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.