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 People Participate in Death March Projects?

The theme of the discussion in the previous project is that organizations create and/or tolerate death march projects for a number of reasons. We may agree or disagree with those reasons, and we may sympathize with the ones caused by truly unexpected crises—but ultimately, as individuals, we have to accept them as a fact of life.

But that doesn't mean we have to participate in them. Most of this book presumes that you will participate in a death march project, though I will specifically suggest that you resign under certain circumstances. But the best time to do so, in most cases, is at the beginning. When told that you have been assigned to such a project (either as a leader or a technical staff member), you should consider saying, "No, thanks! I'll pass on this one." If that's not an acceptable response within your corporate culture, you almost always have the option of saying, "No, thanks! I quit!"

Obviously, some developers—and probably a larger number of managers—will argue that this is not a practical choice for them. I'll discuss this in more detail below, but for now it's sufficient to note that it's one of several possible "negative" reasons for participating in a death march project; it may not be fun, but perhaps it's not as bad as the alternatives. On the other hand, some developers (and some managers) gladly sign up for such projects; aside from the issue of naive optimism discussed above, why would any rational person volunteer to participate in a project that's likely to require 14-hour days, seven-day weeks, and a year or two of postponed vacations?

The most common reasons are summarized in Table 1.2; I'll discuss them in more detail below.

Table 1.2. Reasons for Participating in Death March Projects

By the way, this is not intended as a complete list; Kevin Huigens^[10] asked his project team to do a little brainstorming at one of their recent staff meetings, and they came up with the following list (Table 1.3):

Table 1.3. More Reasons for Participating in Death March Projects

Of course, all of this assumes that you know in advance that it is a death march project. As consultant Dave Kleist^[11] observed to me, that's not always so easy when you're interviewing for a new job:

...it's rarely printed as part of the want ad. Not much sense in saying, "Are you interested in working incredible hours for no additional benefit beyond your hiring salary?"... Seriously, 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.

And, as Steve Benting^[12] pointed out to me, sometimes you get taken by surprise:

...it seems to be a well-thought-out project this time. You've got someone leading who has a real sponsor in management, the project plan appears to be solid, the people involved all appear to be good. Hell, you want to work on this thing. Then it collapses because your sponsor gets taken out in a political struggle, the project plan turns out to be built on assumptions that are incorrect, and one or two key people turn out to be flaky. You can learn to watch out for them, but sometimes you misjudge. And you don't want to believe that it's happening again.

The risks are high, but so are the rewards

The startup-company scenario discussed in an earlier section is a good example of this situation. If you tell project team members that the success of their project will mean the company can go public, and that their stock options will make them instant millionaires, they'll happily work until they drop from exhaustion. They realize—at least in an intellectual way—that there are risks associated with the venture; but since many of them still believe that they're immortal and omnipotent, they don't pay much attention to the risks.

Indeed, considering the influences of Western culture (especially in the United States), it's not at all surprising to see young software developers voluntarily sign up for death march projects. We've been told in countless ways that the success of movie stars, rock singers, sports heroes, and Olympic athletes, as well as business executives and software entrepreneurs, depends largely on tireless energy, enormous commitment, long hours, and personal sacrifice. We never hear about the guile and duplicity, the shady deals and illegal activities, that are sometimes associated with success. And we rarely hear anything about luck and the importance of being in the right place at the right time; Bill Gates, for example, certainly exhibits all of the textbook characteristics of a successful business executive, but if a group of IBM executives hadn't shown up in Seattle in 1980 to look for a PC operating system, and if Gates hadn't been available when IBM was unable to meet with its originally intended OS contractor ... well, who knows where Microsoft would be today?

And one more thing: We don't hear enough about the real consequences of the "sacrifice" that a death march project usually requires—sacrifices, that is, in the area of personal health, mental health, and personal relationships. None of this is likely to matter very much to a 22-year-old technical person; and it often doesn't matter to the introverted, anti-social people who are attracted to the computer field. On the other hand, it's small wonder that you'll find fewer people in their mid-40s and 50s volunteering for death march projects; not only have they learned that most such projects really are doomed to fail, but they've also learned (usually the hard way!) that it's not worth sacrificing their marriage and their relationship with their children.

