Following in the footsteps of McDonald’s, Ford, the FBI and many others, Lloyd’s of London has pulled the plug on a big, expensive, and now embarrassing software project. Launched five years ago, the effort was aimed at modernizing the venerable insurance group’s brokering processes and making them “paperless.” But the new system never enticed users to actually use it – the cure turned out to be worse than the disease. Lloyd’s ended up wasting 70 million pounds – about $125 million – on the project before chief executive Michael Dawson concluded this week that “the platform was not optimal in ensuring more efficient business processes for the Lloyd’s and London market and as a result it will close.”
There are three lessons here. First is that the bigger the software project, the more likely it is to collapse under its own weight. $100 million seems like the line beyond which failure is almost assured. Second is that you should always create software to solve the day-to-day problems faced by the actual users, not to meet big abstract organizational challenges. Solve enough little problems, and the big ones take care of themselves. Fail to make users’ lives easier, and they’ll simply bypass the system (and never trust anything you do ever again). Third and finally, you should never give a software project a catchy codename. For Ford, it was Project Everest; for McDonald’s, it was Project Innovate; for Lloyd’s, it was Project Kinnect. If you’re about to launch an IT initiative big enough to warrant its own name, you should probably make sure you have a really good golden parachute.
Hallelujah and amen.
Anything with “project” in the title also ensures failure. Just as in “project management.” Please. It’s management. Unless the project “managers” have a good process to back them up and buy-in from all managers, they might as well just beat their heads against the wall.
Good news -Most CIOs I know are extremely wary of launching mega-projects. They learned from their late 90s, early 2000s ERP, ebiz,Y2K experiences.
Bad news – Most vendors I know, though, still want to shoot elephants as I wrote here
http://dealarchitect.typepad.com/deal_architect/2005/10/any_budget_so_l.html
$125 million ? That’s nothing.
The Irish government wasted 150 million euro ($190 million dollars) on a payroll system before eventually conceding defeat.
This is an argument for SOA.
Large or small, IT projects have a habit of becoming rapidly unhinged if they are not focused on addressing the
realities of the business environment that they will operate in and support. We’ve seen a number of silver bullet
technologies come and go over the last few decades (databases, expert systems, client-server, BPM, and now SOA) which have
demonstrated time and again that technology driven approaches rarely deliver on their initial promise. The lesson
would seem to be that simple adoption of a new technology will not deliver the grand application that (we think) the
technology might enable.
Successful projects place the business centre stage, with technology in the background playing a supporting
role. As Nick and ordaj point out, successful projects address specific business needs, have buy-in from all
stakeholders, and are integrated into business environment in which they will operate. Technology is then pulled into
the project as appropriate to solve specific problems.
Some emerging technologies (primarily SOA) show more promise, as they are part of an emerging trend to take
a business-focused view of IT. However, we must remember that the magic is in how the technology is
applied, and not in the technology itself.
of course the biggest mega projects in the indurty right now are those at Oracle with Fusion, SAP with its SOA and customer migration, Microsoft as it tries to integrate Great Plains, Navision and other acquisitions…chances of success?
Project size is relative. A small organization can get crushed by the weight of a fairly simple accounting solution project. I receive distress calls weekly from clients who have wasted a lot of cash trying to get a new system live, to no avail. But until they fail, large or small, no one wants to listen to person who says something reasonable like ‘let’s knock this out in pieces and prove the system one foot at a time.” No, the heroic always want to push the entire boulder up the hill at once.
The Lloyds case is ‘special.’ It’s an institution steeped in 300+ years of history where automating even the most (apparently) simple things is incredibly difficult. It also has a special form of accounting that makes solving Rubik’s Cube look like a walk in the park.
The point is made very well in the DT article:
“The problem was underwriters and brokers just didn’t seem to care about getting involved and making the market more technology based. People in the market felt they hadn’t been consulted properly and as a result, the Kinnect solution simply did not get any market momentum.”
In other words – no buy in.
Nick’s talking rubbish in places. I just don’t see the connection with his thesis and the DT report.
Many of the projects I’ve seen fail are as a result of poor project management. Who talks about that? It’s not always the case the software was particularly poor or ‘not fit for purpose.’
In recent years, software has improved immeasurably – the days when Oracle warehouse numbers failed to balance when represented in the GL are gone. (Or at least I’ve not heard that one recently.) Sure, vendors make mistakes – it’s the nature of software that it’s imperfect. But there’s a difference between imperfection and crap.
The minute companies try replicating existing broken or less than efficient processes they build in failure.
Where vendors and SIs do have a responsibility is in over promising. They get away with it because they have knowledge the customer doesn’t and which the customer has no way of testing. Simple solution – don’t pay for what you don’t get. Look at what happened with i2?
To Tom’s point, I’m assuming he’s talking about relatively small companies. Very often, what I see is a failure to understand the significant operational change that new software brings combined with inadequate training and communication.
As to Sam’s point. How is this a case for SOA when there was nothing there before?
There’s no magic wand in all of this but a more careful analysis is needed if companies are to learn the lessons of others. Anyone want to put their hand up and say: “Hey I screwed up?” didn’t think so.
Perhaps you would like to comment on your colleague Nicholas Timmins’ write up of the NHS IT megalith, er, project. (FT 16/01/2006). He sounds very optimistic about it. :)