What is a Death March Project and Why Do They Happen?

This chapter is from the book

Death March, 2nd Edition

Learn More Buy

This chapter is from the book

This chapter is from the book 

Death March, 2nd Edition

Learn More Buy

Why Do Death March Projects Happen?

If you think about what goes on in your organization, it's not difficult to understand why death march projects occur. As Scott Adams, author of the incredibly popular "Dilbert" cartoons, points out,

When I first started hearing these stories [about irrational corporate behavior] I was puzzled, but after careful analysis I have developed a sophisticated theory to explain the existence of this bizarre workplace behavior. People are idiots.

Including me. Everyone is an idiot, not just the people with low SAT scores. The only difference among us is that we're idiots about different things at different times. No matter how smart you are, you spend much of your day being an idiot.^[4]

Perhaps it's too depressing to imagine that you're an idiot and that you're surrounded by (and managed by!) idiots. Or perhaps you consider it an insult that someone would even make such a suggestion. In that case, Table 1.1 shows a more detailed list of reasons for the occurrence of death march projects:

Table 1.1. Reasons for Death March Projects

While the items in Table 1.1 may seem obvious, they do need to be discussed—because they may indicate that your death march project is so crazy and irrational that it's not worth participating at all. Indeed, even without an explicit rationale of the sort shown in Table 1.1, you should seriously consider whether you want to spend the next several months (or years) attached to such a project; we'll discuss that separately later in this chapter.

Politics, politics, politics

Many software developers vow that they won't get involved in politics—partly because they've learned that they're not very good at playing political games, but also because they feel that everything about politics is repugnant. Alas, politics cannot be avoided: As soon as two or more people participate in some joint enterprise, politics are involved.

But when politics becomes the dominant "driving force" in a large, complex project, the project is likely to degenerate into a death march. Remember my definition of a death march project: It's one where the schedule, budget, staff, or resources are 50–100 percent less than what they should be. Why are these constraints being placed on the project? There are many possible explanations, as we'll see in the discussion below; but in many cases, the answer is simply, "Politics." It may be a power struggle between two ambitious vice presidents in your organization, or the project may have been set up to fail as a form of revenge upon some manager who stepped on the wrong toes at the wrong time. The possibilities are endless.

There is little chance that you'll get the politicians to admit what's going on; however, if you're a technical staff member, it's not unreasonable to ask your project manager whether the entire death march project is a political sham. Even if you don't like politics, and even if you think you're a political neophyte, listen carefully to the answer your manager gives you. You're not stupid, and you're not that naive. If you have a sixth sense that there's some ugly politics dominating the entire project, chances are you're right; and if your immediate supervisor gives a naïve, ambiguous, or thoroughly unconvincing answer to your questions, you should draw your own conclusions. To put it another way: If your project sounds like something straight out of a "Dilbert" cartoon, chances are that it will be the kind of death march project in which no rational person would want to be involved.

What if your manager openly agrees with you? What if he or she says, "Yes, this whole project is nothing more than a bitter power struggle between Vice Presidents Smith and Jones…"? If that's the case, then why on earth is your manager participating in the project? As we'll see in the section about why people participate in death march projects, there may be many reasons; but your manager's reasons are not necessarily your reasons. The existence of ugly politics doesn't necessarily mean that you should abandon the project or quit your job right away, but it does mean that you should keep your own priorities, objectives, and sense of ethics separate from what's going on in the project—for it's quite likely that many of the decisions that take place (beginning with the schedule/budget/resource decisions that defined the project as a death march in the beginning!) are not being made with the best interests of the end-user or the enterprise in mind. If the project succeeds at all, it's likely to be an accident—or it may be because the intended victim (who may be your project manager, but may also be a manager several levels above your immediate manager) is a more clever politician than the opposition counted on.

Naive promises made by marketing, senior executives, naive project managers, and so on

Naiveté is often associated with inexperience; thus, it's common to see unrealistic commitments made by people who have no idea how much time or effort will be required to build the system they want. In the extreme case, this can lead to what my friend and colleague Tom DeMarco calls "hysterical optimism": Everyone in the organization desperately wants to believe that a complex project, which has never been attempted before but which has been realistically estimated to require three calendar years of effort, can somehow be finished in nine months.

