- Death March Defined
- Categories of Death March Projects
- Why Do Death March Projects Happen?
- Why Do People Participate in Death March Projects?
- Summary
- Notes
Categories of Death March Projects
Not all death march projects are the same; not only do they involve different combinations of schedule, staff, budget, and functionality constraints, but they come in different sizes, shapes, and flavors.
In my experience, size is the most important characteristic that distinguishes one death march project from another. Consider four different ranges of projects:
-
Small-scale projects— the team consists of three to six people who are working against nearly impossible odds to finish a project in three to six months.
-
Medium-size projects— the team consists of 20–30 people, who are involved in a project expected to take one to two years.
-
Large-scale projects— the project consists of 100–300 people, and the project schedule is three to five years.
-
Mind-boggling projects— the project has an army of 1,000–2,000 or more (including, in many cases, consultants and subcontractors), and the project is expected to last seven to ten years.
For several reasons, the small-scale death march projects are the most common in the organizations that I visit around the world today; happily, they have the greatest chance of succeeding. A tightly knit group of three to six people is more likely to stick together through thick and thin, and this same group of highly motivated people is more likely to be willing and able to sacrifice their personal lives (as well as risk their health!) for three to six months if they know that the regimen of long nights, wasted weekends, and postponed vacations will come to an end in a matter of months.
The odds of successful completion drop noticeably with the medium-size projects and disappear almost completely with the large-scale projects. With larger numbers of people involved, it's more difficult to maintain a sense of cohesive team spirit; and the statistical odds of someone quitting, being run over by a beer truck, or succumbing to the various perils of modern society increase rapidly. What's crucial here is not just the number of people involved, but the time-scale: Working 80-hour weeks for six months may be tolerable, but doing it for two years is much more likely to cause problems.
As for the "mind-boggling" death march projects: One wonders why they exist at all. Perhaps the systems development efforts associated with the NASA project that landed a man on the moon in 1969 could be considered a successful example of a death march project; but the vast majority of such projects are doomed from the beginning. Fortunately, most senior managers have figured this out, and most large organizations (which are the only ones that could afford them in the first place!) have banned all such projects. Government organizations, alas, still embark upon them from time to time; along with potentially unlimited budgets with which to tackle truly mind-boggling projects, appeals to patriotic notions (e.g., "national security" in the post-9/11 era) may be sufficient to blind senior management to the futility of the task they've been given.
In addition to project size, it's also useful to characterize the "degree" of a death march project by such criteria as the number of user-organizations that are involved. Things are hard enough when the project team has to satisfy only one user or one group of homogeneous users within a single department. Enterprise-wide projects are usually an order of magnitude more difficult, simply because of the politics and communication problems involved in cross-functional activities of any kind. As a result, the systems development projects associated with business re-engineering projects often degenerate into a death march; even though the development effort is modest in terms of hardware and software effort, the political battles can paralyze the entire organization and cause endless frustration for the project team.
Finally, we can distinguish between projects that are incredibly difficult and those that are fundamentally impossible. As John Boddie, author of Crunch Mode, points out,
The combination of excellent technical staff, superb management, outstanding designers, and intelligent, committed customers is not enough to guarantee success for a crunch-mode project. There really are such things as impossible projects. New ones are started every day. Most impossible projects can be recognized as such early in the development cycle. There seem to be two major types: "poorly understood systems" and "very complex systems."[3]
This still leaves unanswered the questions of why a rational organization would embark upon such a project and why a rational project manager or technical person would agree to participate in such a project. We'll deal with those questions below.