Register your product to gain access to bonus material or receive a coupon.
Catastrophe Disentanglement: Getting Software Projects Back on Track
- By E. M. Bennatan
- Published Apr 11, 2006 by Addison-Wesley Professional.
Book
- Sorry, this book is no longer in print.
eBook
- Your Price: $30.39
- List Price: $37.99
- About Watermarked eBooks
This PDF will be accessible from your Account page after purchase and requires PDF reading software, such as Acrobat® Reader®.
The eBook requires no passwords or activation to read. We customize your eBook by discreetly watermarking it with your name, making it uniquely yours.
Description
- Copyright 2006
- Dimensions: 6-1/4" x 9-1/4"
- Pages: 288
- Edition: 1st
- Book
- ISBN-10: 0-321-33662-3
- ISBN-13: 978-0-321-33662-0
- eBook
- ISBN-10: 0-321-46798-1
- ISBN-13: 978-0-321-46798-0
“There are many books available on software risks and software failures. There are very few books that provide step-by-step information on getting troubled software projects back on track. This book provides detailed guidelines for software project recovery. Some of the steps the author recommends may be unpleasant, but all are important.”
—Capers Jones, chief scientist emeritus at Software Productivity Research LLC
“This is a well-conceived, well-written, interesting book about an important topic. The author is right in saying that no one else has covered this particular facet of project failure.”
—Robert L. Glass, publisher of the Software Practitioner
A 10-STEP PROCESS TO IDENTIFY SEVERELY TROUBLED PROJECTS AND AVOID COSTLY FAILURE
It’s a software development nightmare: a project that’s rapidly spiraling out of control...or already a disaster. Conventional project management techniques won’t save these projects: there are no standard rescue processes to follow. You need something radically different: Catastrophe Disentanglement.
Drawing on in-depth data from hundreds of development organizations, E.M. Bennatan presents a proven, 10-step program for rescuing any project that’s worth saving. You’ll find specific guidance for addressing massive budget overruns, schedule slippage, poor quality—or all three at once. Using practical examples drawn from decades of hands-on experience as a software development leader and consultant, Bennatan shows how to
- Evaluate where your project really stands
- Align your project’s developers, managers, and customers
- Defi ne the minimum acceptable project goals that are achievable
- Replan your project to successfully deliver the new minimum goals
- Identify risks in your revised project and create effective contingency plans
- Install an “early warning system” to keep your rescued project from slipping back toward catastrophe
Catastrophe Disentanglement is an effective, comprehensive approach to software project rescue. Whenever projects are in trouble—whether you are a senior manager, project manager, team member, or software customer—this book could save your career.
Preface xi
Chapter 1 An Introduction to Catastrophe Disentanglement 1
Chapter 2 When Is a Project a Catastrophe? 15
Chapter 3 Step 1–Stop 43
Chapter 4 Step 2–Assign an Evaluator 57
Chapter 5 Step 3–Evaluate the Project 73
Chapter 6 Step 4–Evaluate the Team 95
Chapter 7 Step 5–Define Minimum Goals 113
Chapter 8 Step 6–Can Minimum Goals Be Achieved? 133
Chapter 9 Step 7–Rebuild the Team 147
Chapter 10 Step 8–Risk Analysis 169
Chapter 11 Step 9–Revise the Plan 189
Chapter 12 Step 10–Create an Early Warning System 209
Chapter 13 Epilogue: Putting the Final Pieces in Place 233
References 245
Glossary 255
About the Author 257
Index 259
© Copyright Pearson Education. All rights reserved.
Extras
Related Articles
Divergent Versus Convergent Thinking: Which Is Better for Software Design?
Sample Content
Online Sample Chapter
An Introduction to Catastrophe Disentanglement for Software Projects
Downloadable Sample Chapter
Download the Sample
Chapter related to this title.
Table of Contents
Preface xi
Chapter 1 An Introduction to Catastrophe Disentanglement 1
Chapter 2 When Is a Project a Catastrophe? 15
Chapter 3 Step 1—Stop 43
Chapter 4 Step 2—Assign an Evaluator 57
Chapter 5 Step 3—Evaluate the Project 73
Chapter 6 Step 4—Evaluate the Team 95
Chapter 7 Step 5—Define Minimum Goals 113
Chapter 8 Step 6—Can Minimum Goals Be Achieved? 133
Chapter 9 Step 7—Rebuild the Team 147
Chapter 10 Step 8—Risk Analysis 169
Chapter 11 Step 9—Revise the Plan 189
Chapter 12 Step 10—Create an Early Warning System 209
Chapter 13 Epilogue: Putting the Final Pieces in Place 233
References 245
Glossary 255
About the Author 257
Index 259
© Copyright Pearson Education. All rights reserved.
Preface
The Russian asked for one last glass of vodka. The Frenchman asked for one last kiss from a young native girl. The Japanese man said that he would like to give his talk about quality one last time. The American then requested: "Please boil me first, so I don't have to listen to another talk about quality!"
There is a time and a place for everything, and when a software project is in serious trouble, the last thing the development organization wants to hear is how they should have run the project. But when a software project is in serious trouble, there is no PMI, IEEE, SEI, or ISO rescue process to follow because these organizations offer preventive, rather than corrective, solutions. And as the project gets closer to being thrown into the pot of boiling water, its last request is "save me" and not "show me how not to get into trouble again."
This is the "save me" book. It deals with rescuing failing software projects and getting them back on track; though, admittedly, it does stray into preventive territory occasionally. The book describes ten steps to rescue (or disentangle) a failing software project (or catastrophe). It is intended for a broad audience, including software developers, project managers, members of senior management, and software project stakeholders (anyone with a significant interest in a software project).
The book is also intended as courseware, and each chapter includes a chapter summary and a list of review exercises.
While the book does occasionally expect some knowledge of software engineering, this is not a primary requirement for using the book. Thus, the book is as useful for software engineers who have limited knowledge about management as it is for managers who have limited knowledge about software development.
The book is divided into 13 chapters:
Chapter 1 contains an introduction to the concept of catastrophe disentanglement. It discusses when a project needs the intervention of a rescue process, and it explains several of the basic terms used in the book.
Chapter 2 describes the method for determining when a project is a catastrophe. For a troubled project, this is the chapter that determines whether the remaining chapters are required.
Chapters 3 through 12 describe the ten steps of the catastrophe disentanglement process (each chapter describes one step).
Chapter 13 is an epilogue called "Putting the Final Pieces in Place." This is where some of the worst straying into preventive territory occurs. It also provides a bird's eye view of the ten steps and shows how to fit the overall disentanglement process into a fixed schedule of two weeks.
This is not a read-as-you-go book. Many of the steps overlap, and each step is dependent on the steps that preceded it. It is also easier to understand each step if the reader has an overall grasp of the whole disentanglement process. Therefore, it is strongly recommended that you review all chapters before implementing the process. However, before becoming discouraged by the previous sentence, recall that each chapter concludes with a summary. You can get by with just the summaries as long as the chapter related to the disentanglement step that is being implemented is read in detail.
As this is a practical text (and not a theoretical one), many methods and techniques are described without their theoretical basis. Extensive references are provided throughout the book, however, for those interested in the theoretical background. A comprehensive list of references appears at the end of the book.
Before this book went to print, there was some discussion about whether a project can rightly be called a catastrophe when, in reality, we expect to rescue it (that is, is the state of being a catastrophe reversible?). The answer is evident to anyone who has worked at a large technology company and has heard a frustrated senior manager say: "This project is a catastrophe!" If the state could not be reversed, the project would be cancelled there and then. But what usually follows is, "We need to get it back on track immediately!" Well, that is exactly what this book is about.
The disentanglement concept is the product of many years of hands-on software project management at Motorola and at other technology companies, and the collection and analysis of software project development data from hundreds of development organizations. The book was preceded by a pilot paper with the same name, published in the U.S. Department of Defense Journal of Defense Software Engineering, CrossTalk.
I would like to acknowledge the tremendous assistance from Amir in producing this book. His contributions and reviews were invaluable.
E. M. Bennatan
January 2006
© Copyright Pearson Education. All rights reserved.