project failiure

About a successful project that was a failiure

  • Wednesday, 18 November, 2009
  • By:

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.

Someone should talk to the minister about agile

  • Thursday, 12 March, 2009
  • By:

So another government IT project fails to deliver.  The National Offender Management Information System had been budgetted to cost £234m (total lifetime cost) and take four years to complete.  Three years in and the costs had spiralled, with a new lifetime project cost estimated at £690m.  The plug was pulled and a new three year project at the cost of £513m was commenced.  Poor project management was blamed, but I’d go further and blame the project approach as well.  The Minister responsible says why;

“As soon as the extent of the projected costs and delays to the project were recognised, we took immediate steps to halt the project and consider the most cost-effective way forward which effectively preserved the work done to date”

So let’s get this straight:

It took three years to recognise that a project to implement a single database had gone wrong. 

Contrast this to an agile project where progress, costs and risks are continuously monitored.  But what does the goverment do?  Continue with the same approach as before with some new project managers on the job.  And wait another three years before any value will be delivered.

The user journey

  • Monday, 9 February, 2009
  • By:

“Faster, slicker, easier to use.  That’s how we sold it to the business.”  It is a common theme, IT have a system that is costly to maintain, hard to extend, is on a dated platform and no longer fit for purpose.  The business are persuaded of the need for a replacement.

This is what happened at an organisation I recently visited.  But it didn’t quite go to plan.  A number of years later and they’ve got an application that is slower, uglier and harder to use.  What happened was the business intent was distilled into requirements (based upon the existing functionality).  Each requirement was captured as a control on a screen.  These were bundled up and sent to India for coding, and the developers went and built a bunch of screens.  They considered interface design but not interaction design.  They focussed upon technical processes rather than user journeys and the resultant deliverable was something that functionally ticked all the boxes (it did what the specifications said it should do) but was ultimately rejected by the people it was intended to help. The code may have been great but that meant little to the business who found the application a pig to use.  Another failed multi-million dollar IT project.

User interface design is more than just screen design, it is about the journey the user takes to accomplish their goals.  Remembering that could have saved this particular organisation a lot of money.

Was it just a simple database query?

  • Friday, 23 November, 2007
  • By:

So the sensitive personal details of 25m people has been lost and there is a huge political furore over it. Whose fault is it? As far as I can see, (and this is my personal opinion,) blame must lie with IT, specifically the IT contractor and either the contract they work with or the perception of that contract.

The National Audit Office asked HM Customs and Excise for child benefit in “desensitized form”. Sensitive details were specifically asked to be removed, ostensibly to make the file size smaller. This would require a bespoke query to be run. It was deemed too costly so it was assumed that a full extract of the data would do. The fact that this was then burned to a CD, posted unregistered mail and lost is not the point (that is stupidity). What is the point is the IT contract prohibits the business (in this case the governmental offices) to do their job properly.

What sort of contract demands extra payment for a simple database query for “NI numbers, child benefit numbers and children’s names in order to select a risk-based sample of cases to audit as part of anti-fraud work“?

Surely this is an extra request that an experienced database analyst could easily run in the course of a day? If not you must ask why not – is it because the database is badly designed with nested tables and stored procedures and stuff that would make a decent DBA go eugchhh (I’ve seen that happen). If this is the case, the IT contractor has done a bad job; if an electrician worked in your house and left a mess of an electrical installation, would you keep employing them, even if they were cheap?

Maybe however it would not have incurred a cost and this was just the perception; “we must not… run additional scans/filters that may incur a cost to the department”. If this was case it suggests a breakdown in the relationship between the business and IT, with tendency towards the confrontational and transactional rather than co-operation and partnership.

Organisations that outsource their IT often fail to realise what the true costs are. Anything outside the terms of the contract is a change request. It is not unusual for the request itself to incur a cost (someone has to write the documentation, specifiy the design, estimate the effort) before a line of code is written. (At one organisation I worked with that had outsourced their IT function, I was told that to add some basic client-side field validation to a single field on an application form on their website was likely to cost in the region of £60k). The business starts to believe that everything costs and IT becomes a hindrance and a vicious cycle commences.

How could things have worked differently? Let’s say the HMRC IT department was run on more lean/ agile lines. With agile it embraces change. The request comes in (let’s assume such requests are not regular occurances) and in the morning stand-up the BA describes the request and asks the developers for its feasibility in a word. Someone says “yes, I ran a simiar querry last month, it’ll take me ten minutes”. (In reality double or treble that estimate), but it will not have an imact on the developers ability to get thier prioritised work completed. Alternatively the developers say “given the database structure we have inherited that’s a lot of effort” or the project manager says “another request?! pritoritise it like the others!” and it is prioritised in the weekly iteration planning meeting (pushing something else out) and then it gets done.

My hope is that when the inevitable investigation takes place, they don’t just look at the policies and procedures, but also at the underlying structure of the way that IT is managed.