The Illustrated Primer

The Death March

Yaacov Apelbaum-TheDeathMarch

Most software professionals view themselves as the masters of their own destiny, analytical and calculated, wisely exercising free choice in all matters of importance.

This was certainly my mental image of myself as well until several years ago, when I gradually came to realize that given enough time on the job, even the most experienced development manger will eventually have to venture into that dark and irrational world of the death march project.

For those unfamiliar with the term, a death march is not a walk through Ezekiel’s valley of dry bones. Rather, it is a reference to a development project where requirements either exceed the realistic deliverables by at least 50 percent or where critical resources are cut in half without adjusting functionally and schedule delivery accordingly.

Contrary to the common misconception, death march projects are not limited to only naïve and over ambitious startups. To the contrary, they are quite common in large and mature organizations that should know better yet for some poorly understood reason continue to practice every form of anti pattern known to man. How do I know this? Well to confess my sins, over the years I’ve participated in several of these projects.

Perhaps you are wondering why any rational person would choose to participate in or initiate a project that from its onset is clearly doomed to fail. The answer has to do with the adaptive strategies we use in order to survive in highly competitive and schedule driven corporate environments.

When performing a post mortem, most death march software projects typically exhibit the same pathology. The prominent finding is that the team has worked twice as hard and/or twice as long as would be expected in a “normal” project. So for example, if a normal work week is 45 hours, then a death march project team works 15-hour days, six days a week for a 80 hour week. Of course, thanks to a steady diet of caffeine and management coercion, the pressure within the team eventually escalates beyond control and leads to project meltdown.

The psychological drivers behind the willingness of individuals to join what is clearly a long and drawn out sadomasochistic exercise stems from the strong disdain that many of us have for organizational politics and our refusal to take any part in it. Unfortunately, by not participating in the political horse trading, we sacrifice our ability to effectively influence these irrational projects and leave all the decisions to corporate politicians who have little stake in the actual development effort.

Scott Adams, commented on this form of irrational behavior:

“Nothing defines humans better than their willingness to do irrational things in the pursuit of phenomenally unlikely payoffs. This is the principle behind lotteries and dating…”

Having reached this realization myself, I eventually started wondering if there were any early signs or warnings that could help identify an imminent death march. After some introspection and reexamination of previous projects, I have come to conclude that any of the following three (individual or combined) project scenarios will almost guarantee the formation of a death march:

  1. Naivety of Youth—The schedule has been compressed to less than half the amount estimated based on previous delivery; so for example a project that would normally be expected to take six months will be set to be delivered in three months or less. This form of a death march is most common in ra-ra speech environments and “Internet time” startups that naively believe that when it comes to their ability to deliver the “sky is the limit”.
  2. The Senility of Old Age—The development team has been reduced to operate at half the capacity. This may have come about as a result of management’s belief that a new development language, framework or technologies will double the team’s productivity. This is often seen in older companies that are downsizing while at the same time transitioning from one technology to another.
  3. Offshoring Hell—The budget for the project has been cut in half because the business believes that offshoring it is a cheaper alternative. In this scenario, the project manager is informed by the business unit sponsoring the project that it’s a “take it or leave it deal” and if the development manager doesn’t accept the budgetary constraints the business unit will offshore the entire project for less. Thus, in an attempt to save his team from the chopping block, the development manager accepts an impossible challenge.

    Another interesting side effect of this type of project is that as soon as management finally realizes that the project is going nowhere fast, they try to salvage it by throwing additional offshore resources at it, which leads to further delays (Brooks’s law).

It is true that many of the contributing factors to a death march may be beyond your control, but if you find yourself involved in one of these coveted assignments don’t panic, take notice. Contrary to the advice dispensed by some purists (i.e. transfer to another team), being assigned to such a project doesn’t mean that you should abandon it or quit your job. My advice is to keep your ethics and personal priorities separate from the politics of the project. Do your best to contribute to the success of the development, but in so doing be sure to set your manager’s expectations to realistic levels.

State your concerns in a non-argumentative and level headed manner and clearly communicate your conditions for participating in the project in terms of exactly how much overtime you will agree to and your willingness to work weekends and holidays.

Without advocating or orchestrating a mutiny, encourage your team members to speak their minds as well. In these ways, although you may not be able to cancel the project, you will likely succeed in regaining some control over it and reduce the amount of stress everyone on your team incurs.

Happy coding!

© Copyright 2009 Yaacov Apelbaum All Rights Reserved.

Exit mobile version