Every stakeholder has their own ideas about what is needed from an IT system. From first request through to final execution, the right methodology and support system can make for a harmonious approach to changes large or small. Danny Bradbury reports.
Nothing stands still in IT. Every week someone identifies a problem with the computing environment that needs fixing or improvement.
Ensuring that changes do not break other parts of the computing infrastructure can be a tough task for IT departments.
One of the problems with change management is that as it is such a nebulous topic it can be difficult for IT managers to define. For some, it includes release management and request management, while for others it focuses on the processing of changes.
For Debbie Rosario, a former change manager at Marks & Spencer who heads up the service management practice for Compass Management Consultants, it encompasses the ability to record change and to govern the entire lifecycle of that change through phases such as request submission, approval, testing and final execution.
Many companies do not understand the extent of the lifecycle, she says, adding, "Organisations also assume that if they have the right software it will take care of that for them. That is not always right. Software supports processes, which have to be robust."
The IT Infrastructure Library (ITIL) is one of the better known best-practice frameworks for service management and it incorporates change management.
Air conditioning and heating manufacturer Danfoss is rolling out ITIL across its entire infrastructure, having already tested it in its patch management processes, says Erling J¿rgensen, director of global IT service and support for the company.
Danfoss has moved gradually from using centralised mainframes towards a decentralised, mid-range server-based environment. Five years ago, it had three large mainframes and 200 mid-range servers. Today, it is decommissioning its mainframes, having installed another 800 servers. Danfoss already had an internal change management process but ITIL has made things easier.
"Now we have a framework in which we could easily train people," says J¿rgensen. "Instead of having training in-house and maintenance of procedures, we could go out and get many more consultants and services helping us with that."
Categorising and prioritising the incoming changes can help an IT department to manage them more effectively. Graham Youngs, service management consultant at QA Training, divides changes into three types: routine operations, mid-level changes and large roll-outs.
Routine changes effectively bypass the change approval process, he says. Adding a new user to Microsoft's Active Directory, for example, can be done in a standard way without affecting many other components of a company's computing environment, and so it need not get bogged down by approval processes. Mid-level changes, such as swapping out a disc on a Unix server, will not necessarily be visible to users but they are still important enough to be fed through the approval process.
"The roll-outs are where the release management process comes in," warns Youngs, who cites a Windows XP deployment for several thousand users as an example.
"You not only need to worry about the technicalities of the change, but there is all the other ancillary stuff you need to do like collecting systems, rebuilding them and training users on XP."
That sounds more like a separate project than a simple change to be sent through an approval process. Where do changes end and projects begin? It is up to each organisation to identify how risk-averse they are, says Youngs.
Impact analysis is a good way to help make that decision, and also to prioritise changes. Guy Lidbetter, chief technical officer for managed operations at Atos Origin, folds impact analysis into his internal ITIL-based change management process. "Let's say we need to do a patch on our NT servers. Where are they? Who's using them? Are they mission critical? 24x7? Who are the right people to engage? Is this is the sort of upgrade that needs testing?"
Having prioritised your incoming change requests, you must get them approved and tested. Finding a balance between thoroughness and speed can be a challenge. Ideally, all stakeholders within an organisation that would be affected by a change should be informed and given the chance to comment. In the real world, of course, the change may be needed quickly and it can be difficult to organise review and feedback in time.
ITIL recommends the use of a change advisory board: a group of stakeholder representatives who meet regularly to review the necessary changes.
"That can be a grand title for a small set of people but they would be the people with key ownership of those domains," says Terry Wilson, business development director for the operations support solutions business unit at IT services firm Dimension Data.
To better inform the change advisory board, the IT department should be able to produce some sort of test document highlighting the likely outcome of the change. Validating changes is an area that often confounds companies, either because of a lack of suitable testing equipment, or human resources.
David Arbo, director of security at global transportation service provider APL, has experienced particular problems around change management of his firewall infrastructure. "They are recorded, they go through the change management process, but validation has not got as much attention over time," he says. "We had a number of self-induced outages that happened as a result of making changes."
Arbo used Skybox Assure, a virtual staging environment for network infrastructure changes from Skybox Security. The system enables him to load new configuration files into an existing model of its network and evaluate the potential impact on data flow and system access.
Arbo is also rolling out a configuration management database (CMDB) based on Remedy to manage the organisation's wider computing infrastructure.
A CMDB is a useful tool for holding information about the dependencies between different elements of your computing environment, but service management tools, normally based on CMDBs, are not always without their problems.
For example, of a CMDB-based product that he has used J¿rgensen says, "It does not really follow the ITIL way, so you have to do a lot of customisation to the product, and you can do that, but it is very expensive."
Meanwhile, Arbo complains that CMDBs suffer from integration problems because of the large number of proprietary technologies, especially in the world of network infrastructure. "You are dealing with a lot of different technologies which presents an integration challenge when you go to a CMDB," he says.
"I may be able to take a policy configuration file and put it into the CMDB but it might not understand what it means." Hence the use of a specific modelling solution to help him manage firewall configuration changes.
Kris Brittain, research vice-president at analyst firm Gartner, agrees. "If I could build a CMDB - one giant repository with everything in it - I would have it whipped. But that is a nirvana, a utopian view. It is not likely," he says. "Most organisations will figure out that they are going to have have to federate multiple repositories." That involves another layer of complexity as you create policies to govern the flow of data between CMDB repositories.
Controlling complexity is another important part of any change management process. Starting simply is the key. Populating the database with a few key attributes will suffice, while overloading it will generate database bloat and make it more difficult to keep your CMDB up to date.
Structuring processes while keeping them streamlined and simple will help you to get a foothold in change management and prepare you to move towards a greater level of maturity in the future.
Finally, think about key performance indicators that can help you to monitor the effectiveness of your change management strategy. Rosario recommends KPIs tracking things like how many problems a change causes on average, how many changes were submitted without sufficient testing plans, how many changes needed to be rolled back, and the approval or rejection rate for changes. Such things will help you to refine your operations, going forward.
Change management does not have to be big and scary, as long as you take small, sensible steps. Doing so might help you to avoid spending the 60% to 70% of staff resources that Gartner says some organisations are wasting on change activity. And that is one change that everyone will want to see.
Case study: Ventura answers the call with automated support system
Call centre outsourcing company Ventura used to use a combination of e-mail requests and manual entries in an Access database to log and process changes. With 4,000 employees on its site and with 50 change requests coming in each week from a base of 250 IT employees, the company was beginning to outgrow the system and needed better automation, says business service desk manager Lee Madden.
Ventura was already using the Heat service management system from FrontRange for helpdesk purposes, and decided to modify it to support change management. It created a new call type and a front-end Lotus Notes form for the product, which allowed any staff member to enter a change request into the system.
This provided direct access to the change control process for a wider base of IT staff, who previously had to route all requests manually through a small change control team.
The new system allows the company to structure its change management around a predefined workflow. Changes can be assigned to various teams, who can then schedule times for the changes to take place so that they do not interfere with any other scheduled IT operations.
Ventura, which implemented the new change management system as it worked towards ITIL compliance, now has more visibility into change practices in different parts of the business.
"We can see if certain teams or areas of the company are requesting changes without adequate notice," says Madden, adding that the company has internal service level agreements dictating turnaround times on change requests. "We did spot that trend, and it has been addressed."
With enhanced change reporting also giving Ventura the chance to categorise changes according to the level of risk and impact on the organisation, change control meetings run more smoothly than before, freeing up IT staff.