Book Review: Catastrophe Disentanglement

Catastrophe Disentanglement, $39.99
by E.M. Bennatan
Addison-Wesley, 2006
270 pages
ISBN 0-321-33662-3
http://www.amazon.com/gp/product/0321336623

As a profession, we software developers have amazingly low standards. Not only do we put up with a staggeringly high failure rate in software projects large and small, but often we simply ignore the fact that our projects are failing until the business sponsors finally realize it's hopeless and cut the funding. Indeed, we sometimes lie to everyone involved with fantastically optimistic status reports and predictions of a marvelous recovery ("Sure, we can do six months' worth of planned tasks next month, we'll just work a bit harder") right up until the end.

This book is an attempt to break at least part of that cycle. Based on the author's experience at Motorola and elsewhere, it lays out a plan for recognizing and remediating catastrophes in software development - those projects that are so drastically behind schedule, over budget, or below the necessary quality bar that they will never be completed satisfactorily. Bennatan starts with a discussion of how to recognize the warning signs of catastrophe (by evaluating, among other things, the rate of change in schedule slip and cost overrun), and then goes on to walk the reader through a ten-step plan for "disentangling" the mess.

The verb in the title is chosen deliberately. The first step in the process here seems draconian: stopping all work on the project in trouble. Some might think it makes more sense to keep working in parallel while coming up with a remediation plan, but the author points out that this is the surest way to show everyone that management is serious about not letting (bad) business as usual continue. There is, after all, no point in letting a catastrophe play out to its inevitable conclusion. If you're engaging in a disentanglement exercise, the goal is to find, if at all possible, some reduced-scope version of the project that can be successfully completed, possibly with a revamped project team. If that's not possible, it's time to pull the plug. You should be able to figure out which alternative makes sense in no more than two weeks of intense work and evaluation.

And who does the work? The author recommends bringing in an outside evaluator, someone with experience in software project management who can devote full time to the exercise. This avoids any involvement in internal politics (one hopes) and helps increase the chance of an objective (some would say ruthless) evaluation. Senior management support is essential here; the hired gun has to be seen as the judge who is going to make a fair decision, not as someone to be fooled again. The evaluator goes through a structured process - laid out here - of figuring out what state the project is in, as well as what the team is capable of, and what the minimum necessary software deliverable is that will be useful. Then a final report makes recommendations for, hopefully, turning things around.

It's clear that Bennatan has been involved in plenty of large projects and not a few disentanglement efforts. Not only is the basic framework sound, but each chapter includes a section of potential pitfalls and suggested counters. There are also exercises at the end of each chapter, making the book suitable for a one-term course (though I wonder how many college students would really have the background to understand the sad necessity of this field of work). While it's clearly written from the perspective of large corporate software engineering, it looks to me like the same strategy could be usefully employed even on small-team projects, in a time-abbreviated fashion. I could see going through the whole process in 3-5 days with a small team, instead of taking 2 weeks.

If you're the sort of hired gun who gets called in to find out that someone else has made a big mess that you're expected to magically clean up, you'll want to add this book to your shelf. You may well be doing most of these things already, but it's nice to have a structured framework, and this is also the sort of book that you can share with management at the outfit that hires you to say "this is what I do, take it or leave it."

Mike Gunderloy is the lead developer for Larkware and author of numerous books and articles on programming topics.

Published May 18, 2006