Updates
Latest Tweet
What's New?
Check out for latest innovation, a computer based training video collection
Like this Page
Catastrophe Disentanglement: Getting Software Projects Back on Track Review by Charles Ashbacher
With this advice, you can right the rudderless software project
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.