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.