How to kill, execute, decompose … a project?

Project management is a serious business but it does not hurt to have some fun with this interesting domain. In this first official post, we decided 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 with this first post while we address an important view on project management terminology.

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 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 – in either phrase, the word “life” exists … so a project has a life.


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!

Let us start with the death spiral and hopefully it will not visit your project.

Kill Point

If you have experience in project management and you are familiar with the project life cycle/span 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” and some call these review points as “Kill Points”!


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. Some call 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 it is executed? We need to find a higher authority to answer this one.


The fourth 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 sometime 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 don’t we? The project is dead because we killed it, executed it, and even decomposed it. The project team is guilty as charged!


Just a few days 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.


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. Now we know why the project is dead, if we did not execute it, we crashed it.

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?

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 implementation instead of execution?
  • Why do we have to decompose and not breakdown 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 destructive connotation?

Your thoughts!

We want to hear from you, debate, discuss, offer a counter argument, clarify, challenge, support …

For a short video, click here.


3 thoughts on “How to kill, execute, decompose … a project?

  1. Pingback: Should you ask one of these “fantastic” questions? | Redefining Project Management

  2. Mounir Ajam Post author

    Mark – thank you for the elaborate response. I agree with you that morbid language stick and the other terms are more standard … so it is up to people to chose which would they prefer. Just today i saw a post asking about “Murder Board” …

    My personal preference is to stay away from those terms – but that is my preference.

  3. Mark Jones

    Mounir, two observations on this.
    First, a linguistic approach. At the end of your post where you list alternatives, it struck me that your preferred terms are mostly denotative meanings, the most basic meanings that those words can provide. By contrast, the others are connotative meanings, which are meanings that are extensions of a word’s original denotative meaning. What’s remarkable here is that words chosen for their connotative meanings are typically more colorful; denotative word use tends to read as dry and stale.
    So to extend your metaphor a bit, the death-related terms tend to bring a bit more life to the project glossary!

    So, second, why death-related connotative meanings in a project context? You have already hit on the answer, is that there is a useful analogy between the human life cycle and the project life cycle. I would take the rationale a step further, though, and suggest that it is the inherent frailty of projects that makes the analogy strong, in addition to the obvious linkage of denotative human death and connotative project death. Just like there are so many things that can injure or kill a person, there are just as many things that can disrupt or terminate a project, so it’s a natural language choice to select terms that are familiar by analogy and enrich the language at the same time.

    The good news is it’s not all morbid language that is used on projects. Subprojects are born. Change requests are OKed. Resources are freed up. PMs are worshipped (OK, that one is a little over the top…).


We welcome your opinion - supporting or challenging the topic