RTM’d today: Software Change Management: Case Studies and Practical Advice

imageWe’re very eager to announce that Software Change Management: Case Studies and Practical Advice (9780735664753, Page count 192), by Donald J. Reifer, has shipped to the printer.

Why is it so difficult to change organizations? What does it really take to make “process improvement” yield measurable results? For more than 30 years, Donald Reifer has been guiding software teams through the technical, organizational, and people issues that must be managed in order to make meaningful process changes—and better products. This practical guide draws from his extensive experience, featuring 10 prototype case studies spanning the public and private sectors and even academia. Each case study illuminates the original conditions; describes options and recommendations; details reactions, outcomes, and lessons learned; and provides essential references and resources.

Contents at a Glance

CHAPTER 1  Getting Started
CHAPTER 2  Industrial Case: Organizational Change in a Large Information Technology Shop
CHAPTER 3  Industrial Case: Justifying a Process Improvement Program for a Large Bank
CHAPTER 4  Industrial Case: Moving to Commercial Off-the-Shelf and Open-Source Software Usage in Telecommunications
CHAPTER 5  Industrial Case: Small Defense Project Needs Help
CHAPTER 6  Industrial Case: Utility Moving to the Clouds
CHAPTER 7  Industrial Case: Adoption of Agile Methods
CHAPTER 8  Government Case: Large Defense Project Behind Schedule and Over Budget
CHAPTER 9  Government Case: Introducing New Technology
CHAPTER 10 Government Case: Maintenance Shop in Turmoil
CHAPTER 11  Academic Case: Establishing a Meaningful Collaboration with Industry
CHAPTER 12  Making an Impact


This book presents ten case studies that revolve around how to manage change in
industrial, governmental, and academic settings. Each case was selected to communicate
lessons learned that the reader can use to address typical issues that occur
during the process of change. Context-sensitive knowledge about how others managed
change within these settings is communicated by describing what others did when
faced with adversity.

Who Should Read This Book

This book was written to equip those making and managing changes in software
organizations with the processes, techniques, and tools that they need to be successful.
If you are involved in change initiatives, this book is for you because it points out what
the typical issues are that you will face and how others in similar situations have dealt
with them.

This book is targeted for consumption by a broad range of readers, from executives
to those software engineers who want to pursue change initiatives aimed at getting
the job of software development and maintenance done quicker, smarter, and better.
Professors will also fi nd this text helpful in communicating the fundamentals associated
with instituting and managing change in organizations. Entrepreneurs and business
people might want to take advantage of concepts included within the case studies that
describe how to facilitate making the changes necessary to transition products to market
quicker. Researchers might fi nd the text useful in structuring how they package their
new research developments for eventual commercialization.


This book expects that you have at least a basic understanding of underlying software
engineering and management fundamentals that set the context for the changes
described within the case studies. If you need refresher materials in these topics, you
might consider reading Steve McConnell’s Code Complete, Second Edition, (Microsoft
Press, 2004), Roger Pressman’s Software Engineering: A Practitioner’s Approach, Seventh,
Edition (McGraw-Hill, 2009), and Donald Reifer’s Software Management, Seventh Edition
(Wiley IEEE Computer Society, 2006).

Who Should Not Read This Book

While this book might be interesting reading for entry-level software engineers, such
readers need to be warned that the book presents only the background information
needed to understand the management structure, industrial practices, implementation
issues, and underlying technology for each of the case studies covered. Because
the knowledge needed to fully understand the issues more deeply can take years to
learn for the uninitiated, these readers and others from non-software backgrounds are
warned that some of the discussions on how to resolve problems may be beyond their
capacity to fully understand.

Organization of This Book

This book is organized around ten case studies. Chapter 1, “Getting Started,” presents
some background and context materials for these cases, while Chapter 12, “Making an
Impact,” provides a summary of lessons learned. The other ten chapters focus on learning
experiences presented as case studies that range from making needed organizational
changes in a large Information Technology (IT) shop to addressing adoption of
Agile methods in a smaller, high technology organization. While based on real-world
experiences, all of the cases represent fi ctitious examples developed to highlight different
change management messages. Each of these ten cases is trying to communicate
that change is hard and no matter what you do to facilitate the transition to something
new, people will resist it. In response, each case tries to highlight the change management
principles you can use to make the change and get the job done, often over the
objections of others who are more comfortable with the status quo.

Online Companion Content

For those using this text in software engineering courses, I have authored an Instructor’s
Manual. The purpose of the manual is to help the instructor organize discussions
for each of the ten case studies presented in a systematic manner. The manual might
also assist others reading the book to determine all of the messages that the cases are
trying to communicate. It was fun to write and should be fun to read.

Comments (1)
  1. Luigi Bruno says:

    Software management changes is one of the biggest challenges for software engineers: this book could be very useful.

Comments are closed.

Skip to main content