- 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?
Here's a quick quiz. Change management is: a) software that automates the process of tracking and documenting changes to a code base or IT system; b) a process gleaned from books, classes or overpriced consultants to help streamline technology-related change; or c) an intangible, impossible-to-teach part of individual and organizational character that embraces the inevitability of and opportunity associated with change.
Stumped? You should be, because the correct answer is: d) depending on the situation, some combination of all or none of the above.
Less ambiguous than the definition of change management are the reasons why dealing with change is more difficult than ever.
First, across industries, the race is on to shrink time to market and time to value, whether for a blockbuster product or an important application for internal users. Second, due to the flattening effects of globalization, competition is increasingly fierce. As a consequence, CIOs are under pressure to constantly upgrade existing systems or implement new technologies either to maintain the organization's leadership or, more often, just to keep up with the pack. Finally, technology complexity is on the rise thanks to a host of environmental factors, from mergers and acquisitions to increasing regulations, to the pressure to expose more and more formerly glass-house IT shops to the wider world via service-oriented architecture (SOA).
In short, the rubber is meeting the road when it comes to change management, a business process that historically has been long on good intentions and short on execution. Why? Because setting up and following a change-management process involves generating and then following multistep business process flow charts, holding regular meetings to discuss the finer details of design and feature enhancements or system configuration changes, diligently churning out voluminous documentation and a host of other prosaic tasks.
Ask a random sampling of technology managers if change management is important, and expect nearly all of them to emphatically say that, yes, of course it is. Ask the same people to show their up-to-date library of documentation inventorying their organization's network devices, hardware and software configurations and versions, naming standards and the like, and get ready for mumbled excuses and averted eyes.
Even a semi-serious attempt at instituting change management is going to take the valuable time of several of your organization's most valuable employees. Inevitably someone will ask whether all this process stuff is worth the trouble. It more than likely is when you consider the various payoffs.
For starters, change management helps to lower risks associated with change, eliminate resource conflicts and redundancies, and learn from successes and mistakes of the past—all of which help CIOs and other senior managers to save money.
Change management comes with a smattering of strategic benefits as well. Done correctly, these processes will provide a comprehensive picture of the organization-wide impact of change and enable managers to make contingency plans based on real-time project status.
Finally, change management can offer a backdoor means to achieving the near-universal goals of increased internal teamwork and external end-user satisfaction. This is somewhat counterintuitive, as anything related to the word "process" often connotes a soul-sucking onrush of flowcharts, checklists and, worst of all, endless meetings. But the fact is, when everyone is in the loop and projects become more orderly affairs, teams are happier and often produce better, more customer-friendly results.
Inspect any worthwhile change-management flow chart and you will notice that the process invariably involves at least one stop at a change control board.
Let's enunciate what this board is not. It's not a bureaucratic purgatory where good ideas go to die. Nor is it a parking lot for your junior varsity-level performers who aren't quite cutting it in their regular jobs.
Rather, creating a change control board is about making sure that good ideas have the best chances of success. Accordingly, the team should review all change requests based on completeness, organizational readiness, business impact and business need. Other responsibilities include scheduling the change, communicating the change to all affected parties and coordinating user training.
It's the sort of rigorous, multifaceted work that often requires a diverse array of top talent drawn from around the organization. Depending on the nature of your business, it can be reasonable to seek representation from finance, operations, engineering, sales, service, IT and other units. Picking some of your best and brightest to staff the board comes with an important secondary benefit as well: Namely, the rest of your organization is far more likely to accept the edicts of the board if it is mostly made up of the A-listers whom everyone respects.