On Killing Projects

Sometimes projects cannot succeed in their current incarnation. I have been involved in a couple of projects that were initially disasters and had to be stopped, completely re-thought and then begun again. While it won’t happen often (hopefully!) being able to correctly identify a terminal project and deal with it can save time, money and finally generate a successful outcome. I’ve outlined a few factors to look for as well as some tips on how to kill a bad project.

When to Kill a Project

Over budget.
Over time.
Nowhere near completion.
Thinking about the project keeps you up at night and makes you nauseous at work.

The above are a deadly combination. Budget, time and completion milestones should all roughly keep pace with each other. Being over budget, over time and under completed is about the worst possible configuration and represents catastrophic failure for that project. Feeling sick to your stomach is your subconcious project manager telling you that you are doomed unless something is done. Listen to your body. The secret to excellent project management is recognizing tendencies toward the above early in the project rather than when you run out of money and/or time.

How to Kill a Project

Build a case including alternate options to meet original needs.
Gain support of stakeholders and a champion.
Present recommendations to leadership.
Do not play the blame game.
Learn!

Don’t just go to your supervisor and say this project needs to be killed. You have to address how the need that generated the project in the first place will still be met or debunk the necessity of meeting it at all. You won’t get anywhere unless you can confidently answer that one. You also need to sell all the stakeholders on the idea as well. Stopping a project is incredibly hard to do once momentum is established and you will need all the help you can get. Finally, don’t get into assigning blame for who screwed up what. That will just take energy away from killing the project. Fix the problems and learn what went wrong and why and how to do it better next time.

This is not to say that all poorly run projects must be killed. Usually you can make some adjustments to an existing project that will bring it back into shape. Killing should be reserved for those few that cannot be salvaged in their current form.