This is the 3rd article in the series "Killing A Project". Click here for Part 1 and Click here for Part 2.
No one wants to be on a project which is failing or not performing at all. But organizations and project managers need to determine very quickly on whether to kill a project or not. It’s hard to make a decision when you’ve invested lots of time and especially when you’re emotionally connected but there are always business-related signs and warnings which will warn you about the consequences if you keep working on the project.
If we take a look at any report by The Standish Group, then we’ll realize that the major reasons for IT project failures are PEOPLE and PROCESSES. If you can identify those signs in time, don’t hesitate to kill the project.
The major reasons for IT project failures are PEOPLE and PROCESSES
The best way to identify is the project is doomed or not is to check the progress with the objectives or goals. If you’re not on the path of meeting the original purpose and you think your team is out of track because of so and so reasons and you’ll never get back on track, then it’s the best idea to kill the project and release the resources so that organization doesn’t waste more money.
If your project team is failing to deliver the required results on time and failed to meet MULTIPLE deadlines, then that might be a financial sign that it’s going to cost you way over than planned and you need to decide very quickly about the future of the project. And that’s just not true about schedule, but for all Triple Constraints. If your team is meeting deadlines and scope but not delivering the satisfying to results (QUALITY) to the customer or to the stakeholders, then it won’t worth at the end and they might decide to kill it at the end.
The best way to identify is the project is doomed or not is to check the progress with the objectives or goals.
We all have seen senior executives who often promote uncertain projects because the result will help themselves and not to the organization. In such cases, project managers need to take responsibilities and clearly define alternatives in Business Case for stakeholders so that they can identify why the currently promoted project isn’t worth much.
The great concept of Sunk Cost and we need to be careful about it. I know that anyone’s future business decisions should not be based on sunk cost but it’s hard to ignore sunk cost many times when it’s too much and stop throwing good money after bad money.
A technology warning sign would be when your team starts counting number of bugs they’ve fixed rather than the number of features they’ve released or when your team prioritize every bug they find out as critical. Those signs really point towards the quality of the system.
The size of the project matters as well. Small projects tend to be more successful than large projects and that’s when the risk of scope comes into picture. If your client is keep adding the scope and the project team is uncertain on what to build then that’s a SCOPE CREEP sign to kill it asap.
There is one solution to the scope creep type of situation. AGILE. Agile projects are more successful because of iteration than Waterfall. So, when your team is working on a very big project of years without delivering workable solution in between then don’t even bother to start OR stop it as early as you can.
There is one solution to the scope creep type of situation. AGILE.
Closure Kill Project Project Management
