Death March - TechBookReport

Keywords: Corporate software development, methodologies, project planning and control

Title: Death March (Second Edition)

Author: Edward Yourdon

Publisher: Prentice Hall

ISBN: 013143635X

Media: Book

Verdict: Interesting but depressing

Buy US
Buy UK

There can be few titles of IT books as evocative as this one. If you've ever worked on such a project, or indeed are currently engaged on one, you'll know exactly what Edward Yourdon means by a 'Death March' project. If you've not had the experience yet, and you work in a corporate development environment, then you're either new or you've lead a charmed life so far. Death March projects are those that are doomed to failure from the word go, doomed by unrealistic deadlines and resourcing and, even though everybody involved knows what the end is going to be, nobody seems to act on the blindingly obvious.

Yourdon aims to do more than characterise and report on the existence of Death March projects, which in most respects differ from the kind of projects described in most software methodology or project management texts. To this end the book opens with a chapter which defines such projects and then explores why they happen and why people take part in them. For many of us the answer to the latter question is straightforward - we have no choice. Given the chance most of us would run a mile before getting involved, but the sad facts of life for a corporate developer mean that very often the only way out of a project is by finding another job?

If we want to understand why nominally sane and intelligent individuals create Death March projects, and why they refuse to learn from previous failures, one has to understand corporate politics. There is a chapter devoted to the subject, along with a chapter on the related topic of negotiations.

One of Yourdon's primary aims is to help people on these projects to find strategies for survival. Sometimes the advice is quite radical - not many of us can afford to walk out of a job when faced with an ultimatum to work on project Titanic, even if we'd like nothing better. Aside from this many of the recommendations are just plain common sense - try to by-pass the bureaucracy as much as you can, try to stay sane in the face of the insanity all around you, don't be tempted to look for silver bullets (whether this is methodology X or tool-set Y) and so on.

Borrowing from medical practice, Yourdon advances the concept of triage as an essential strategy. This is the policy adopted in accident and emergency departments in hospitals - take those patients with the severest needs and do what you must to save them. Minor injuries have to wait in line while the cardiac patients are kept alive. This is an apt description of a what you have to do in a Death March project: identify those requirements that you need to meet in order to keep the project alive. This means sorting requirements into 'must-do', 'should-do' and 'could-do' and only doing the 'must-do' requirements unless you've got the time to do some of the 'should-do' items too. Over time the relative priority of requirements will change, but by focussing always on the most important you have some chance of delivering something useful at the end of the day.

Yourdon also takes a look at development processes, critical chain scheduling and the theory of constraints and other areas. Time management and controlling progress also rate separate chapters, as do tools and technology. The final chapter raises the idea of simulations and war games, which sound good in theory but, as he admits, are unlikely ever to be used by most companies.

While this is a interesting book, it's also a very depressing one. Far from being the exception it seems as though Death March projects are increasingly the norm. It has to beg the question, what is it about corporate cultures that makes people unable to learn from their mistakes?

Hit the 'back' key in your browser to return to subject index page

Return to home page