 |
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
|