It was almost exactly ten years ago that I wrapped up a summertime writing project in Polson, Montana and began heading back to New York City; you can see the description of my cross-country drive in the September 1, 1996 entry in the “road-warrior journals” section of my website, entitled “Leaving Montana.” The writing project was a book, Death March, which described a phenomenon that I was beginning to see fairly frequently by the mid-90s, and which became almost the norm by the end of the decade.

Most people understand the subject matter of the book without any explanation, but in case you’re puzzled: a death march project is one whose schedule (deadline), budget, resource allocation (people), and other constraints are so aggressive that the only possible way to succeed is to have every member of the team work 14-16 hours a day, seven days a week, until the project is finished or everyone collapses from exhaustion. Sound familiar?

A few months after I finished the manuscript, my good friend Tom DeMarco wrote a passionate objection to the very concept of death-march projects (See “No Means No!” in the April 1997 issue of American Programmer, which was subsequently transformed into the Cutter IT Journal). Tom argued that death march projects typically have three characteristics: a culture of fear, an absence of justification, and a virtual certainty of failure.

I respect Tom’s opinions, and I agree that project managers and IT professionals should run away as fast as possible if they find themselves being sucked into a project with those three characteristics. But I think there are counterexamples: I’ve seen death march projects that were exhilarating and sufficiently exciting that you’d sign up for another one just like it; death march projects utterly devoid of the “culture of fear”; death march projects that had justifications like making oodles of money, or saving a segment of the population from disaster; and death march projects that, albeit risky, did have a reasonable probability of success.

However, this is primarily a philosophical argument: whether you like them or not, death march projects do exist. Indeed, they’ve always existed, at least throughout my career of 40+ years in the computer field. They became much more commonplace toward the end of the 1990s for two reasons: the dot-com bubble, and Y2K projects that absolutely, positively had to be finished before the January 1, 2000 “rollover.”

Of course, both of those phenomena came to an abrupt end, though for very different reasons. And in terms of death-march projects, things were relatively quiet from early 2000 until recently. I think that’s primarily because IT spending dropped during the post-Y2K/post-dot-com era, and companies were less inclined to embark upon ambitious development efforts with aggressive schedules. Death march projects didn’t disappear, but they weren’t as pervasive as before.

But in the past few months, I’ve noticed a resurgence of interest in the topic. A revised edition of the book was published in the fall of 2003, and the Japanese translation was finally published in the spring of this year. It’s gone through two printings, sold a respectable number of copies, and a Japanese computer magazine is coming to New York next month to interview me about death march projects. And I’ll be giving keynote addresses on death march projects at five different venues of the 2006 Software Best Practices conference this fall; click here for a schedule of events, and let me know if you’re coming.

What’s going on? Quite simply, I think IT spending is up, companies are getting more adventurous, and they’re embarking on more aggressive development initiatives once again. Or maybe it’s an instance of the “generational amnesia” phenomenon: we’ve got a new crop of project managers and IT executives (and/or business managers, senior executives, and end-users) who weren’t here ten years ago, when the previous generation learned a lot of hard lessons about death march projects. Or maybe people are being seduced, once again, by the siren song of advanced technology — “yes, this time we really can succeed with this impossibly large development effort, because we’re using Ruby on Rails!”

For whatever it’s worth, technology-based solutions are at the bottom of my list of recommendations for surviving and succeeding with death march projects. At the top of my list is politics — e.g., figuring out who the key stakeholders and decision-makers really are, figuring out why the death march project has been initiated in the first place, and who will be allowed to define “success.” That’s followed by negotiation and estimation techniques, followed by “peopleware” practices, followed by “processes” (e.g., agile processes, SEI-CMM/ISO-9000 processes, risk management processes, etc.). All of these are things we should be doing for any software development project, but they are the key differentiators between success and failure in a death march project.

So, welcome back to the world of death march projects. You can love ‘em or hate ‘em, but I think they’re here to stay.

P.S. If you’d like to get a sense of what Polson, Montana is like, take a look at my July 4, 1996 road-warrior posting entitled, “The Polson Parade.” It also gives you a sense of what “blogging” was like in the days before we had today’s sexy new blogging tools. That whole entry, HTML tags and all, had to be typed into a simple-minded text editor, and then uploaded via FTP to my web side. So we may still have death-march projects, but some things have definitely improved!