ARN

Change Management 101: An executive guide to change management

A few painstaking steps offer numerous payoffs

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 organisational 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 globalisation, competition is increasingly fierce. As a consequence, CIOs are under pressure to constantly upgrade existing systems or implement new technologies either to maintain the organisation'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 organisation's network devices, hardware and software configurations and versions, naming standards and the like, and get ready for mumbled excuses and averted eyes.

Page Break

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 organisation'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 organisation-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, organisational 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 organisation. 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 organisation is far more likely to accept the edicts of the board if it is mostly made up of the A-listers whom everyone respects.

Page Break

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 organisation's external Web site? 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 organisation's emotional intelligence and behavioural norms.

Topping the list is the culture that recognises 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 realised 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, organisations 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.

Page Break

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 organisational communication proved more important than change management. During ERP upgrades, change management fared similarly, coming in fourth behind team composition, organisational 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 organisational 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 catalogue 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 organising the stack in a decidedly low-tech “napkin organiser.” In contrast, he declared his change-management software to be the heart of his development process and the glue among his developers, testing organisation and wider community of users.

Page Break

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.