The naiveté and optimism extends to the technical staff, too, as we'll see below. But for the moment, let's assume that it's your manager, or your marketing department, or the end-user who is responsible for the naively optimistic schedule or budget. The question is: How will they react when it eventually becomes clear that the initial commitments were optimistic? Will they extend the schedule, increase the budget, and calmly agree that things are tougher than they had imagined? Will they thank you for the heroic efforts you and your colleagues have made up to that point? If so, then it may turn out that the most important thing you need to do is avoid the classical waterfall life cycle, so that a realistic assessment of schedule, budget, and resources can be made after the first prototype version of the system is delivered.^[5]

But in many death march projects, this kind of rational mid-course correction isn't possible. This can happen, of course, if a senior manager makes a naive promise to the customer, and then feels that the commitment has to be honored—no matter what. In the worst case, the person making the commitment knows full well what's going on: It's particularly apparent when the marketing manager confesses to the project manager over a beer after the celebrations accompanying a new contract from some gullible client, "Well, we wouldn't have gotten this contract if we told the client how long it will really take; after all, we knew that our competitors would be coming with some really aggressive proposals. And besides, you guys always pad your schedules and budgets anyway, don't you?"

The last comment is especially onerous if it comes from your boss, or from some manager two or three levels above you. Obviously, it suggests that the entire process of estimating schedules and budgets is a negotiating game, which we'll discuss in more detail in Chapter 3. But there is also likely to be some degree of naiveté, for the unspoken implication in your manager's complaint about "padding" the schedule and budget is that you could finish the death march project in time to meet the ridiculous deadline that has been imposed upon you. On the other hand, it could have something to do with the "Marine Corps" mindset that I'll discuss in that upcoming section. Similarly, the commitment to a ridiculous schedule and budget by the marketing department could turn out to be another form of politics, discussed earlier; that is, the marketing representative probably doesn't care whether the schedule and budget he proposed is ridiculous or not, because his primary objective is his sales commission, or meeting his quota, or pleasing his boss, etc.

Assume for the moment that the death march project has been created as a result of "pure" naiveté, absent of politics or other malicious influences. The question is: What should you do about it? As noted above, a key question is the probability that the decision-makers will revise their budgets and schedules when it becomes apparent that the original commitments can't be met. This is difficult to predict in advance, though it wouldn't hurt to check around and see what has happened to other death march projects in similar situations. (If this is the first such project that has ever occurred in your company, then you really are in uncharted territory!)

If you have the strong impression—either from your political instincts, or from the experiences from previous projects in your organizations—that management will hold fast to its original budget and schedule, no matter how much of a "denial of reality" is involved, then you need to make a much more fundamental decision about whether to proceed or not. Some of this involves the extent to which you can negotiate other aspects of your project—e.g., the technical staff that will be assigned to the project—which we'll discuss in Chapter 2.

Naive optimism of youth: "We can do it over the weekend"

Though management is a convenient scapegoat for many of the idiotic decisions associated with death march projects, the technical staff is not entirely blameless. Indeed, in many cases senior management will happily admit its naiveté and lack of experience with the process of estimating and scheduling complex projects. "How long do you think it will take?" a vice-president will ask the technical hot-shot, who may have been promoted to the rank of first-level supervisor just last week.

And if the technical hot-shot is ambitious and filled with youthful optimism (which usually borders on the teenage delusions of immortality, omnipotence, and omniscience) the answer is likely to be, "No problem! We can probably knock it out over the weekend!" A really good software engineer—well, "hacker" might be a more appropriate description here—is firmly convinced that he or she can develop any system in a weekend. Minor details such as documentation, error-handling, editing of user inputs, and testing are so boring that they don't count.

If you're the naively optimistic software engineer responsible for making the death march estimate, chances are that you don't even know what you're doing. You probably read the paragraph above, bristled at the apparent insult, and muttered, "Damn right! I really can build any system over the weekend!" God bless you; maybe you'll succeed. In any case, nothing that you hear from an old fart like me is likely to change your mind.

