Software Runaways
This is a case-study book dealing with software failed projects, e.g., The Denver Airport problem. It categorizes these failed projects into the following areas: project objectives were not fully specified; projects were poorly planned; enabling project technology was not fully understood; absence of management methodology; insufficient expertise; and lack of understanding of the risks involved.
These cases will show how failure might have been avoided and how the projects might have been completed on time and within budget. This book should be seen as a companion volume to Yourdon's Death March book and Jones' Assessment and Control of Software Projects, both of which are extensively referenced in the book.
Review By: Mary Decker
08/26/2002This book provides an in-depth look at major software (and engineering) projects that went very wrong. It doesn't attempt to place blame, but rather to analyze the project, its shortcomings, and the overall effects of problems and how they contributed to failure.
The author starts by defining terms and relating them to the standards used when discussing project overruns. He gives a straightforward explanation of why he adopted his standards and the statistics used to back them up.
After defining the terms, he identifies the top seven problems that contribute to “software crisis”:
Project Objectives not Fully Specified
Bad Planning and Estimation
Technology New to the Organization
Inadequate/No Project Management Methodology
Insufficient Senior Staff on the Team
Poor Performance by Suppliers
Performance (Efficiency Problems)
For each problem he includes "War Stories" that are dramatic examples of these problems. Each problem is given a face, and we see that it is usually more than any of the above factors that contributes to the overrun. These examples provided a dramatic example of how wrong things can go on a project and while reading the cases, I found myself analyzing my current projects and noting the warning signs.
The war stories do not attempt to assign blame but rather to illustrate how these projects went awry. They describe the contributing factors, the environment, and the problems each project faced. Finally, he explains the outcomes of the projects.
The book was very easy to read and I found myself sometimes nodding along, having seen the problems discussed on a smaller scale. Some of the war stories had me cringing, but all of them made me think.
The author did what he set out to do in giving us dramatic examples of runaway products. His cases are well documented and well described--all in all something we can all learn from, although after a while the stories and problems started to run together.
In the conclusion the book gives some solutions to these problems and how to identify them early on. I would have liked it if the "Remedies" section were longer and perhaps interwoven with the war stories. Still, it gave a cohesive focus to the problems and factors that lead to project failure. Understanding the process is the first step to making it better.
I would recommend this book to anyone who asks "How could this have happened?" or says "Nobody else has these problems." They are out there and perhaps this book will help people learn to look at projects and understand the process better.