Change Management Definition and Solutions

Change Management (CM) topics covering definition, objectives, systems and solutions.

What is change management?

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.

Why is change management so hard?

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.

What are the business benefits of change management?

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.

What is a change control board, and who exactly belongs on it?

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.

What is a change request, and what kind of information should it include?

The aforementioned change control board doesn't while away precious time on half-baked, what-if ideas. Rather, the board should require that all proposals be submitted as well-formed and standard change requests. Does the proposal:

  • adequately present the risk level associated with the change?
  • thoroughly describe the change, including how it was tested?
  • provide a plan for backing out and reversing course if things start to go wrong?
  • list the prerequisites and other changes that have to take place in order to ensure success?

If the answer to any of these is no, the change request likely should be rejected.

Change requests also should include sufficient technical information about the change. It's fair to ask for such details as existing and required network topology and configuration, physical server rack layouts, software versions and configurations, security solutions, and port assignments and addressing.

This geeky minutiae is mostly about ensuring due diligence and creating a paper trail. In fact, most change control boards don't actually do detailed technical vetting of change requests, a task better left to assigned sub-teams of technology specialists.

In many ways, a change request can be thought of as a story submitted by a cub newspaper reporter to a seasoned editor. The story should have multiple, credible sources and look at the issue at hand objectively and from a variety of viewpoints. And the editor generally shouldn't spend his time nitpicking about particular statements of fact or opinion but rather making sure the story hangs together overall and fits into the broader context of the day's news.

What are the intangible elements of successful change-management processes?

There is no one recipe for change-management success. Details vary widely depending on industry and context. Are you releasing software to the public? Upgrading an ERP system for internal users? Overhauling your organization's external website? Each of these, a tiny fraction of dynamic situations presented to CIOs on a regular basis, presents a unique change-management problem.

However, successful change-management solutions generally have a host of attributes in common, many of which are related to your organization's emotional intelligence and behavioral norms.

Topping the list is the culture that recognizes the need to adapt and is committed to persevering through the inevitable speed bumps on the road to change. Usually this requires the support of top management. Stories abound of well-intentioned IT and developer managers who for years would send their teams to classes on best practices in change management. Back in their cubicles, the employees would attempt to implement what they learned, at least until they realized their counterparts in other parts of the company weren't subject to the same process-heavy strictures. Only when top brass mandated and measured all teams on their commitment to the same processes and tools would these best practices stick.

Being hyper-attuned to customers and users also helps. Ideally, organizations should embrace and encourage feedback from those impacted by change rather than seeing customer opinion as an impediment. This means setting up some means to support and involve customers and users. Peruse the business press today and you cannot miss articles about edge-driven innovation, the wisdom of crowds and so on. The fact is, listening is hot, while ramming through change is not.

This is not to say that the masses get everything they want. To support the inevitable crowd that will be unhappy with changes to their treasured application or service, change management also requires robust education and training, and not just for customers and users. Training should start with the IT workforce that will be tasked with implementing and supporting change and then build out from there.

How important is change management compared to other quasi-technical processes?

Change-management success depends more on your team members' ability to relate to each other and to customers than on hardcore technical skills such as, say, refactoring. Fine. But where exactly does change management rate among all the other can't-we-all-just-get-along goals spouted by helpful human resources departments everywhere?

The answer, according to a 2006 research article in The Journal of Computer Information Systems, is smack dab in the middle. Fiona Fui-Hoon Nah, an associate professor of information systems at the University of Nebraska-Lincoln, and Santiago Delgado, a product manager at National Instruments in Austin, Texas, administered surveys and conducted interviews about ERP implementations and upgrades at two large, creaking bureaucracies—a public university and a government-owned utility.

During havoc-wreaking ERP implementations, the researchers found that team composition, top management support and organizational communication proved more important than change management. During ERP upgrades, change management fared similarly, coming in fourth behind team composition, organizational communication and project management.

This is not to diminish the importance of change management, which the authors say belongs on any list of critical success factors for big projects. Rather, it's a reminder that even the best change-management plans can go awry if other organizational processes are not up to snuff.

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.

1 2 Page 1
Page 1 of 2
NEW! Download the Winter 2018 digital edition of CIO magazine