Donald Reifer: “Software Change Management: Doing More With Less”

Donald Reifer here. Many firms are currently searching for ways to save money and cut cycle time in these times of economic contraction. To achieve these ends, many are trying to find ways to cut their costs and spur productivity growth. For example, some are simplifying their software development processes while others are out-sourcing work to try to realize such benefits. But, any change, no matter how trivial, can have adverse effects especially when the staff is not properly prepared and trained to accept it. Take something as petty as introducing a new trouble report. While the goal may be to simplify and reduce the effort associated with collecting defect data, the effort associated with training and bringing people up to speed so that they can effectively use it may diminish the anticipated returns on investment. Fred Brooks in his classic book The Mythical Man-Month (Addison-Wesley, 1975) summarizes the phenomenon when he says that adding people sometimes makes a project later because staff doing productive work has to be reassigned to train the new hires. The lesson learned is that change, no matter how trivial, must be managed carefully. Else, the anticipated results may not be realized.

My new book Software Change Management: Case Studies and Practical Advice (Microsoft Press, 2012) tries to arm its readers with the insights needed to manage change and achieve the benefits they are seeking. It does this by putting the reader in the driver’s seat as it tours ten realistic case studies which examine what can happen when embracing change. Looking at the cases, readers see a number of common themes which they can address in order to increase their chances of success. Take a hypothetical organization that is trying to do more with less by automating its regression testing processes. To do this, they must introduce new processes and tools into a test organization that is understaffed and under the gun to get their product releases to their clients according to aggressive schedules. The three key questions that need to be answered include, but are not limited to, the following:

Is your organization ready for the change?

  • Have the organizational issues associated with the change been addressed? If there is an organizational process, the test processes have to be changed to reflect the new approach. In addition, the new processes being introduced have to be compatible with others (configuration management, defect reporting, distribution management, etc.) that the testers will use to perform their jobs. In addition, tooling needs to be compatible and operate with other automation already in place for developmental activities.
  • Do you have a viable plan for implementing the change? The tasks associated with introducing the test automation effort need to be detailed, realistic schedules and budgets need to be set and tracking/measurement mechanisms need to be put in place to be able to assess whether or not the goals set for the effort, both technical and programmatic, are being realized.
  • Do you have a sponsor and champion for the change? In addition to a sponsor for the effort, an executive champion for the change is needed to help win the battles of the budget and buffer those leading the change from interference by those who want to see it fail (i.e., especially those competing organizations making a play for the staff or budget as change budgets are often grabbed from others allocations).
  • Does the staff buy into the change and see its benefits? Those affected by the change need to buy into it. Else, they will not be committed to implement it. Sometimes overworked people might even avoid using something new especially when it gets in their way of performing their jobs. The best approach is to sell them on the personal benefits of change. When people are under the gun, they will embrace only those changes that help them get their jobs done more quickly and better.
  • Has the staff been prepared to implement the change? Adequate preparation in terms of orientation and training is a must. In order to meet their on-going commitments, your staff needs to be able to implement the change as part of their work related assignment. This is best achieved through some “Just in Time’ training where skills, knowledge and abilities are developed on-the-job.

Are the changes that you are making realizing their potential?

  • Is change progress being tracked and managed to ensure that the test automation fully realizes its potential? Having a plan is one thing. Implementing the plan in the context of how the organization does business is another. While planned correctly, most change initiatives fail due to lack of measurement and follow-through. Someone needs to be put in charge of the change and made responsible. This person needs to assess progress and take the corrective actions needed to keep the effort on track.
  • Are the risks that materialize during implementation being effectively management? All management I believe is some form of risk management. In response, risks associated with the initiative like staffing up and procurement problems need to be identified, tracked and mitigated. Having an issues and “top 10” list are a good first step especially if they are reviewed periodically with upper management.

Are you ready to declare success and move on?

  • Am I ready to move on? Many change initiatives fail because they do not know when to declare success and move on. Records need to be finalized, staff needs to be reassigned and recommendations for improvement need to be documented. The natural end of an initiative is when its goals are realized. In the case of testing, the effort is over when the automation infrastructure is in place and being used operationally to test releases.

These pointers summarize some of the advice offered to those trying to embrace new ways of doing business. I encourage those interested in learning more to read my book’s case studies. If you need insight into the cases, I suggest that you download my Instructor’s Manual. This document highlights key points in each of the cases and summarizes lessons learned.

Happy New Year, everyone.

Skip to main content