What is a Death March Project and Why Do They Happen?
This chapter is from the book
This chapter is from the book
This chapter is from the book
Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing. One man may find happiness in supporting a wife and children. And another may find it in robbing banks. Still another may labor mightily for years in pursuing pure research with no discernible results.
Note the individual and subjective nature of each case. No two are alike and there is no reason to expect them to be. Each man or woman must find for himself or herself that occupation in which hard work and long hours make him or her happy. Contrariwise, if you are looking for shorter hours and longer vacations and early retirement, you are in the wrong job. Perhaps you need to take up bank robbing. Or geeking in a sideshow. Or even politics.
—Jubal Harshaw, in To Sail Beyond the Sunset
by Robert Heinlein (Ace Books, reprint edition, 1996)
What is a death march project? What makes IT organizations create such things? Why would anyone in his right mind agree to participate in such a project?
To many grizzled IT veterans, these are rhetorical questions. Everything, in their experience, is a death march project. Why do they happen? Because corporations are insane and, as consultant Richard Sargent commented to me, "Corporate insanity is doing the same thing again and again, and each time expecting different results."[1] And why do we participate in such projects? Because, as consultant Dave Kleist observed in an e-mail note, "Death march projects are rarely billed as such, and it takes a lot of work when being hired from the outside to discover if your hiring company is prone to creating death march projects."[2]
If you think the answers to these questions are obvious, feel free to jump to the next chapter. I'm sometimes think they are obvious, since most people never ask me what I mean by "death march." But if you're one of the people who has no idea what I'm talking about, or wonder if this is a book about military campaigns from World War II, it may be worth the effort to pause for a moment and contemplate what this is all about.
Death March Defined
Quite simply, a death march project is one whose "project parameters" exceed the norm by at least 50 percent. In most projects, this means one or more of the following constraints have been imposed upon the project:
-
The schedule has been compressed to less than half the amount estimated by a rational estimating process; thus, the project that would normally be expected to take 12 calendar months is now required to deliver its results in six months or less. Because of the competitive pressures of business competition in today's global marketplace, along with the concept of "Internet time" from the dot-com era of the computer industry, this is probably the most common form of death march project.
-
The staff has been reduced to less than half the number that would normally be assigned to a project of this size and scope; thus, instead of being given a project team of 10 people, the project manager has been told that only five people are available. This may have come about as a result of someone's naive belief that a new programming language or application development environment will magically double the team's productivity—despite the fact that the team was given no training or practice with the new technology and probably wasn't even consulted about the decision to use the technology in the first place. Unfortunately, it's happening far more often, as this edition of Death March is being written in the spring of 2003, because of the ongoing economic recession and the associated cutbacks in IT budgets.
-
The budget and associated resources have been cut in half. Again, this is often the result of downsizing and other cost-cutting measures, but it can also result from competitive bidding on a fixed-price contract, where the project manager in a consulting firm is informed by the marketing department that, "the good news is that we won the contract; the bad news is that we had to cut your budget in half in order to beat out the competitors." This kind of constraint often has an immediate impact on the number of project team personnel that can be hired, but the consequences are sometimes a little more subtle—e.g., it may lead to a decision to hire relatively inexpensive, inexperienced junior software developers, rather than higher-cost veterans. And it can lead to a pervasive atmosphere of penny-pinching that makes it impossible for the project manager to order pizza for the project team when they spend the entire weekend in the office working overtime.
-
The functionality, features, performance requirements, or other technical aspects of the project are twice what they would be under normal circumstances. Thus, the project team may have been told that it needs to squeeze twice as many features into a fixed amount of RAM or disk space as its competitor; or it may have been told its system has to handle twice the volume of transactions that any comparable system has ever accomplished. The performance constraints may or may not lead to a death march project; after all, we can always take advantage of cheaper, faster hardware, and we can always search for a more clever algorithm or design approach to accomplish the improved performance. But doubling the functionality—i.e., the available features—usually means doubling the amount of work that has to be carried out; that does lead to a death march project.
The immediate consequence of these constraints, in most organizations, is to ask the project team to work twice as hard and/or twice as many hours per week as would be expected in a "normal" project. Thus, if the normal work-week is 40 hours, then a death march project team is often found working 14-hour days, six days a week. Naturally, the tension and pressure escalate in such environments, so that the death march team operates as if it is on a steady diet of Jolt cola.
Another way to characterize such projects is as follows:
A death march project is 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 Š 50 percent.
Of course, even a project without the schedule, staff, budget, or functionality constraints described above could have a high risk of failure—e.g., because of hostile politics between the IT department and the user community. But most commonly, the reason for the high risk assessment is a combination of the constraints described above.