When is change management most important?
According to academics who study the stuff, most technology-related projects follow a natural arc. In their 2006 paper, Nah and Delgado describe a four-stage model that appears frequently in information systems literature.
First is the chartering phase, which focuses on the business case for the project. Next comes the project phase, which comprises configuration, rollout and integration with existing business systems. Third is shakedown, the bug-fixing phase between going live and commencing normal operation. Last is onward and upward, which is mostly about regular maintenance and small-scale enhancements.
Not surprisingly, change management is most important during the project and shakedown phases, the most dynamic and stressful times of many technology endeavours. Here's a rough rule of thumb: When the time comes to inform and then train and support users to deal with a new application or service, you better make sure that a reasonably robust change-management system is in place. When you are focusing on planning, or after your users are a mostly contented bunch, you can ease off the change-management gas.
What are some common change patterns that pop up that need to be managed?
Declaring that it's important to manage change is one of those controversy-free platitudes in technology. Everyone agrees with the statement. No one knows exactly what it means.
However, there are some common change patterns that crop up in many complex hardware- and software-dependent applications. Three of these patterns are spelled out in a December 2006 article in Communications of the ACM by Kannan Mohan, an assistant professor of computer information systems at Baruch College in New York, and Balasubramaniam Ramesh, a professor of computer information systems at Georgia State University in Atlanta.
One pattern is the issue of often hidden interdependencies, particularly as applications evolve into various flavours. You know that algorithm marketing has been begging you to add to version 1A of your company's flagship application? Turns out it conflicts with a key feature of version 1B, a problem since many of your customers run both versions of the application depending on the business unit.
Another is the rapidly increasing degree of variance. If your vanilla application or service casually begets four variations, and then before you know it each of these begets four more, that's 16 different flavours — great for an ice cream store, but awful for a technology shop tasked with support, maintenance and service.
Finally, there is a resource-draining pattern of reinventing functionality. That algorithm you just laboured over for the better part of three weeks? The guy three cubicles over produced one that's astonishingly similar six months ago. You would be worried about getting in trouble for wasting precious time and resources if everyone were not so painfully aware of the fragmented nature of your firm's application engineering process, an unfortunate reality for many technology teams.
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 modularise 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, organisations 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 standardise 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 centre and taking three months to improve the warehouse-management system used by your global network distributions simply shouldn't be counted as equivalent accomplishments.