But if you are a battle-scarred veteran, and you can see that you're about to be roped into a death march project because some naive young technical manager has made a ridiculously optimistic commitment regarding the project's schedule, budget, and resources—what should you do? The best advice, I think, is "Run!" When such technical managers realize that they are in over their heads, they often collapse into truly irrational behavior or paralysis. In most cases, they haven't dealt with anything before that was so big and complex that it couldn't be overwhelmed by sheer cleverness or brute force (e.g., 48 hours of nonstop coding over the weekend). In any case, they're certainly not in the mood to hear you say, "I told you so!" as their project falls behind schedule.

The "startup" mentality of fledgling entrepreneurial companies

I've not only watched this occur, I've participated in such projects and have been responsible for initiating them in several cases. Shortly after the first edition of this book was published, it appeared that any startup company with "dot-com" in its corporate name or product name could get more venture capital than it knew what to do with. But as became clear to the venture capitalists and hopeful investors, startup organizations are generally understaffed, underfinanced, undermanaged, and hysterically optimistic about their chances of success. They have to be: A cautious, conservative manager would never dream of starting a new company without tons of careful planning and a large bank account to deal with unforeseen contingencies.^[6]

So, almost by definition, a large percentage of the projects associated with startup companies comprises death march projects. And a large percentage of these projects will fail; a large percentage of the companies will fail with them. C'est la vie—that's what high-tech capitalism is all about (not only in the United States, but all over the world). Having been raised in this culture all my life, I think it's perfectly normal; my attitude is also biased by the fact that I've been lucky enough to succeed in a few such ventures. Indeed, this scenario is often one of the positive reasons for embarking upon a death march project, as I'll discuss in more detail in that section below.

But not everyone is familiar with the culture and environment of a corporate startup. If you've spent the past 20 years of your career working with brain-dead COBOL zombies in a moribund government agency (or in, for that matter, most banks or insurance companies or telephone companies) and you've just taken a job with a startup firm because you were downsized, outsourced, or given an early retirement, then you probably have little or no idea what you're in for. Death march projects occur in big companies, too, but they're often staffed by cast extras from Night of the Living Dead. The environment is completely different in startup-company death march projects; it's like a rush of pure adrenaline.

At the same time, the startup companies often suffer from the kind of naive optimism discussed earlier. Many startup companies are founded by technical hotshots convinced that their new technology will make them richer than Bill Gates; other such companies are founded by marketing wizards who are certain they can sell Internet-enabled refrigerators to gullible Eskimos. Optimism is important in any startup venture, and the success of the corporate venture may depend on doing what nobody has ever been able to do before; but even an aggressive, optimistic startup company has to obey basic laws of physics and mathematics. If you get involved in a startup-company death march project, check to see whether there is some kind of plan for success, or whether the whole venture is based on wishful dreaming.

The "Marine Corps" mentality: Real programmers don't need sleep

Startup companies are sometimes vulnerable to the "Marine Corps" syndrome, but I've seen it most often in the consulting organizations like EDS and the Big-X^[7] accounting firms. It may reflect the personality of the corporate founder(s), and it may reflect the corporate culture in its earlier days—the corporate behavior at Microsoft, for example, has often been attributed to these factors. In essence, you'll be told by the appropriate manager, "Every project is like this, because that's how we do things around here. It works, we're successful, and we're damn proud of it. If you can't handle it, then you don't belong here."

Whether an attitude like this is civilized, humane, or right is a topic for a separate discussion. Indeed, the question of whether it's even successful is something to be discussed elsewhere; the important thing is to realize that it's deliberate, not accidental. If you're a martyr or a revolutionary, you might decide to attack the corporate culture, but the chances are that you won't succeed. It's quite possible that there will be some negative long-term consequences of the overall death march culture, for example, the best people may slowly drift away and the company may fail. But when it comes to this death march project, there's no point questioning why it has been set up with a nearly impossible schedule and budget. As the prototypical manager of such companies says, "If you can't handle it, then you don't belong here."

Sometimes there's an official rationale for such corporate behavior—for example, "We compete in a tough marketplace, and all of our competitors are just as smart as we are. The only way we succeed is to work twice as hard." And sometimes the death march projects are set up to weed out the younger (weaker) junior employees, so that only the survivors of the death march projects will reach the exalted status of "partner" or "vice president." Whatever the rationale, it's usually fairly consistent; there's not much point complaining about it for the sake of a single project.

