How to kill, execute, or decompose a project?

With this post, we will start re-publishing some old articles and update them. Of course, we will continue to publish new articles.

Project management is a serious business, but it does not hurt to have some fun with this interesting domain. In this post, 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, dead, 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 our projects 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.

In the past, we also used to hear the term project management life cycle, which is not a common term anymore. Why? Not sure. Maybe it died and was replaced with the project life cycle; although they are not the same.


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 speak of 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 a 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”? Yes, since some refer to these stage gates 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? Am I the only person confused here?


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 know 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 premortem. 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 premortem 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.