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?

What about the importance of change-management software compared to other business process or application lifecycle management tools?
Change management, though mostly about the human touch, also frequently requires various software tools. Especially in the world of application development, an array of such tools exists—some commercial, some open source. These tools can be essential, especially when they can automatically catalog all changes to a code base associated with a given change request.

Having a detailed record of changes is required in highly regulated industries, such as food and pharmaceuticals. Indeed, in the wake of Sarbanes-Oxley (SOX), the change-management system of any publicly traded company is potentially fair game for government regulators.

Those steeped in code say good change-management software is potentially more important than other process-focused tools, such as those handling configuration and requirements management.

One veteran coder told me the reality is that most development teams end up maintaining just small, functional subsets of the larger software program, hardly enough to justify using a configuration management tool—no matter the price. And capturing requirements, he said, could be as simple as scribbling on napkins and then organizing the stack in a decidedly low-tech "napkin organizer." In contrast, he declared his change-management software to be the heart of his development process and the glue among his developers, testing organization and wider community of users.

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 endeavors. 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 flavors. 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 flavors—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 labored 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.

Continue Reading