Introduction
Management reviews, sometimes referred to by project managers as phase exits, stage gates, or kill points, are very important for keeping projects on track. These moments serve as decision point for if a project should be continued, re-assigned, or canceled. Remember that each project is just one part of an entire system an organization has, and changes in other parts of the organization might affect a project’s status. By breaking projects down into phases, management can make sure that their projects are still compatible with the changing needs of the organization. In addition to management reviews, it is important to have management involvement throughout the life cycle of most projects, especially for long-term, large projects. Typically, the executive sponsor or executive steering committee of the project makes the final decision on stopping or killing the venture.
Thomas Edison, whose key to success was that he failed often, said of himself, “he could recognize a dead horse before it started to smell.” Unfortunately, in the history of IT, there are too often failing projects (or dead horses) that linger. It’s okay to let a project go if it no longer makes sense! Project cancelation comes from draining cost overruns, schedule overruns, changes in budget, changed or forestalled goals of the project, political factors, rocky project performance, lost stakeholder/user support interest, too many high risks, or any combination of those and other factors. The most common reason for canceling a project is a change in organizational priorities. Sometimes more important projects are just waiting for attention. It’s important to note that contracts often specify the time and way a project may be canceled.
Post-Project Review
When a project is completed or terminated, there should be a post-project review. Some project managers don’t waste the time performing this review when a project is terminated. I don’t agree with this. Terminated projects are especially important to learn from! Clearly analyze and name the causes that contributed to the premature ending of a project, and remember that pieces (specifically, intellectual property) of the canceled project could possibly be used in the future. Capitalizing on such can help lessen the costly expense of termination. Learn from mistakes made, so that you don’t repeat them again and so you can improve your future projects. Remember, successive recurrences of the same negative situation are not mistakes – they are evidence of neglect. Neglect always carries a high cost and can mean taking fewer profits to the bank. I like to keep in mind the following quote from George Santayana, Spanish-born American philosopher, and humorist, “Those who can’t remember the past are condemned to repeat it.”
More Tips
When you are getting ready to kill a project, make sure you really can’t save it. As part of a thorough investigation into whether a project must be canceled, review the original scope of work, the skillsets of those involved, the required materials, the testing process, the expectations of the sponsors, and any other factors that contributed to the project reaching a kill point.
Don’t play the blame game! Usually, when a project needs to be canceled, several people have made (big) mistakes somewhere along the way. No matter who is to blame, you won’t do yourself any favors by pointing the finger. Hopefully, you work in a positive culture where people are not punished for bringing forth “bad news.”
Make sure you communicate the reasons why you had to pull the plug. This is critical because it helps sponsors, employees, and customers all understand that a cancelation doesn’t mean other projects are in jeopardy. If you must cancel multiple projects that are interconnected, try hard not to cause your team stress.
Make plans on what to do with the resources that were allocated to the canceled project. For example, employees may be reassigned to other projects and/or pursue additional training. Contractors might have to be let go or reassigned.
Any recommendations for changing the development process should be submitted and considered quickly. No process is perfect in its original design, and rapidly changing business needs will continue to challenge the process, so ensure the post-project review receives the necessary attention. I believe project managers in the IT field and in other industries are getting better at identifying “dead horses,” which means we can reduce cost, time overruns, and increase our success rates.
Your thoughts in the comment section below are appreciated.
This is my fifty MPUG article (or the equivalent of a book), which is a milestone for me. I want to thank the MPUG team and my valuable editor, Jana Phillips, for her outstanding support in making my work straightforward and satisfying.
