Same failure, different company and country
Last week I read about another IT project failure. This one was in New Zealand, but it could have been any company anywhere. Many people reading it will have thought of one of their own and wondered if it will ever end.
So, is IT project failure inevitable? Well, no, but also maybe, yes.
Oxford and Copenhagen researchers studied 5,392 IT projects and found that ‘…managers may be unwittingly exposing their organizations to extreme risk by severely underestimating the probability of large cost overruns.’ Most projects had small overruns. A few had extreme ones, and those are the ones we hear about.
Anyone who has worked on IT projects knows that doing things the right way usually leads to success. Most organisations just don’t do it. So, what do these success principles look like in practice?
Know what 'done' looks like. Define the value a project should create before deciding what to build. If nobody can describe the benefits and how they’ll be achieved, don’t start.
The business case is not the plan. It’s an approval to test whether the benefits will outweigh the cost. Planning a major project should take months and provide the basis on which to start.
A sponsor who shows up. Sponsorship is a skill most senior managers are never taught. Once the project starts, sponsors should stay visible and surround themselves with people to make timely decisions, rather than at the next board meeting.
Only do the work that gets you there. Every feature should move you closer to the outcome. Anything outside the original scope goes to ‘Phase II’ or the ‘nice to have’ pile. Also, ‘no’ is a complete sentence.
Build the team, then execute. Without a team built at the start, work rarely happens cohesively or on schedule. You can’t build the plane whilst flying it. It will always crash.
Mitigate risks. Writing them down isn’t enough. Treat, transfer, tolerate or terminate them. Every risk is an issue waiting to happen, and issues impact time, money and reputations.
Build small and show users early. The NAO found that larger digital programmes carry a greater margin of error. Releasing working pieces to users turns one big bet into lots of small, survivable ones.
Change the culture before implementation. Too often, change managers are asked to get people aboard the new ship after it has sailed. People need training, but new behaviours will be required if the benefits are to be realised.
Agree kill criteria before you start. Not every project that looks good on paper works in practice. If the kill criteria are met, stop, however much has already been spent.
I’ve led my fair share of projects, and they can be messy affairs. Yet following these principles drastically reduces the chance of public, humiliating failure. At worst, you’ll see it before the newspapers do.
Download my new white paper ‘Making Culture Change Stick’ to find out more about how you can build, change or retain a great place to work at www.colindellis.com/culture-papers
