Project management is a serious business and project management skills are crucial for all types of organizations today. However, it does not hurt to have some fun with this fascinating domain. In this article, we decided to play on words and learn the language of the living dead that – some of us – use from time to time.
Life & Death
Some of the words we often use in the emerging and dynamic field of project management are related to death; yes death as in no longer alive.
Why the darkness?
We are not totally sure but maybe because when there is life there has to be death; unless, of course, some of us could be immortals.
Actually some projects do seem to be immortals; since they do not seem to finish … ever.
To explain the above let us start with life.
One of the most common terms some use in project management to refer to the ‘whole project’ is the phrase Project Life Cycle or Project Life Span. Regardless which term we use – in either phrase the word “life” exists … so a project has a life.
Of course, those managing projects sometimes cannot get a life since they are so busy managing the life of the project.
Now since projects are important and each has a life, then why would one use death terms to refer to projects? We do not only talk about death, but we talk about violence – ouch! Can we talk about projects in a positive manner or is violence around us so dominant that we use “death talk” even when we are talking about the creating of something new, something amazing?
Let us start with the death spiral and hopefully it will not visit your project.
If you have experience in project management and you are familiar with the project life cycle concept, then you know that we typically breakdown the project into smaller time-bound segments, we call them phases or stages. Further, you might already know that at the end of the stages there are review points, control points, toll gates, stage gates. Meaning a review to approve the earlier works and decide if we are to go ahead to the next stage or not. So there is a decision on continuing or not. If we were not to continue then we cancel the project; sorry we KILL the project; Eyck “kill the project”.
Why cannot we just say stop or cancel the project and some prefer “Kill the Project?”
If the project survived the early work, we did not kill it, and we have an approved project management plan, then the team move ahead into project execution and we execute the project (work). This does not make sense, does it?
It sounds like if we do not Kill the Project we Execute it. In other words, if we do not kill it early we execute it? I am confused!
What we have here is the name of a technique we use in project/stage planning to develop the work breakdown structure (WBS) and activity list. In project management, we like to breakdown the project/stage scope into smaller and smaller pieces down to what we call work packages. Then we breakdown the work packages into smaller pieces that we call activities. Sounds logical to subdivide the work into smaller and smaller pieces for better planning and control.
Yet, an important standard document like the PMBOK® Guide calls this breakdown technique ‘decomposition‘. In other words, we decompose the scope into work packages and the work packages into activities.
The confusing part is that we do this before the execution and killing the project. How the project decomposes before it is executed? We need to find a higher authority to answer this one.
Another term for today is postmortem.
We use this term for the project review and analysis that we do after the project is killed or complete in order to find out what went wrong (and sometimes well).
Well, this is natural outcome since after we kill the project we need to find out the cause of death, but we already know this don’t we? The project is dead because we killed it, executed it, and even decomposed it. The project team is guilty as charged!
However, what is more, confusing is that if the project is complete – survived to the end of this survival game, yet we still perform a Postmortem. How can we do a postmortem on something that is alive and thriving?
Just a few days ago (before the original writing), a friend showed me a message talking about premortem. What is that?
Is this for the team to decide how to kill the project? Sounds like premeditated murder.
Actually on a serious note, it was the first time I heard this term but basically it uses death language to refer to project risk management or something like that.
Once I was leading a project management class, we were talking about scheduling and in scheduling there is a technique we use to compress a schedule (make the project duration shorter). Yet the death talk lovers prefer to call this crashing so we typically joke about crashing the project.
Now we know why the project is dead, if we did not execute it, we crashed it.
One has to admit – we are quite creative in the death talk and finding ways to kill, decompose, execute, crash and not necessarily in order.
Why the Darkness?
To summarize the above,
- First we perform a premortem on a project …
- before the project decomposes … and
- before we crash the project to death …
- and if it is not dead we kill it …
- or execute it … and
- if in trouble during the executing we crash it again …
- Finally, we perform a postmortem … whether it is dead or not!
Sounds about right?
Why such words and why we cannot use normal living words to refer to projects? The sad part is that many global standards and project management literature use these words.
- Why cannot we use approval, decision point, go/no go, stage gate … instead of kill points?
- Why cannot we use project implementationinstead of execution?
- Why do we have to decompose and not breakdown or subdivide …
- Why–oh why postmortem and premortem instead of post project reviews and risk management?
Projects are already complex and a chance of success is a challenge – do we have to make them worst by using terminology with a negative connotation?
This initial version of this article was originally published in September 2012. It is updated and republished in April 2015.