Ultimately, this is a personal choice, based on personal values; I'm no position to tell anyone else what's right or wrong. I should emphasize, though, that I'm not as negative as one might think from the comments above. Though I'm much less naive than I was when I entered the computer field in the mid-1960s, I'm still attracted by entrepreneurial opportunities. Show me a sufficiently exciting risk/reward formula, and I'll sign up for yet another death march...

By the way, sometimes the rewards are psychological, not financial. As Sharon Marsh Roberts^[13] observed to me,

The "heros" are needed, wanted, desired. They are certain of their place in history, if only they can keep this project from outright sinking under its own weight.

The same people take on EMT work and enjoy firefighting (literally). If you only win once in ten times, but everybody else lost all ten, wouldn't you be a hero, too?

And as Paul Neuhardt^[14] put it,

For me, it was ego, pure and simple. They told me that they just knew I could help prevent the project from becoming a death march. I was made the "technical project manager," given ego boosts on a regular basis, then hung out to dry along with the rest of the team. Left, right, left, right, left, plop!

The "Mt. Everest" syndrome

Why do people climb dangerous peaks like Mt. Everest, despite the pain and the risk? Because it's there. Why do people run a marathon and drive themselves to the point of physical collapse in triathlons? Because of the challenge. It's all the more exciting if the challenge is one that has never yet been successfully accomplished; of the six billion people on the planet, for example, only one can stand before us and say, "I was the first to walk on the moon." Some may think it's crazy, egotistical, and selfish to even try; but others are willing to brave the odds and deal with horrendous obstacles for the private thrill and the public glory of succeeding. As consultant Al Christians^[15] remarked to me in a recent e-mail note,

I am somehow prompted to reply "testosterone," which is about the same as "because it's there." There are plenty of jobs that raise the 'why?' question. Underground mining, cowboying, logging, smoke jumping, jet fighting, submarining, even high-rise window washing all have serious drawbacks far beyond what you describe for software projects, and yet all these have practitioners whose sense of self is linked to their profession.

