Do we execute or manage projects? Maybe we should be more direct and ask: do we kill projects or lead projects to success? We need to enhance our view and understanding of project management and project life cycle.
We know that project management is a serious business, but it does not hurt to have some fun with this exciting domain. Today, we are updating and reposting our first blog post; from a few years ago.
In this post, we want to play on words and learn the language of the living dead that, some of us, use from time to time. We decided to have fun as we address project management terminology.
Life & Death
Some of the words we often use in the dynamic field of project management are related to death; yes death as in no longer alive.
Why the darkness?
We are not entirely 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 appear 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 the word “life” exists. Therefore, so a project has a life.
Now since projects are essential 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!
Let us start with the death spiral, and hopefully, it will not visit your project.
Kill Point or Stage Gates
If you have experience in project management and you are familiar with the project life cycle concept, then you know that we typically break down the project into smaller time-bound segments, we call them phases or stages. To manage projects, we need a project life cycle model like the one shown here, with stage gates, the numbered symbols.
If the project survived the early work (i.e., we did not kill it) and we have an approved project management plan, then the team move ahead onto project execution, and we execute the project (work).
This does not make sense, does it?
It sounds like approval at the Kill Point was to go ahead with Execution instead of sparing the life of the innocent project. So if we do not kill it early, we execute it after planning?
I am confused!
Let us jump back to planning.
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 break down the project/stage scope into smaller and smaller pieces down to what we call work packages. Then we break down the work packages into smaller pieces that we call activities. 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 so how the project decomposes before we execute it? We need to find a higher authority to answer this one.
Another term for today is postmortem, and we use this term for the project review and analysis that we do after the project is complete to find out what went wrong, and sometimes what went well. Well, this is a natural outcome since after we kill the project we need to find out the cause of death, but we already know this do not we? The project is dead because we killed it, executed it, and even decomposed it. The project team is guilty as charged!
However, the confusing part is that we often do a postmortem on projects that survive; how can we do this, I am lost for words.
Just a few days (years) ago, a friend showed me a message talking about pre-mortem. What is that? Is this for the team to decide how to kill the project, or to save it?
Actually, on a serious note, it was the first time I heard this term, but it uses death language to refer to project risk management or something like that.
In case we did not kill, decompose, or executed the project some might want to crash it.
Today as 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 durations shorter) that we call crashing so we typically joke about crashing the project.
The problem is that after crashing a project, we do not know if it will survive, go to intensive care, or ultimately die. We need to manage projects and lead them to success not crash them.
Why the Darkness?
To summarize the above,
- We perform a pre-mortem on a project,
- Before that, we crash the project to death,
- If it is not dead, we kill it at the kill point, or
- Execute it, after we decide not to kill it,
- Next, we perform a postmortem,
- Before the project decompose.
Sounds about right?
Closing Comments: Manage Projects
Why such words and why we cannot use ordinary 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?
- Would not be bettwer to use use project implementation instead of execution?
- Why do we have to decompose and not break down or subdivide?
- Why–oh why postmortem and pre-mortem instead of post-project reviews and risk management?
Projects are already complex, and the chance of success is a challenge, do we have to make them worst by using terminology with a negative connotation?
We want to hear from you, debate, discuss, offer a counter argument, clarify, challenge, support …
For a short video, click here.