Can a Death March Project be Healed?

How many times have you found yourself on or in charge of a project that seems to be cursed, ill conceived, and just too visible for its own good? You know the kind: all of the people on them seem to have lost their mind, nothing seems to get done, and there is more time put into status and how things look than actually doing the work. The problem with these types of projects is that any reasonable person would seek to avoid or cancel them for the good of the company and their own sanity and health if they could. Nevertheless, these projects seem to be all to common. The larger they are, the worse they can get. Their prevalence makes it virtually impossible to avoid them, so what do you do if you find yourself on one of these cursed spawns of the devil and can you reclaim your sanity by making them better somehow?

What is a Death March Project?

Ed Yourdon defines a death march project as:

"... one for which an unbiased, objective risk assessment (which includes an assessment of technical risks, personnel risks, legal risks, political risks, etc.) determines that the likelihood of failure is ≥ fifty percent [1, p. 3]."

Sadly, some may look at that definition and note that all of their projects begin that way. The key part of Yourdon's definition, in my opinion, is that the likelihood of failure is greater than or equal to fifty percent. One of the ironies is that nobody ever really does an objective risk assessment on these types of projects, so you never really know what the true likelihood of failure is. Also, the definition of failure is highly subjective in some cases. Is it missing a date? A key feature? Low quality? All of the above?

Why not Walk Away?

Walking away from a death march project is almost always the right action, assuming you can recognize it early enough. But, there are times when you just cannot walk away from them. Their prevalence is one reason: How do you walk away from something that happens so often? There are other motivations as well. Some wish to take on the challenge that these projects offer in the hopes that it will advance their career. Others remain out of fear that if they do not they will be penalized. Whatever the motivation, there appears to be sufficient evidence to suggest that we may want to find a way to heal these projects because they are going to continue regardless.

Healing the Death March Project

The definition of failure (and success) seems to be the key ingredient for understanding whether you can heal a so-called death march project. The problem is, the true dependent variable may not easily make itself easily known. That suggests that you need to understand what the organization is trying to accomplish and somehow gain control over the variables that cause the project to fall within the "death march" category.

The most common problem I have seen in difficult or troubled projects is uncontrolled scope. Regardless of the software methodology, if there is no control over scope, I do not think healing the project is possible. While poor requirements (or stories, depending on your methodology persuasion) may be a sub-dimension of this, when I have seen projects that were otherwise aggressive yet have a sufficient control over scope they never seem to devolve into a chaotic death march.

It is much to simplistic to state that controlling scope (or, just understanding scope and changes) will fix a death march project. Sometimes, the scope is all-too-well known and that is part of the problem: it's too big to fit. Nevertheless, I think many such projects would benefit: it could move them out of the category or, at the very least, you will know what you are in for!

References

1. E. Yourdon, Death March. 2nd ed., Upper Saddle River, New Jersey: Prentice
   Hall, 2004.