The following review is republished here with the permission of Robert L. Glass. The review appears in the May-June 2012 issue (Volume 22, No. 3) of The Software Practitioner, a bimonthly newsletter “written by and for people who build software for a living.” (Thank you, Bob!)

Software Change Management: Case Studies and Practical Advice

By Donald J. Reifer
Published by Microsoft Press, 2012
Review by Robert L. Glass

The most quickly informative part of this book is its subtitle. It is about case studies that describe major change activities.

And wondrous case studies they are. They’re not just simple little goody-goody stories about how change has been accomplished. They are instead stories of criticalchange activities of our time, hitting the hot button issues of the 2010s – such things as changing to cloud computing, transitioning to agile development approaches, and the saga of a small company wrestling with the huge paperwork requirements of government contracting. They reek of realism, even going so far as quoting one change participant as saying “the battle has just started and you better check and double-check all your numbers,” because the enemy parts of the organization will “use every trick in the book to discredit you.” Of the horror stories in the book, perhaps the most awful is the one about that small but innovative company that wins a government contract to commercialize their innovation, only to have to come close to deciding to give up on the whole matter because the government reporting requirements are too onerous.

Following the book’s case studies, the final chapter is a brief but information-packed summary of the book’s message. That chapter begins with “The 10 case studies in this book should provide you with a lot of food for thought about what the real issues are for those of us who are trying to make needed changes to development processes. The cases amplify the point that all barriers to change are psychological and managerial.” And then begins that information:

10 secrets of success:
1.   View change from multiple perspectives.
2.   Emphasize change roles and defined processes as you roll out the innovation.
3.   Look for the obvious and the low-hanging fruit as the first order of business.
4.   Most barriers to change are psychological and behavioral.
5.   Even when you think the need for change is obvious, barriers to it can pop up from the most unexpected sources.
6.   Always tie change to business objectives. Then, when presenting justifications for the change, let the numbers do the talking.
7.   Not all change is good. Sometimes it makes sense not to pursue it.
8.   Do not lose sight of marketplace discriminators when making changes.
9.   Control the controllables, and do the things that you can do.
10.   Do not forget that you need to expend the effort to make a product out of the technology.

And then there are the “Dirty dozen lessons learned:”
1.   When identifying issues that impact cost, productivity, and quality, dig deep to identify both the issues and root causes.
2.   Use industry benchmarks from reputable sources to establish cost, productivity, and quality baselines for comparison and justification of changes.
3.   Improvements will always take longer than expected. The reason for this is simple. Motivating change is hard and breaking down barriers takes time.
4.   Use actual results whenever possible to gain momentum to get change adopted for widespread use. While skeptics might not believe the numbers, presenting them provides powerful evidence that the change is worthwhile.
5.   To win the battles of the budget, it is important to come to the fight armed with a business justification for your expenditure, an idea for where you will find the money, and a plan for achieving the desired results.
6.   There may be hidden issues that influence decisions relating to change. Late-emerging issues can be the major drivers that govern which option is selected.
7.   Those who foster change need to anticipate the perceived threats, and develop plans to address them as part of their efforts.
8.   Getting people to deliver what they promise often takes patience, effort, and diligence. Many will do a good job.  Others will let you down.
9.   What works in the small does not always work in the large. This fact cautions us to be careful when trying to scale techniques that work in a laboratory to businesses at large.
10.   Do not forget to keep management and stakeholders apprised of your progress and issues.  Without current information, management support can seemingly waiver overnight even when you
have high-level champions for change in your corner.
11.   Partnering with potential users is a good idea, especially when it requires all parties to make commitments of time, staff, and money to the cause.
12.   Understand the work that needs to be performed before developing plans to handle it.  As you peel the onion, you may be surprised to find tasks that you did not have any idea that you were expected to perform.

And finally, there are the 10 tools and techniques to rely on:  

Startup phase:
1.   Work Breakdown Structure
2.   Critical Path analysis
3.   Benchmarks
4.   Root cause analysis
5.   Fishbone diagrams

Implementation phase:
6.   Rate of progress charts
7.   Gantt charts
8.   Risk matrix

Assessment phase:
9.   Project retrospective
10.   Defect measures

The items in each of these lists are elaborated, of course, in that final chapter.

The case studies are full of pros and cons and pitfalls that might be encountered along the way to change. The book is very realistic, but perhaps a little too frightening!