- What Exactly Are Death-March Projects?
- So Why Should We Avoid Death-March Projects?
- Death-March Projects Are a Sign of Poor Management
- Don't Get Me Wrong; Long Hours Are Okay
- Hell, No, I Won't Go!
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Death-March Projects Are a Sign of Poor Management
Death-march projects are underfunded projects, pure and simple. Being underfunded, they have to be completed in less time and with fewer resources than are needed to deliver the desired functionality.
Underfunding is always a management issue. Sure, estimating is difficult, and the developers may have made a mistake when the project was originally estimated, but incorrect estimates are easy to fix. Most good managers allow for the possibility of incorrect estimates and do what it takes to create a sane schedule as soon as the project has been re-estimated. Unfortunately, some managers attempt to hold the team to the original, incorrect estimate—and suddenly everyone is on a death-march.
Worse, some managers hold to the idea of "stretch targets," in the mistaken belief that people work better when put under pressure. These managers delight in their ability to force developers to cut their estimates to the bone. This makes the project look cheaper and can mean that a marginal project will receive the go-ahead. Now the poor developers are expected to live up to the reduced estimates—death-march time again.
Some managers claim that the project has to be completed in minimal calendar time to meet some external date or to respond to a competitor. This is not normally an issue if the project is significant and important enough, because the project will be given adequate priority throughout the organization. The death-march problem only arises for "pet projects" and unimportant projects, for which the rest of the organization doesn't really see the urgency. Suddenly, because the manager wasn't paying attention to the outside world, the developers are asked to work to a crazy schedule without adequate organizational support.
All of these are examples of poor management. There's no excuse for expecting developers to put in a sustained, superhuman effort for normal, business-as-usual operations.
I consider this to be true even in the case of competitive pressure, where a competitor has come out with some new cool feature that our product just has to have. Why was the manager asleep at the wheel? Why is our company not well enough respected in the marketplace that we could just announce a sensible schedule for inclusion of the new feature in our product, and the panic would then die down? Why were we not proactively leading the market and forcing our competitors to follow? It all comes down to poor management.
Admittedly, the crazy schedule might be due to a simple, one-time mistake, in which case it might make sense to sign up for the death march. But experience has taught me otherwise. I rarely see lots of introspection and reflection from managers as to how to avoid a death march. Indeed, it seems that they actively rely on using death marches as a technique for delivering projects. (Sorry, but if I wanted to burn myself out I could think of many more enjoyable ways of doing so.)