Terminating a Project: How Killing a Project Is Not Always A Bad Thing
Updated: 7 days ago
Don Davis PhD, MBA
I live in Colorado and a trip to the Stanley Hotel where the movie, The Shining, a 1980 psychological horror movie was filmed is in the mountains about 45 min away. In the movie, Jack Torrance is a writer whose son Danny Torrance possesses the psychic ability to see the hotel’s horrific past. Although I have not seen the movie in a while I can still hear Danny saying “REDRUM”.
How does this relate to killing projects? I will get to this point a little later in our story but first I need to set up what will bring us to that point.
Killing a project, also known as Project Termination, when a project is no longer feasible or fails it needs to be terminated. Project termination is the end of such projects that have been identified as unsuccessful and is no longer worth pursuing. In other cases, the project may have reached its natural end.
There are many possible reasons why a parent organization may deem it necessary to terminate a project. The most common possible reason for unnatural project termination refers to the situation where a project is ended prematurely before it is completed. This can happen for a variety of reasons, including:
The project was not feasible from the start (i.e., unrealistic completion date, poor project time management)
The project ran into unexpected difficulties (i.e., sudden lack of financial resources so difficult to budget in accounting and finance issues)
The project was not well-managed (i.e., poor performance)
The project did not meet its goals (i.e., sudden market crisis)
Whatever the reason, unnatural project termination can be a major setback for businesses and organizations. It can lead to wasted resources, lost opportunities, and damaged reputations.
The decision to terminate a project can be made by the key stakeholders, client, project management team, control board, top management, or project manager. When terminating a project, the parent organization should first notify all relevant other stakeholders. This includes project team members, sponsors, and any other individuals or organizations who are affected by the termination. Once stakeholders have been notified, the parent organization should develop a plan for how the project will be ended. This may involve wrapping up loose ends, transferring assets to another organization, or simply shutting down operations.
When a project is terminated, all remaining resources are released and the project personnel is disbanded. Project records are archived and any final reports are prepared. Project termination is a formal part of the process and should be documented in the project's governance documents.
The parent organization should also take steps to ensure that projects are documented and shared with relevant parties and served as document lessons. This will help to improve future projects and avoid repeating any mistakes that were made during the course of the terminated project.
Project termination can be a difficult decision to make, but it is sometimes necessary in order to avoid further losses. Terminating a project early can save money and material resources that would otherwise be wasted on a doomed effort. Project managers should be familiar with the process of terminating a project so that they can make the best decision to save time, effort, and money. Part of being a project manager is helping to best leverage resources to complete projects but knowing when to stop comes as a part of managing time, money and people. Part of making projects transparent to an organization is the ability for a project manager to also clearly state that things are not going well.
While it is unfortunate that the project did not work out, it is important to learn from mistakes so that future projects can be more successful. Project management is a complex process, and there are many factors that need to be considered in order to ensure a successful project outcome. By understanding what went wrong with this project, we can make sure that future other project result is better able to avoid these same pitfalls. Project management is an essential part of any business, and making sure that it is done correctly is crucial to the success of any organization.
When we embark upon a project it is often to create something that everyone is behind and oftentimes if teams do not fully step through defining what they are going to create it can lead to severe issues later.
What is the purpose of the project? Typical projects in Life Sciences seem to be centered around two areas: 1. To create something 2. To solve a problem
What are the guiding principles for the project? This is the definition of the “must-haves” that will enable binary decision-making about key things that need to come from the project. If at any point the guiding principles are in violation the team cannot go forward. For example, if you want to have a software supplier that acts as a partner to your business but they often are only worried about “their revenue or their product”. The team would need to stop external developments and find another vendor.
Key outputs need to be defined. What will the new world look like with this new product, software, or service? What are the things that are in place?
Leadership support in starting the project and leadership clarity in stopping the project, if needed.
Back to our story about The Shining, if these things above are not in place you do not need to be Danny Torrance or have the shining to know about either the horrific past of other projects at the company or the horrific future that is about to happen. Without a clear definition, there is a tremendous risk to be the failure of the project in successful completion, and if issues arise, the project will most likely continue to languish.
As projects, progress, and companies spend money the individuals within the company become emotionally and physically invested in the project. This often clouds judgment and I have seen Diagnostic projects that should have been killed, IT projects that should have been killed but when it came time the project team or leadership team just could not or would not make the decision. So the project and development teams continue on trying to overcome issues that may not be resolvable.
Numerous times in my career I have been asked to help recover a project and in many cases, I have been able to help teams and managed many projects by going back and clarifying the points above. However, if the initial decisions that formed the foundation of the project violated any of the guiding principles there comes a time when the decision needs to be made to kill the project.
I was recently speaking to a leader about how fortunate we are to work around the most brilliant people in the industry. Many of these scientists are wonderful at their specialty and they will not give up. To reference another Stanley Kubrick film, 2001 A Space Odyssey, sometimes we need the monolith to arrive to trigger an epic transition to a new era. After you have spent over a million dollars trying to overcome issues and had numerous meetings with brilliant people to try and see if there is still a possibility that the project can survive, when is it time to pivot or stop?
Helping with this decision is a small toolset that I have outlined for you based on proven tools for solving these issues. Hopefully, they will help you if you encounter a project that is somehow stuck at the Stanley Hotel.
A couple of tools for you:
An initial project charter is a good idea, here is a simple template for a charter.
Build a list of no more than 10 guiding principles at the beginning of a project. What are the must-haves?
If a project is in trouble what has the company spent to get to this point? How much will it cost to fix the issues at hand? How does this impact the ROI that the company expects from the project? Use this criteria to decide to pivot or persevere.
If you need to define clearly with the team why the project team is struggling I would suggest a fishbone or cause and effect brainstorming session will give you a list of most likely targets to go after.
At the head of the fishbone, you describe the effect or outcome involved.
At the end of each of the ribs of the fishbone you list out the big categories, oftentimes you will see things like (man, machine, method etc.)
At each of the points on the rib bones, you will list out the factors or causes for the issue that you are seeing.
After the team has listed the causes you will then place a C for Constant, N for noise, or X for Experimental. Constants should really be constant and should not change, Noise are the factors that you are not going to solve for and Experimental factors are going to be tested to see if they improve the outcome.
After the team has fully tested and eliminated options without a final solution there is really only one final decision to be made and that is for the project to end.
“I do not always know what I want, but I do know what I don’t want.” – Stanley Kubrick