My recent post on project failure was one of my all-time favorites. While I wrote about failure from the top of my head, the reader comments were really well considered. Between my thoughts and the reader observations I think we have a great summary of the main reasons IT projects fail. I plan to turn that into a presentation.
Of course you do not want projects to fail. The preferred alternative is success. But there is a 3rd option, if a project is clearly not meeting your expectations you should kill it. Wayward projects are those suffering from cost and schedule overruns; are clearly going to require more resources than planned; and/or are not going to meet the original expected benefits.
Our organization has learned to embrace killing projects. And I think it is very healthy. In the recent Baseline Magazine, there is an excellent article on Project Lust. The story quotes Michael Krigsman, CEO of Asuret, a project-management consultancy: “It’s very common to see both IT and the line-of-business folks become enamored with a project and continue, blinded by the risks, when a third-party objective participant would say that there is failure coming down the line out there”
I believe project lust is common in most corporate cultures. The result is throwing good money after bad. At Ministry our IT Steering Committee congratulates business leaders that have the insight to see when something will not meet the planned expectations and having the courage to kill the project.
Every year we refine our project to discipline to better ensure success. But we are still a long way from perfect. Bad IT projects are still a fact of life. Killing them preserves your resources for the good stuff. I would encourage IT and organizational leaders to let embrace the idea of killing projects as something much better than failure.
The starting point for all of this is having the discipline to determine the success (or failure) of each project. If everything completed is considered a success, then there is no reason to stop.
If you are not killing a project or two each year you are going to suffer more failures.
Thanks to tstadler for making the picture available via flickr us Creative Commons Licensing.
Candid CIO 
Hi Will,
When do you think the project should be killed? What are the symptoms of a project that should be definitely terminated.
I think this is an interesting subject. Have you ever seen it go over board? It seems like the tendency is to look at the past expense as a sunk cost and then continue forward. Definitely a trap.
Pingback: IT Project Failures mobile edition
There’s an expression over here in the UK that “it’s no use crying over spilt milk”. Any investment (cash / resource / effort) incurred in a failing project has gone to the great accountant in the sky – but most business and IT managers can’t see this, with the inevitable result of greater losses.
Killing a project is a critical business skill – good post!
Killing projects is a brave move that few have the guts to do – I find that a lot of (dare I say cowardly?) PMs would rather continue throwing good money after bad in the hope of saving the day rather than suffering what will be in relative terms some egg on face. Governance is the key, isn’t it? Show me effective governance though!
Simon