That doesn't necessarily mean that you should accept an assignment on such a project; after all, just because every other project within the organization is a death march doesn't necessarily mean that yours will succeed, or that you will survive. It simply means that the decision to create such a project has an understandable origin.

Intense competition caused by globalization of markets

Organizations that might not have tolerated death march projects in the past are sometimes forced to do so in the 21st century, simply because of the increased level of competition associated with the global marketplace. The secondary factors here are the Internet and the Web, as well as governmental decisions to open previously protected markets or eliminate tariffs and quotas.

For some organizations, this is not a new phenomenon; the automobile and electronics industries, for example, have been facing stiff competition since the 1970s. But for other organizations, the appearance of European or Asian competitors in the North American marketplace can come as a rude shock. Once senior management has accepted the reality of serious competition, it may decide to embark upon a variety of radical moves, ranging from downsizing to outsourcing the entire IT organization to the other side of the world; it may also decide to compete head-on with a new product or service that requires a new, ambitious system to support it. Voila! A death march project has begun.

A relatively recent version of this globalization phenomenon is the outsourcing of software development projects to "offshore" organizations in India, China, Russia, or other countries. Having visited software organizations in several of these countries, I can testify that such organizations are typically not "sweat shops" that engage in the kind of death march projects that require their programmers to work 16 hours a day, seven days a week. Nevertheless, the presence of lower cost offshore programming resources may cause domestic software companies and IT departments to respond by making their higher priced programmers in the United States work longer hours. As one reader suggested to me in a recent email message:

"I see things getting worse. With the trend of outsourcing software development work overseas to dramatically cut labor costs, the remaining domestic software houses will suffer tremendous competitive pricing pressures. The only way to compete will be to get your product on the market first and cut costs. 'Deathmarch' may become standard procedure for many companies. An improving economy won't change these market realities."^[8]

Intense competition caused by the appearance of new technologies

Competition from an expanded marketplace is often perceived as a defensive issue, but it can also be perceived as an aggressive, proactive opportunity—"If we build this new system, with double-byte characters, then we can offer our company's products for sale in Japan." Similarly, the introduction of radically improved technology may cause a defensive response from a company that was reasonably happy with products built around an older technology; or it may lead to a proactive decision to utilize the new technology for competitive advantage. At the time this book was being written, technologies such as wireless computing and Web services were obvious examples of this phenomenon; but the amazing thing about our industry is that new examples appear every couple of years.

If the corporate response to the new-technology situation is essentially defensive in nature, then the death march project may be one that seeks to exploit the company's old technology far beyond its normal limits. Thus, if the organization has too much invested in the old technology (and the infrastructure surrounding it) to abandon it entirely, it may embark upon a rewrite of its old systems, with demands that the programmers find a way to make it ten times faster and sexier.

But many death march projects in this category are the ones that involve first-time usage of the new technologies. Think back to the first client-server projects, object-oriented projects, relational database projects, or Internet/Java projects in your organization; some of them may have been modest experiments to explore the potential benefits of the technology, but some of them were probably created as a competitive response to some other company's introduction of the same technology. And in the latter case, these projects can be huge, as well as being saddled with outrageously aggressive schedules and budgets.

But what really contributes to the death march nature of such projects—beyond the obvious characteristics of size, schedule, and budget—is the attempt to use bleeding-edge technology for an industrial-strength application. Even if the technology is basically usable, it often does not scale up well for large-scale usage; and nobody knows how to exploit its strengths and avoid its weaknesses; and the vendors don't know how to support it properly; and on and on...

While all of this may be perceived as an unpleasant experience by the older technical project team members (the ones who remember the "good old days" of FORTRAN II and assembly language), it's important to remember that the younger technicians and project managers prefer these new technologies, precisely because they are new. And these are the same folks whom I characterized above as naively optimistic about the schedule and budget constraints within which they're working. Is it any wonder that things degenerate into a death march project, with everyone working late nights and long weekends in order to coax the experimental new technology into some semblance of working order?

Intense pressure caused by unexpected government regulations

