Donald J. Reifer - Software Change Management: Case Studies and Practical Advice

Copyright 2011

Microsoft Press books are available through booksellers and distributors worldwide. If you need support related to this book, email Microsoft Press Book Support at .

Microsoft and the trademarks listed at http://www.microsoft.com/about/legal/en/us/IntellectualProperty/Trademarks/EN-US.aspx are trademarks of the Microsoft group of companies. All other marks are property of their respective owners.

The example companies, organizations, products, domain names, email addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred.

This book expresses the authors views and opinions. The information contained in this book is provided without any express, statutory, or implied warranties. Neither the author, Microsoft Corporation, nor its resellers or distributors will be held liable for any damages caused or alleged to be caused either directly or indirectly by this book.

When youre making decisions about addressing upcoming opportunities and challenges, it is a good practice to do an Analysis of Alternatives. And it is also a good practice to include Dont change what youre currently doing as one of the alternatives. In many cases, this can be the best alternative, as reflected in such maxims as If it aint broke, dont fix it, Plan the flight and fly the plan, and Hold steady on the course.

But there are more and more situations in which Dont change is a very risky alternative. A good set of examples is the analysis in Eberhardt Rechtins book, Systems Architecting of Organizations: Why Eagles Cant Swim. Rechtin explains why on six successive satellite system replacement competitions, the more experienced incumbents just did some modifications of their previous winning designs and lost to more innovative competitors. In order to remain competitive in a world of increasing change velocity, youll want to consider alternatives to Dont change, and to provide evidence in your Analysis of Alternatives to opponents of change when Dont change is not a good idea.

Is the velocity of change all that rapid? In 2006, I published a paper[] that tried to anticipate future trends and to prepare organizations for accommodating them. By 2011, I found that I had not covered several trends that turned out to be further game-changers for organizations. Most of them were software-intensive: service- oriented cloud computing; social networking technologies; mega-sensor-intensive smart systems; multicore chips requiring software parallelization; and search and mining of ultra-large data aggregations. And the pace of change continues to accelerate, not just in technology, but also in competition and the marketplace. Not only is it important to monitor these changes, but its at least as important to master the art of making successful organizational change.

This is what makes Don Reifers book particularly timely and helpful. Getting an organization to change requires getting many stakeholders and suborganizationswho often wont want to change or would like to manipulate the change to increase their power baseto come together, to agree on a mutually satisfactory change strategy, and to contribute their key resources to making the change successful.

Besides Dons technical contributions to such areas as cyber security, cost estimation, business case analysis, software project management, and software maintenance, he has been an effective change agent as a consultant to a remarkably wide variety of organizations. These include large and small financial, telecommunications, aerospace, software tools, gaming, and Internet startup companies, and public service organizations. In the book, he provides case studies drawn from these various sectors that illustrate how they have dealt with the need for change to address opportunities or problems at a project, department, business area, or enterprise level.

Along the way, the generally successful case studies illustrate pitfalls to avoid, such as trying to change things outside your span of control, neglecting to provide incentives for change to success-critical stakeholders or leaving them out of the planning process, trying to change too many things in one step, and failing to provide a sound business case for a change initiative.

The diversity of the case studies means that not all of them will be relevant to everyones situation, but that most people will find some of them to be highly relevant. And the diversity is brought together in the final chapter, which includes ten change management secrets of success; a dozen change management lessons learned; ten useful tools in change management; and summaries of change management critical success factors in dealing with senior managers and in dealing with the workers who will implement the changes. As a bottom line, this book can be very valuable in helping you cope with the increasing pace of change that youll encounter during your career.

Barry Boehm

September 2011

The phrase software process improvement has become a catchphrase for the software industry and occurs hundreds of times in monthly journal articles and also in scores of books. But what does the phrase really mean and how do the concepts get applied in the real world? Don Reifer has been studying software in major companies for many years and has assisted many in improving software development methods and practices.

Process improvement is closely linked to change management. Change in corporations is sometimes glacial and often resisted strongly. Dons book includes some interesting factual information, and also procedural information, about introducing both structural changes and organizational changes that do not disrupt ongoing operations.

At the level of individual projects, change control is also a critical factor. In fact, from my observations while working as an expert witness in software litigation, the two main sources of lawsuits are poor quality control and poor change control.

The measured rate at which software projects change is between 1 and 2 percent per calendar month. For large systems with schedules in the 36 to 48 month range, more than 25 percent of the features that are present at delivery were not there when the requirements were first defined. They came in later due to either incomplete requirements gathering or external business changes that were not predictable.

Dons new book is not a theoretical treatise on change management and software process improvement, but rather its a series of a dozen empirical case studies from both companies and government groups. The book also covers improvements in both development and maintenance operations.

Software change management and process improvement involve more than mere acquisition of a few tools that support specific methods such as Agile or the Team Software Process. Rather, the issues addressed include a full spectrum of organization topics, methodological topics, tools, and the measurement and reporting of improvement results. In fact, the measurement and reporting of results has been the Achilles heel of many process improvement attempts. The organizations may get better, but if they dont measure the improvements and the costs needed to achieve the improvements then fairly soon top executives will cut off the funding.