Project Management Terminology

How do you kill, execute, or decompose a project?

Project management is a serious business, but having fun with this exciting domain does not hurt. In this post, we decided to play on words and learn the language of the living dead that some of us use occasionally. In other words, let us have fun with the project management terminology.

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, dead, i.e., 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 some of our projects could be immortals. Actually, some projects seem to be immortals since they never appear to finish.

Life

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, 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.

Death

Since projects are important and each has a life, 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; hopefully, it will no affect your project.

Kill Point

If you have experience in project management and are familiar with the project life cycle concept, then you know that we typically break down a project into smaller time-bound segments, which we call phases or stages. 

Further, you might already know that at the end of the stages, there are review points, control points, toll gates, or stage gates, meaning a review to approve the earlier works and decide if we are to proceed to the next stage. So, there is a decision on whether to continue or not.

If we were not to continue, we would cancel the project; sorry, we “KILL” the project. Eyck “kill the project”? Yes, since some refer to these stage gates as “Kill Points”!

Execution

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 moves ahead to project execution and 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?

Decomposition

Let us jump back to planning.

Here, we have 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 called work packages. 
• Then, we break down the work packages into smaller pieces called activities. 

Some call this breakdown technique ‘decomposition.’ The wonderful use of project management terminology.

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 does the project decompose before it is executed? 

We need to find a higher authority to answer this one.

Postmortem

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 (or 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!

Pre-mortem

Recently, 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.

Crashing

Once, 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,
• Later, 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 (or after) the project decomposes.

Sounds about right?

Why such words, and why we cannot use ordinary living words to refer to projects? 

Sadly, some project management literature uses these words.

• Why can we not use approval, decision point, go/no go, and 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 perimortem 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 e by using terminology with violent connotations?

What are your thoughts?

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

For a short video about project management terminology (from our past), click here.