Death March (2nd Edition) (Yourdon Press SeriesDeath March (2nd Edition) (Yourdon Press Series - published by Prentice Hall, 1997

When I first began reading this book, I thought it would be all about the team that came before us… the one that spent a lot of time delivering something that didn’t work. But the more I read, the more I found myself identifying our current team with the descriptions in each chapter. Curious as the title doesn’t sound that positive! As Wikipedia defines it, a death march project is one that is destined to fail.

One point that comes out repeatedly is that while in some ways “Death March” projects are not intended to be the norm, more often than not they end up being the de facto way that many IT projects are run.

In Ch. 1, characteristics of a “Death March” project are listed as including:

  • Tight schedules
  • Small team
  • Limited budget
  • More features
  • Smaller scale

Hmm.. that sounds familiar!

In subsequent chapters he goes on to cover topics such as Politics, Negotiations, People, Processes, Tools & Technologies and finally the idea of “Death March” projects as a way of life.

In Ch. 3, the topic of Estimation is examined, and the value of having an experienced project manager who can estimate slightly better than just “gut feeling”, and that there are software estimation tools that can improve forecasting accuracy. I reckon Steve McConnell’s Software Estimation: Demystifying the Black Art (Best Practices (Microsoft)) could be worth a read to learn a bit more about this topic. I’ll add that to my wish list!

People can make all the difference, and our team certainly bears this out. I can’t agree with the comment that 80 hours a week is ok though.

Yourdon also espouses the importance of good workplace conditions – in particular quietness and privacy (eg. separate offices). There’s certainly empirical evidence to reinforce the productivity benefits, which flies in the face of the current trend of “open” office space, cramming as many people into tiny cubicles as possible.

Triaging tasks/bugs are critical, and allows you to prioritise what is important.

When this book was first published, there wasn’t much in the way of “Agile” development practises, but I think Yourdon is alluding to this when he makes mention of using RAD tools (refactoring), mini-milestones (iterations) and daily builds (continuous integration).

One thing I did find annoying was Yourdon’s use of a monospace font when listing the emails in each chapter’s list of references. This made them very hard to read and I mostly ended up skipping over them as a result.

Overall I came away inspired by this book. Yourdon highlighted the many pitfalls that await a team who are engaged in a “Death March” project, but does offer hope that under the right conditions, you can achieve success.