About a successful project that was a failiure
On time, on budget, to the scope that was agreed from the outset of development. A successful project? Well no actually. It was a complete failure.
Here is a story about an insurance company with a number of differnet products sold through intermediaries. Whilst the intermediaries were good at selling single insurance products, they weren’t so good at cross-selling or up-selling other products. Focus groups with the intermediaries revealed that they didn’t know about all the other types of insurance available through the company.
What if the intermediaries could have a portal where they could access all our insurance products in the same place with customer alerts and sales support prompts identifying further selling opportunities?
From this initial idea a benefits case was pulled together consisting of a product definition and financial projections. In pulling together the benefits case, the potential revenue uplift numbers surprised everyone. Signing off the benefits case on the new Intermediary Portal was duly signed off, and the product definition was handed over to IT to build.
Being an agile IT shop, the business and developers sat down together and got their heads around the product definition. It soon became clear that the challenge was one of “single sign-on”. Each of the insurance products offered were on a different legacy application that required the intermediaries to sign-on with different credentials. To bring them all together in a single portal was far harder than the simple problem that the initial product definition suggested.
In pulling together the benefits case, a rough estimate had been supplied by IT. Now it was an in-flight project with an initial list of stories, it became clear that they had significantly under-estimated. Of the twenty different products that the business wanted on the portal, for the budget the business had set aside would deliver barely four products.
With new estimates a release plan was drawn up. Release one would deliver single sign-on across four products identified by the business as being most profitable. All the sales support tools were de-scoped and scheduled for a third release with the second release delivering single sign-on for the remaining products.
Development started, the business stakeholders worked closely with the developers and the First Release of the Intermediary Portal went live with congratulations all round. Funding for the next release was lined up depending upon the success of the first release. But that success never came, take-up was less than expected and the cross and up-selling never materialised.
The proposition to the intermediaries as delivered was flawed; the portal had to be all or nothing, single sign-on across four unrelated products was not compelling to them. There was no sales support. The intermediaries thought “so what?” IT had delivered on the business requirements yet the project was deemed a failure.
This story tells a striking lesson. The project failure was due to a lack of joined-up thinking. The business and IT both had followed their processes and done the right thing. The business had identified an opportunity, built a benefits case and had this signed off. IT had run a model agile project with close engagement with the business. However whilst both stages of the process were locally optimised, they were done in isolation of each other. Once the (development) train had left the station both sides were committed to delivering the product portal. No-one returned to the business case, no-one went back to the end users, the intermediaries and asked whether the cut down scope for the first release would actually be of value to them. More importantly, IT were engaged too late in the process. The business had settled on an IT solution to the problem without engaging IT. Had IT been party to the ideation and visioning process they would have been able to raise the risk of the project complexity earlier on. Indeed they could have killed the project before it started.
Returning to the initial problem; “intermediaries weren’t so good at cross-selling or up-selling other products… Focus groups with the intermediaries revealed that they didn’t know about all the other types of insurance available through the company.” The problem didn’t need a portal solution. The issue was one of awareness; almost certainly an off-line marketing campaign would have delivered a greater ROI without the need for IT to build the wrong product.