Wanted Dead or Alive

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. Today’s topic, the dark side of project management terminology.

We decided to have fun with this first post while we address an important view on project management terminology.

The dark side of project management terminology

Life & Death

The dark side of project management terminology is about 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 of 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 lifecycle/span concept, then you know that we typically break down 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”!

How-to-kill-execute-decompose-a-project; the dark side of project management terminologyExecution

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 sometimes 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?

Why the darkness in these project management terms? 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 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 destructive connotation? With this, we conclude the dark side of project management terminology.

Your thoughts!

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

For a short video, click here.