Change Management Definition and Solutions

• What is change management?
• Why is change management so hard?
• What are the business benefits of change management?
• What is a change control board, and who exactly belongs on it?
• What is a change request, and what kind of information should it include?
• What are the intangible elements of successful change-management processes?
• How important is change management compared to other quasi-technical processes?
• What about the importance of change-management software compared to other business process or application lifecycle management tools?
• When is change management most important?
• What are some common change patterns that pop up that need to be managed?
• How do I put these common change-management patterns to rest?
• How do I measure the success of my change-management process?

How do I put these common change-management patterns to rest?
Mohan and Ramesh, who based their study on detailed observation of how a large supply chain management vendor evolves its software, have three recommendations for slaying the most stubbornly regular change dragons.

First, it's important to modularize change. This means that tweaks to code or the overall system should be isolated as much as possible from other changes. In the software world, using industry best practices such as design patterns and refactoring can help in this regard. If, on the other hand, you find yourself dealing with changes to an overall system, then your best bet is just to develop design guidelines and checklists that encourage this sort of modular approach.

Second, since it's not possible to completely isolate all changes, Mohan and Ramesh urge engineers and project managers to document the scope of the introduced variation. Like wildlife biologists putting radio collars on wolves to learn how and where the beasts roam, so too should software engineers watch how all introduced changes evolve through time. One way to do this is to build a traceability matrix or map, which situates each change in the context of the overall system and shows all dependencies.

Third, organizations should facilitate reuse and knowledge sharing. Engineering, finance, marketing, sales and IT should be reading from the same script, something that's made infinitely easier if you really are committed to sketching out and then using that aforementioned traceability map, which can be anything from a hyperlinked, text-heavy document to a detailed flow chart. If built correctly, the map will include explanatory notes about the rationale behind each introduced change, information that's especially useful when it comes to not reinventing the wheel.

How do I measure the success of my change-management process?
IT may once have been the province of freewheeling technology wizards and artists, but today the trend is to standardize and measure every aspect of operations. Dashboards and indicators are de rigueur. The "if it moves, measure it" ethic is especially rigid when it comes to process work such as change management. After all, change-management processes direct unforgiving quantitative scrutiny to nearly every corner of corporate operations. So it's only fair that change management itself be held to the same analytical standard.

Most firms track all change requests—number submitted, completed, in progress, failed and so on—to determine the percentage and quantity of change success. The problem with this method is that it treats all change equally. A better approach, and one that ensures that the collected data is more meaningful, is to first separate your change requests by business unit and risk, and then start measuring. Why? Because taking an afternoon to add a commodity server blade to your data center and taking three months to improve the warehouse-management system used by your global network distributions simply shouldn't be counted as equivalent accomplishments.

Science and technology writer Geoff Koch can be reached at koch.geoff@gmail.com.