This chapter is from the book
This chapter is from the book
This chapter is from the book
Summary
If the discussion in this chapter seems pessimistic and cynical, remember: It hasn't stopped death march projects from taking place. Companies both large and small are filled with politics and are staffed by managers and technical developers who suffer from hysterical optimism as well as the usual gamut of emotions such as fear, insecurity, arrogance, and naiveté. And the combination of re-engineering, downsizing, outsourcing, and global competition—together with the opportunities provided by new technologies such as object orientation, client-server, and the Internet—suggests to me that death march projects are likely to be a common occurrence for years to come.
And that's the primary point of this chapter. You may not agree with any of the rationales suggested here; you may not like any of the reasons for initiating such projects or joining such projects—but they're real nonetheless. The key point is to recognize and understand your own motivations at the beginning of a death march project, so that you can make a rational decision to join the team or look elsewhere for your next job. Since many of these projects are initiated during periods of great corporate stress and emotion, rational decisions are not as easy as you might think; it's all too easy to be swept away by the emotions of your fellow colleagues or your manager.
It's worth noting that some observers have a more optimistic outlook than what I've suggested; they believe that there will actually be fewer death march projects during the remainder of this decade. For example, when I asked in an online discussion forum during the spring of 2003 whether death march projects were likely to diminish, Erik Petersen responded by saying:
Hopefully going down. Two reasons.
The culture of the ever expanding IT budget has gone, and management wants projects to succeed (even if they still try to run them lean). From what I have seen, sub project deliverables are becoming more common and highlighting death march issues earlier, and projects are killed sooner.
Better education should reduce the naiveté of newbies. Most graddies now learn about testing and quality as part of their studies. Some even learn project mgmnt. Agile methods are popular at universities as well, with test first development, etc. XP is becoming more popular, complete with no overtime mantra. I think this will help to empower teams, both delivering better software, and standing up to unrealistic schedules and targets.[18]
Whether there are more or fewer of them in the future, I should emphasize that I'm not necessarily opposed to death march projects; I agree with my colleague Rick Zahniser[19] that such projects can be an educational experience even if they fail:
I've told you before, I think everyone should be on at least one of these projects. However, there are some other things that you should do at least once:
+ Spend a night in jail.
+ Get commode-hugging drunk
+ Raise a boy
+ Raise a girl
+ Start your own business
+ Climb Mount Fuji[20]
In any case, for the remainder of this book I'll assume that you have made a rational decision to join the death march project—though I'll remind you from time to time, in later chapters, that you always have the option of quitting during the project. But we'll assume that your primary objective at this point is to succeed, or at least survive, the death march project. In subsequent chapters, we'll see how that can be done.