Customer Reviews

Catastrophe Disentanglement: Getting Software Projects Back on Track

5 star:		(6)
4 star:		(0)
3 star:		(0)
2 star:		(0)
1 star:		(0)

 

 

There are plenty of books that try to help you keep your project on track. But what happens when you are sitting on a catastrophe and you don't know how to salvage it? E. M. Bennatan fills a necessary niche with the book Catastrophe Disentanglement : Getting Software Projects Back on Track.

Contents: An Introduction To Catastrophe Disentanglement; When Is A Project A Catastrophe?; Step 1 - Stop; Step 2 - Assign An Evaluator; Step 3 - Evaluate The Project; Step 4 - Evaluate The Team; Step 5 - Define Minimum Goals; Step 6 - Can Minimum Goals Be Achieved?; Step 7 - Rebuild The Team; Step 8 - Risk Analysis; Step 9 - Revise The Plan; Step 10 - Create An Early Warning System; Epilogue - Putting The Final Pieces In Place; References; Glossary; About The Author; Index

If you're in IT for any length of time, you'll be part of a project that is massively over budget or late. Rather than just continue the death by 1000 cuts or a quick mercy killing, Bennatan presents a ten step process that allows an organization to take a (hopefully) objective look at the project and decide what can possibly be saved from it. I was impressed that it wasn't a long drawn-out procedure either. The plan calls for an evaluator (or a small team for huge projects) to come in and quickly assess the environment... what's been done, the climate of the team, and what could be redefined as a "minimum system". At the end of this process, the organization should be able to either kill it off with the knowledge that it can't be saved, or continue on with a redefined set of deliverables that are achievable. It won't be everything that was originally wanted, but it will be more than you'd get by letting it die. I was also impressed with the "What Can Go Wrong (And What To Do About It)" section in each step. He doesn't present this as some cut and dried panacea that will flow smoothly every time. It may not be an easy task, but the book will give you the help you need to make it all work.

Definitely a book that is worthy to be on every IT project manager's bookshelf, as you *will* need it some day...

Good book, good subject, well covered. The book builds an organized process around the rescue of a failed (or failing) software project. The steps are easy to read and understand, and seem well thought out. Some good methods for identifying projects headed for serious trouble. Also, some useful guidance on how to handle political (not just technical) problems. Obviously, the result of significant experience. Well recommended.

I bought this book for general project evaluation purposes, for a project that I was called in on that was in trouble.

Well worth the read - a lot of it is just good common sense, straightforward project management process, but it provided a great roadmap for validation of my plan to put the project back on track.

Definitely would recommend it - it's an easy read; I finished it in under 5 hours on the flight out, complete with note-taking. Kudos to E.M. Brennatan for writing this in a straightforward fashion.

Catastrophe Disentanglement : Getting Software Projects Back on Track teaches the kind of skills you hope you never have to use. It's something like taking a CPR class for project management. You hope you never have to administer CPR in real life, but when you do get put in that position, you're really glad you have that training to fall back on. That clear, logical list of steps can mean the difference between life and death. In the world of project management, the skills taught in this book can save projects and careers.

This book differs from traditional project management books in that it focuses on corrective rather than preventive measures. The author teaches two critical things. First, he presents a set of criteria used to recognize a project that is in need of rescue. This is an important step! Once a project is identified as seriously out of control, you can apply the steps presented in this book to bring it back on track and guide it to a successful completion. This book will give you the reasoning and courage necessary to make hard decisions.

Table of Contents
Chapter 1 An Introduction to Catastrophe Disentanglement
Chapter 2 When Is a Project a Catastrophe?
Chapter 3 Step 1--Stop
Chapter 4 Step 2--Assign an Evaluator
Chapter 5 Step 3--Evaluate the Project
Chapter 6 Step 4--Evaluate the Team
Chapter 7 Step 5--Define Minimum Goals
Chapter 8 Step 6--Can Minimum Goals Be Achieved?
Chapter 9 Step 7--Rebuild the Team
Chapter 10 Step 8--Risk Analysis
Chapter 11 Step 9--Revise the Plan
Chapter 12 Step 10--Create an Early Warning System
Chapter 13 Epilogue: Putting the Final Pieces in Place

I would recommend this book to anyone involved in software projects.

It is always better to avoid getting into the starting scenario of this book - where you are managing a software project that is staring at failure. Prevention rather than cure, right? Certainly, Bennatan forthrightly agrees with this, in the book's Preface. But few software processes deal with the awkward case of getting out of a catastrophe. The latter is the author's term, which frankly I find a little hyperbolic. Then again, if you are indeed in that situation, with a project to save, then maybe you'd use it too.

The text breaks up its advice into 10 steps, with well chosen and self explanatory titles like "Assign an Evaluator" and "Evaluate Project Status". It's no small part of the value of this book that the titles are logically clear and help the reader in accepting and retaining the concepts in those chapters.

Of all the chapters, the most critical might be the evaluation of the project status. Without an assessment that is as objective and quantifiable as possible, then doing subsequent steps means performing them on a foundation of sand. Certainly, each step or chapter is important. But you should focus considerable effort on this particular chapter.

Another way of looking at the chapter is that a cause of your project's current problems might well have been shoddy and imprecise planning and assessments (as the project progressed). If so, then a sloppy application of the chapter could just be a continuation of what got you blokes into this mess in the first place.

You might also find the exercises provided at each chapter's end to be useful in furthering the understanding of the chapter's message.

It is a law of nature, grouped under the general name of entropy, that it is easy to mess things up and very hard to straighten them out. In fact, it is the natural state of nature to tend towards increasing disorder. This law also applies to software projects, since they are naturally very complicated entities; they easily reach a point where difficulties compound to the point of dysfunction. The author calls this state a catastrophe, although in my opinion that is an overstatement.
A catastrophe is a major disaster, far beyond what most software development projects actually are. Granted, there are problems, but most of the situations described in this book are ones that can be recovered from with more effective planning and focused execution. The author puts forward a ten-step plan for disentanglement:

1) Stop the project - not permanently, just long enough to examine the project in detail before things get worse.
2) Assign an evaluator - a disinterested party is assigned to perform an honest and unbiased appraisal of the project and what is going wrong.
3) Evaluate the project - the evaluator takes the lead in doing a complete dissection of all aspects of the project, what is being done right and what is going wrong.
4) Evaluate the team - examine the people working on the project and determine if all are suited to their jobs and if all are performing at the appropriate level.
5) Define minimum goals - determine what is considered to be the minimum level of achievement that will be considered a success.
6) Determine if the minimum goals can be achieved - if the minimal level of success is not possible, then the decision must be made to terminate the project.
7) Rebuild the team - this step has two basic components. Personnel changes if necessary and reinvigorating those who are going to remain part of the team. One of the greatest tasks is to overcome the defeatist mindset.
8) Risk analysis - attempt to identify all possible risks and assign a reasonable probability of occurrence to all of them.
9) Revise the plan - as circumstances change, modify the plan to reflect the different conditions.
10) Create an early warning system that will flag the appearance of problems when they are not yet serious.

These ten steps are each the topic of a chapter. Exercises for further practice are included at the end of each chapter, although no solutions are given.
I enjoyed the book; it contains a lot of sound advice on how to right a rudderless software project. Most of the advice will work only on a project that is not yet seriously out of control. Quite frankly I don't believe that a ten-step plan like this is powerful enough to get the most dysfunctional death marches back to a point of potential profit. Therefore, while I believe that the advice is sound, it is limited in scale, where the measurement is of the level of dysfunction in the project. On that basis, I can recommend the book.