Killing an IT project requires more than a rifle and a backyard. It is a multifaceted process with ramifications for many. In an article for TechRepublic, Scott Matteson describes 10 tips to put an IT project to sleep cleanly and peaceably:
- Get buy-in from project stakeholders and agree on conditions.
- Impossible projects are easier to end.
- Communicate what was and was not in the business’s control.
- Emphasize what you can still do.
- Stress the need to support the business.
- Emphasize the cost advantages of moving onto other priorities.
- Emphasize the business gains of moving onto other priorities.
- Hold a postmortem review.
- Analyze the project management product or methodology.
- Improve the project planning process for next time.
Deciding to terminate a project is very much a turn-the-keys-on-the-nuclear-sub affair, in that stakeholders should agree collectively to the closure and how to proceed with it. If possible, the IT project cessation should be announced as a group so that no one person is stuck taking the heat for it. Matteson notes that it is actually easiest to describe the formal reasons why a project must end when the project is just totally infeasible (whether for security gaps, inefficient technology, etc.). This is a double-edged sword though, in that making the closed project sound too impossible could get the people who planned the project in the first into hot water.
All the same, do articulate if uncontrollable factors like vanishing vendors sunk the project, or if controllable factors like inefficient personnel skills are also a culprit. In some cases, a partial resurrection of the project might be possible:
Not every doomed project needs to completely bellyflop. Is there some sort of alternate solution, even a stripped down concept? For instance, rather than killing an initiative to deploy tablets to the entire remote worker fleet due to security/loss concerns, can you identify a subset of the original user group who might still receive such an implementation? Gaining some measure of benefit from the original project rather than none is obviously preferable and can help pave the way towards revisiting the project in its entirety later.
In the end though, the ultimate goal is not to save face, but rather to best support the business. Go with whatever course best sustains the health of the organization. Try to excite people about the cost savings and better opportunities that could arise from stopping a weak project.
When the messy details are all quantified and addressed, that just leaves ensuring mistakes made during the canceled project do not arise again. A postmortem review is a good first step in that regard. Scrutinizing your overall project management processes will yield further insight, and make it so that more warning signs are heeded in the next project planning process.
You can view the original article here: http://www.techrepublic.com/article/10-ways-to-gracefully-kill-an-it-project/