Movie Night – Stanley Kubrick And How Killing Projects Is Not Always A Bad Thing
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 awhile 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.
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 development 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, 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 projects at the company or the horrific future that is about to happen. Without a clear definition, there is a tremendous risk to the project that it will not make it to a clear endpoint, 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 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.
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