And so it is with death march software projects. I had the chance to visit the original Macintosh project in the fall of 1983, a few months before the product was officially unveiled, and was humbled by the intensity of the team's commitment to its challenge. In addition to whatever other reasons the members might have had for working long hours and dealing with Steve Jobs' megalomaniacal ego, the team was utterly convinced (partly as a result of Jobs' charisma) that the Macintosh would revolutionize personal computing. They were lucky—they turned out to be right.

From this perspective, even the death march projects that fail can be noble failures. Countless projects in Silicon Valley have fallen into this category, often after burning tens of millions of dollars of venture capital; while most of the dot-com startups had no substance at all, some of them really did seem awe-inspiring and revolutionary until they went into bankruptcy. But even though they failed so badly that entire companies went bankrupt, and though they caused divorces, ulcers, and nervous breakdowns—even though they did all of this and more—the people who worked on those projects still speak of their experiences in hushed tones. "I worked on the Toys.com system," a grizzled veteran will tell her awe-struck apprentice. "Now that was a revolutionary piece of software!"

Though it may never reach the front pages of Computerworld, there are also numerous death march projects with lofty ambitions buried within large organizations—with application developers signing up gladly because the "corporate Mt. Everest" seems such a worthy challenge. Sometimes these projects fail because the marketplace or the corporate end-users don't want and don't need the glorious, revolutionary systems being developed; and sometimes they fail because the project team bit off more than it could chew and promised more than it could deliver.

There are two things to watch for if you find yourself being swept up in the hysteria of a Mt. Everest-style death march project. First, watch out for the projects that are predetermined failures. Suppose, for example, that someone told you that you could be on the first manned mission to Mars, and that you would even have the honor to be the first person to plant a foot on Martian soil. "Of course," your project manager goes on to say, "you won't have any oxygen tanks, because we won't have enough room on the space craft for all that extra weight. So it's a guaranteed fact that you're going to die—but think of the honor and the glory!" I'll discuss these projects in more detail in Chapter 3, under the heading of "kamikaze" projects; for now, the scenario speaks for itself.

The second thing to watch out for is that the challenge being described by your corporate management (or by the entrepreneurial founder of your software company) may not turn out to be such a big deal after all. This is a particularly insidious danger if the challenge is technical in nature, for example, "We'll be the first people on earth to put an operating system with the functionality of Windows XP into 128K of ROM!" Granted, that would be an amazing technical accomplishment—but so what?

It's a good idea to ask the "So what?" question two or three times—in other words, continue asking the question in response to each successive answer you get from your corporate management. If the response to the Windows XP scenario posed above is, "Well, that means we could put all of Windows XP onto your wrist watch!", then ask, "So what?" again. In some cases, the answers will eventually become silly and you'll be jerked back into the real world. For example, suppose your boss answers the second "So what?" question above with the explanation, "Well, if we can also squeeze in a full voice-recognition system, that means you'll be able to write Visual C++ programs while you're walking down the street, by talking to your wrist-watch!"

No doubt there are a few dozen programmers who would say, "Cool!" and volunteer to spend the next three years of their lives on such a project. The fact that nobody in his right mind would ever use such a project is irrelevant to them; the technical challenge is a sufficient justification. Putting Windows XP, full voice recognition, and Visual C++ into 128K of ROM would give you supreme bragging rights at any convention of hackers and programmers; if that's what you live for, then by all means go ahead and sign up for the project.

It's also a good idea to explain the project in simplified non-technical terms to your spouse, or your "significant other," or your parents—or, even better, your children. They will ask the "So what?" question, without the burden of being tempted by the technical challenge. "You're going to give up your nights and your weekends and your vacations for the next two years in order to put Windows XP on a wrist-watch?" your spouse will ask incredulously. And your children will ask, "Yeah, but Mom/Dad, why would anyone do that?" If you can answer those questions without feeling utterly foolish, then you can sign up for the project with a clear conscience.

A worse form of Mt. Everest project is the one where the challenge matters enormously to corporate management, but not at all to anyone who stops and thinks about the situation for a second. "Why are we signing up for this death march project, boss?" the young programmer asks innocently. "Because," the boss thunders righteously, "it will increase our corporate earnings per share by a full 3.14159 cents!!" This means that if the programmer was lucky enough to have options on a hundred shares of the company's stock, and if every penny of increased earnings was paid out in dividends, the programmer would get a whopping $3.14; and if Wall Street traders got so excited by all of this that they boosted the price of the stock by a dollar, the programmer's net worth would increase by another hundred dollars. "And what else would I have to show for the thousands of hours of overtime you're asking me to sign up for, boss?" the young programmer asks. The boss is silent, for he knows that the honest answer is: nothing. The project is intrinsically boring, involves no interesting technology, and has a 75-percent chance of failing anyway.

But the very worst death march projects, in my opinion, are the ones where the boss deliberately manipulates the innocent project team into believing that a Mt. Everest-style challenge is involved, when the boss knows full well that it's not. Imagine the project team member who asks, "Why are we trying to build this batch, mainframe, COBOL airline reservation system in six months, boss?" The boss is likely to respond, "Because nobody in the entire airline industry has ever tried to do it in less than three years before!" I suppose that one could argue that there is a technical challenge involved in creating a batch-mode airline reservation system, but it's not the kind of technology that I would want on my resumé in the 21st century. In any case, what makes this scenario a death march project is not the technical challenge, but the ridiculous schedule imposed on the project. Why is the project manager doing it? Who knows—but it's not likely to be the sort of thing you'll want to brag about to your friends a year from now.

The naiveté and optimism of youth

Ours is a young industry, and many of the most exciting and challenging projects are being performed by, and led by, people in their twenties. It's not at all uncommon to see death march projects where the entire technical team is under 25, and where the majority are in the 21–23 age range. As such, they remind me of the fighter pilots and bombing crews recruited by the Air Force in the Gulf War: like Tom Cruise's character in Top Gun, they are young, idealistic, and absolutely convinced that they could do anything. As David Maxwell^[16] put it:

…projects are like a marriage. We tend to start off naively and full of hopes and slowly as reality sets in, we have to re-assess our expectancies within the relationship. There are many reasons apart from logic that attract people together into a marriage and it is the same case with projects. With a predominantly youthful workforce, it is likely that the "death march" project will occur again and again as a training ground for managers and developers alike. And, as I know from personal experience, I often repeat the same mistake many times before the penny drops.

Indeed, it's this supreme confidence that enables a death march team to succeed where traditional project teams have failed before. Part of the folklore of our industry is that the most successful products—ranging from Lotus 1-2-3 to the original Netscape Navigator Web browser—have been developed by a handful of people under conditions that no "rational" project team would have accepted. When these projects succeed, they often bring fortune and fame to the project team; and when they fail, they often provide some valuable lessons to everyone involved (though the corporate consequences may still be disastrous!).

It's important to note that the naiveté and optimism of youth are usually combined with enormous energy, single-minded focus, and freedom from such distractions as family relationships. Obviously, youth doesn't have a monopoly on any of this, but it's a lot more common to see a 22-year-old programmer willing and able to focus on the technical demands of a death march project for 100+ hours per week continuously for a year or two, than a 35-year-old programmer with a spouse and two children and a moderate passion for mountain climbing. The young programmer who signs up for a death march—as well as the relatively young project manager who optimistically promises success to the corporate chieftains—is implicitly saying, "Of course I'll succeed with this project; I'll overwhelm the obstacles with sheer energy!"

I won't make any value judgments about all of this, because it's pointless. As noted above, ours is an industry that attracts young people, and I don't think that will change in the next few years. I also think it's unlikely that young people will abandon their optimism, energy, and ability to focus single-mindedly on a problem. As for their naiveté ... well, it doesn't help much for battle-scarred veterans to accuse their younger colleagues of this disease.

The alternative is unemployment

Because we do have an industry populated by young, optimistic people, and because it's a vibrant industry that has been growing steadily (and sometimes rapidly!) for the past 30-40 years, I'm sometimes surprised to hear this explanation for participation on death march projects.

But even our industry has its downturns and recessions. As this edition of Death March was being written in the spring of 2003, the high-tech recession had been underway for roughly three years—with no obvious indication of when it would end. And for those too young to remember, there were also downturns in the early 1990s, the early 1980s, and the mid-1970s.

We're also an industry where rapid change renders some veterans obsolete. Indeed, there has been such enormous change during this decade that our profession—like so many other white-collar professions—has experienced significant downsizing, re-engineering, and outsourcing. Aggregate employment in the software industry may be rising steadily, but we sometimes forget that this means only that the C++ programming jobs are increasing more rapidly than the COBOL jobs are declining. In addition, the large IT shops that have expanded into bureaucracies of several thousand people have been particularly vulnerable to downsizing and outsourcing; senior management may not be ready to reduce the ranks of technical staff, but they're often eliminating the middle managers, administrators, and staff people.

All of this becomes a factor in death march projects. The reason your project team has only half as many people as it should have is that management has cut the entire software organization in half. And the reason that your project schedule is twice as demanding as it should be is that management is attempting re-engineering by edict: It has announced that the entire organization needs to be twice as productive as before, which translates into simple commands of "Work harder! Work faster!"^[17]

This is not a book about re-engineering, and I don't want to comment on the re-engineering strategies employed by management. The significant issue here is that many technical staffers and many project managers feel an implied threat when projects are created in this kind of environment: If they don't agree to the death march project parameters, they'll be the ones to lose their job. For the 22-year-old, unmarried programmer, this shouldn't be a problem; for the 35-year-old project supervisor with a family and a mortgage, it can be a more serious problem. And for the 45-year-old programmer whose only skills are COBOL and CICS, it can be a serious problem indeed. Even though we do have a young industry, it's been around long enough that there are even some 55- and 60-year-old programmers who are grimly holding on until their pension is fully vested.

It's also common for middle-aged or older people to find that they're locked into a community, because their spouse has a job in the same town, or their children can't be pulled out of the local schools, or because the prospect of leaving behind aging parents and other family members is too painful. None of this seems a problem when the job market is growing, but anyone who lived in Poughkeepsie, New York, in the early 1990s knows exactly what I'm talking about. People living in Redmond, Washington, could conceivably find themselves faced with the same kind of rude shock five, 10, or 20 years from now.

I'm generally sympathetic to the middle-aged and older software professionals who find themselves in this position, though the re-engineering/downsizing phenomenon has been around long enough that I'm amazed to find technical people who ignore the possibility that it could happen to them. But this, too, is a subject for a different book; I've discussed it at length in Decline and Fall of the American Programmer and Rise and Resurrection of the American Programmer, and I'll confine my remarks here to the reality of such death march projects.

If your company has told you—either explicitly, or by innuendo—that your job will disappear unless you sign up for a project with a ridiculous schedule, budget, and resource allocation, what should you do? Obviously, this depends on your assessment of your financial, physical, emotional, and psychological situation; you also need to accurately assess the situation within your company. In some cases, the real threat is that your promotion, bonus, or salary increase will be withheld if you don't participate; I'll cover this separately below. But even if the threat is termination of employment, big companies can't usually carry out their threat right away; you may have two or three months before your job disappears, and that may be enough time to find a job elsewhere.

What if the threat is more immediate and blunt? "Sign up for this death march project right now, or pack up your things and get out!" says your boss. It's inconceivable to me that a rational person would choose to work in such an environment, but let's assume the environment had been reasonably friendly until the latest re-engineering craze turned your boss into a raving lunatic. So here you are: Sign, quit, or be fired. What can you do?

If at all possible, my advice is: Quit now, because it's just going to get worse. You may have to live off your savings for a few months, and you may even have to take a pay cut while you gain experience in some newer technology; but chances are you'll be a happier person than if you knuckle under and continue on in a situation that has little or no upside potential. Sometimes you can accomplish this by volunteering for the death march project while simultaneously updating your resumé and starting the job search; however, this can create some ethical dilemmas if you feel that quitting in the middle of the death march project would leave your teammates stranded and helpless.

If you feel that you are truly stuck—because of imminent pension vesting, or because of unmarketable technical skills, or because personal commitments keep you locked into a one-employer town—then you might be tempted to take a more positive approach to the death march project. "By gosh, I'll show them that there's still some bark in this old dog," the middle-aged veteran will say. "I'll show management that I'm still just as good as those young whippersnappers, and we'll get this project done on time!" Your courage and positive outlook are admirable indeed, but just remember one thing: If your death march project succeeds, there will another one. Remember the theme at the beginning of this book: Death march projects are not the exception, they have become the norm.

It's required in order to be considered for future advancement

As noted above, there are times when the "invitation" to join a death march project carries with it a threat that future promotions and raises will be contingent upon (a) acceptance, and (b) success in the project. This is often associated with a re-engineering initiative—for example, "The people who lead the Megalith Bank into the 21st century will be the ones who have led us through this incredibly complex and challenging Total System 2020 re-engineering project!" If you find yourself in this situation, remember that politics is a key factor: The people who take credit for the success of the death march project may or may not be the people who participated in it. And the manager who proposes the death march project may be using the re-engineering "crisis" solely as an opportunity to advance his or her career, with little or no concern for whether the project team members survive in the process.

If you've memorized every word of Machiavelli's The Prince, and if you enjoy playing political games, then such death march projects might sound like great fun. But most software professionals haven't seen The Prince since their college days (if ever) and, in addition to admitting their political naiveté, they'll also express disgust at the whole concept of politics and enormous disrespect for those who indulge in it. If that's the case, why would anyone sign up for the Megalith Bank's Total System 2020 project? The only plausible answer: because you sincerely believe that it's a one-time death march project, and because you really believe that it will help advance your long-term career within the Megalith Bank. And if you believe this, chances are pretty good that you also believe pigs can fly.

In the majority of cases I've observed, the threat of withholding promotions and raises is part of the "Marine Corps" culture discussed earlier in this chapter. Whether it's right or wrong doesn't matter at this point; what counts is that it's fairly consistent. If you receive such threats on your first death march project, you'll probably get them on your second, third, and fourth. You may have been too innocent or naive to contemplate the long-term implications of such a policy when you first joined the company, but sooner or later it will sink in. There are really only two options in this case: Accept it, or quit.

The alternative is bankruptcy or some other calamity

As mentioned earlier, some death march projects have been caused by the re-engineering, downsizing, and outsourcing decisions made by senior management, which in turn have often been caused by global competition, unexpected government regulations, and so forth. Whatever the cause, the results are the same: The employee signs up for the project because he sincerely believes that the alternative is bankruptcy or some other dire calamity. And the situation is often exacerbated by blunt statements from management that anyone unwilling to participate in the death march should resign forthwith, so that those who remain can concentrate on saving the company.

Again, the issue here is not whether the situation is right or wrong, or whether management should have taken earlier steps to avoid the crisis. The point is that once the crisis has arrived and management has initiated the death march project, you need to make a rational decision about whether or not to participate.

From the discussion in earlier sections of this chapter, you can anticipate my advice here: Step back and ask yourself whether this death march project is a one-time exception or the beginning of an ongoing pattern. Even if you win the battle, your company may have lost the war; indeed, your success with your death march project may have the ironic consequence of delaying the final demise of the company just long enough to sustain a second death march project.

Again, this is a personal decision, and it may be colored by feelings of loyalty, sympathy, or a Hollywood-inspired desire to "win one for the Gipper"—a last hurrah to show the world that you and your company are not going to give up without a fight. And who knows: Maybe a tremendous success with your death march project will turn things around, as appeared to be the case when Borland delivered its Delphi product to the marketplace. None of us has a crystal ball when it comes to predicting the outcome of a death march project, nor can we accurately predict what the consequences of a death march success or failure will really be. Some companies die quickly, others die a long, lingering death; still others are acquired before the terminal rot sets in.

As you consult your own crystal ball, seek advice from as many people as possible, especially from those who have no vested interest in the outcome. You may find some honest, objective managers in your company who will candidly discuss the consequences of the death march failure/success; but you should also remember that the same managers have their own career and paycheck to worry about, and that their ego and political instinct may prevent them from sharing the really vital information you need to make an informed decision.

It's an opportunity to escape the "normal" bureaucracy

Technical staffers and project managers often complain that their corporate bureaucracy stifles productivity and introduces unnecessary delays into the software development process. But the larger the organization, the more entrenched the bureaucracy—especially in organizations where the methodology police enforce strict adherence to SEI-CMM or ISO-9000 processes. Similarly, the human resources department may have elaborate procedures that must be followed before new people can be hired, or before external contractors can be used on a project.

Death march projects often provide the opportunity to circumvent some, if not all, of the bureaucracy—and this is reason enough for frustrated software developers to sign up for such projects. In the extreme case, the effort takes on the characteristics of a "skunk works" project: The project team members move out of the corporate facility into a separate building, where they can carry out their work without the distractions of the normal bureaucracy. But even in a less extreme situation, a death march project can often get permission to use its own tools and programming languages, to try new technologies such as object-oriented programming, and to short-circuit much of the ponderous procedures and documentation that would otherwise be required. Equally important, the death march project manager is often given far greater latitude when selecting team members than would normally be the case.

In the best case, all of these changes can transform a death march into a civilized experience—that is, the very procedures (and technology and people) that turned the project into a death march have been removed or replaced. And if the death march project is eminently successful, it can serve as a catalyst to make permanent changes to the technology, peopleware, and processes used in other development projects throughout the organization. Conversely, if the death march project fails, it might serve as an affirmation that the "standard" policies aren't that bad after all.

In any case, a situation like this is a perfectly plausible reason for working on a project that might otherwise seem uncivilized. In some organizations, certain software developers make a point of always signing up for such projects because it's the only way to avoid getting sucked into the bureaucracy.

Revenge

Revenge may not seem like a rational explanation for working on a death march project, but it's real nonetheless. The success of the death march project might be sufficient to wrest power away from an incompetent vice president, or it might serve to humiliate an obnoxious critic who continually tells you "it can't be done" within the schedule and budget constraints of the death march project. Revenge is a powerful emotion, and it is particularly evident in the senior management ranks of large organizations, where insults are remembered forever, and where crafty politicians will sometimes wait months or years to wreak revenge upon their enemies.

Revenge can be a very powerful personal motivator, but it's usually somewhat more difficult to imbue an entire project team with the emotion. And when it happens, it often creates a situation where the team loses track of the "official" objective of delivering a working system within a specified budget and schedule—after all, their first and highest priority is revenge.

If revenge is your motivation, then there's not much for me to say: This is another personal judgment call. But if you're signing up for a project in which it's the manager's revenge, or the team's revenge, fueling the project (and causing it to accept deadline and budget constraints normally unacceptable), then you should be very careful indeed. "The vice president is an idiot," your project manager might tell you, "and if we finish this project in six months, he'll be so humiliated in front of the Board of Directors that he'll have to resign!" Well, that's fine—maybe the VP really is an idiot, but do you really want to sacrifice your personal life for the next two years in order to bring about his demise? After all, the next VP is likely to be just as much an idiot as the last one.

On the other hand, if everyone perceives the Vice President to be the personification of Darth Vader, and if the project manager is seen to be a combination of Luke Skywalker and Yoda, then a death march project can be very invigorating indeed. In this case, the entire project is re-cast into a battle of Good versus Evil, and that's enough to make people accept incredible sacrifices without complaint.