As noted above, one of the reasons for death march projects associated with globalization of markets is the decision by governmental authorities to reduce tariffs, eliminate import quotas, or other such decisions to "open" a previously closed market. But this is just one example of governmental influences that can lead to a death march project; deregulation of controlled industries, or privatization of government agencies are two other obvious examples. Indeed, many of the death march projects taking place today around the world are a direct result of a government decision to deregulate the telecommunications industry, the financial services industry, the airline industry, and so on.

However, there are also many instances of increased regulatory pressure from governmental authorities—especially in the areas of taxation, reporting of financial details to stock-market authorities, environmental regulations, and so forth. In any kind of democratic society, there's likely to be a great deal of advance notice about such regulations, because the legislative body argues and debates and fusses over details for months or years before the relevant legislation is enacted. But the details often aren't clear until the last moment, and the typical reaction from senior management is to ignore the whole thing until it become an unavoidable reality. And then, boom! Another death march project is created.

The particularly onerous thing about many of these government-mandated death march projects is the deadline: The new system must be operational by some arbitrary date such as January 1st, or fines of a million dollars a day will be imposed. There may be an opportunity to ask for an extension or a waiver, but in most cases, the deadline is absolute. And the consequences are usually as dire for the organization as those mentioned above: Layoffs, bankruptcy, or other calamities will occur if the new system isn't finished on time.

Notice that in projects like these, technology is usually not the issue; what characterizes the projects as death march in nature is the aggressive timetable. Of course, management sometimes complicates the situation by understaffing the project or hobbling it with an inadequate budget.

Unexpected and/or unplanned crises

Your two best programmers have just marched into your office to inform you that (a) they're getting married, (b) they're joining a missionary group building hospitals in the jungles of Africa, and (c) today is their last day on the job. Or your network services manager calls you to say that your vendor has just gone bankrupt and you'll have to reprogram everything in the next 30 days in order to use another vendor's network protocol. Or your legal department calls to say that the company has been sued by ten zillion dollars because the company is not in compliance with Sub-paragraph 13(b) or Regulation Q of some arcane tax code that nobody even knew about.

Of course, you could argue that, in a well-managed company, the impending departure of your two best programmers would have been anticipated and planned for; and you wouldn't have been so silly as to be wholly dependent on one telecommunications vendor; and management would have had the foresight to check into the details of Regulation Q. Such crises, according to the purists, are the result of poor planning and poor management; an "unplanned crisis" is therefore an oxymoron.

Perhaps so; but as a practical matter, it's becoming increasingly difficult to anticipate and plan for all the crazy things that can happen in the business world today. For better or worse, we live in a world of chaos, and death march projects are a natural consequence of such chaos.^[9] Indeed, even if we have a general idea that chaotic things could occur in the future, we may still have to respond to them in a death march fashion. Everyone in the vicinity of the San Andreas fault in California, for example, knows that a truly massive earthquake will occur sooner or later; but that won't prevent a rash of death march projects from starting up the day after the "big one" drops the western half of the state into the Pacific Ocean.

Indeed, even when we know precisely when a crisis will occur, it often leads to a death march project—because management's tendency is to avoid dealing with the situation until the last possible moment. How else could we explain the panic that crept into many IT organizations as the Y2K problem loomed ahead of them? We had known for a long time that January 1, 2000, was coming, and it was obviously a deadline that could not be postponed. We knew precisely what the nature of the problem was, and it didn't require newfangled technologies such as Java. So why did so many Y2K death march projects get launched in 1998 and 1999?

In any case, unforeseen crises can lead to all kinds of death march projects. In the worst case, they create projects for which the deadline is "yesterday, if not sooner"—because the crisis has already occurred and things will continue to worsen until a new system is installed to cope with the problem. In other cases, such as the unplanned departure of key project personnel, it can turn an otherwise rational project into a death march exercise because of the shortage of manpower and the loss of key intellectual resources.

For various reasons, these often turn out to be the worst kind of death march projects, because nobody anticipated that they would turn out this way. For the Marine Corps situation discussed above, there are no surprises: Everyone knows from the first day of the project that this one, like all previous projects, is going to require extraordinary effort. And for the startup companies, the death march project is anticipated with excitement; not only will it be exciting and challenging, but its success could make everyone rich.