- 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!
Ed Yourdon's book Death March: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects (Yourdon Press, 1999, ISBN 0-13-014659-5) states that the world would be a healthier place if more of us stood up to say, "Hell, no, I won't join this death march!" Unfortunately, he then spoils it all by stating "...death-march projects are the norm, not the exception." (See related article.)
Well, I beg to differ. Death-march software projects are not the norm. It is possible to run projects with sensible schedules that don't threaten to burn out the entire team. We don't have to deliver buggy software because we're too tired even to think.
What Exactly Are Death-March Projects?
The really crazy thing about death-march projects is that, as Tom DeMarco pointed out in his speech at OOPSLA in Tampa Bay (Oct., 2001), these death-march projects are characteristically insignificant. Yes, they're dramatically hyped by the organization, but their success or failure doesn't really matter. If the project really did matter, the organization would invest sufficient time and resources to make sure that it had a much better chance of succeeding.
Think about it. Really important projects that are valued by the organization get staffed, planned, and managed properly. The organization makes sure that the delivery dates are realistic given the desired functionality.
Insignificant projects, on the other hand, have to make great promises about what they can deliver at minimal costjust to get funded. Sure, if you can pull it off, you get to look like a hero. Even if you don't pull it off, you can still claim that it was successful because of how much you managed to accomplish.