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?
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.
