| If you are not familiar with ITIL
Change Management then you should understand the
difference between Change Management and Change
Control under ITIL if you want to maximise your
chances of producing a strong argument to justify
ITIL Change Management. ITIL defines Change Control
as:
The procedure to ensure that all changes are controlled,
including the submission, analysis, decision making,
approval, implementation and post implementation
of the change.
Whereas ITIL describes Change Management as:
The process of controlling changes to the infrastructure,
or any aspect of services, in a controlled manner
thus enabling approved changes to be implemented
with minimum disruption.
The key to the difference is at the beginning of
each statement, Change Control is a procedure whereas
Change Management is a process. In other words there
may be many changes being controlled under the Change
Management process. Each change needs good Change
Control but the Change Management process oversees
all of the changes. It is possible to have good
Change Control but failures because there is no
Change Management. For example two different IT
teams are each working on separate changes that
will change the same server, both teams control
their changes very well but problems happens at
implementation because there was no communication
between the teams and one change is having a detrimental
change on the other change. With Change Management
the fact that two teams were going to change the
status of the same server would have been noticed
and those teams would have been asked to liaise
and communicate with each other and therefore eliminate
the change failure. So in any way you could say
that Change Management simultaneously manages the
life cycle and status of many controlled changes
because Change Control is a component of Change
Management.
It is no surprise that because Change Management
is extensive that The ITIL goal is comprehensive:
The goal of the Change Management process is to
ensure that standardised methods and procedures
are used for efficient and prompt handling of all
Changes, in order to minimise the impact of Change-related
Incidents upon service quality, and consequently
to improve the day-to-day operations of the organisation.
To make an appropriate response to a Change request
entails a considered approach to assessment of risk
and business continuity, Change impact, resource
requirements and Change approval. This considered
approach is essential to maintain a proper balance
between the need for Change against the impact of
the Change.
It is particularly important that Change Management
processes have high visibility and open channels
of communication in order to promote smooth transitions
when Changes take place.
Let us break this rather large goal down into its
fundamental components and see what we can identify
to help justify ITIL:
To minimise IT failures caused by changes made
to IT infrastructure — this is a wonderfully clear
statement that quantifies the over-riding responsibility
of Change Management. The question is do you get
any new incidents or problems as a result of failed
changes, or changes that have ‘worked’ but created
new incident or problems in other IT Infrastructure
components? For example a new software item is added
successfully but there is not enough memory so performance
is inhibited. If you are not sure analyse your Incident
and Problem Data Bases to see if any evidence exists
to prove failed changes. Use this data to prove
that you are missing this Change Management goal.
A good idea is to ask the Service Desk staff for
examples because if changes are failing they will
be only too willing to help!
Efficient and prompt handling of changes — here
we are concerned with the scheduling and timing
of changes. If you have a central point for the
registration and management Change Requests then
you should take a cross section of these to determine
what percentage of changes are late or delayed.
This will provide the data for proving whether you
are meeting this component of the Change Management
goal. However if you do not have Change Management
at the moment this may be difficult to quantify.
For example if you do not have a central point to
manage Change Requests how will you determine how
many changes were implemented late? First of all
not having a central point is justification for
Change Management itself, how can you manage change
if you do not know which infrastructure items you
are changing or when you will be changing them.
You may be able to perform some detective work by
interviewing customers to get their opinions on
how change is managed at the moment or collect and
analyze any change requests that exist at the moment
in different IT locations. However you obtain the
data this is an important topic because change scheduling
and timing is the key to successful Change Management.
Ensure standardised methods and procedures are
used — traditional each IT department has employed
its own method to control the cycle of changes under
their domain. This cannot be the case if different
departments are to work together on the same change.
One of the most demanding challenges with modern
changes is not the success of the change itself
but on ensuring that the environment around the
change can successfully accept the change. For example
a change to a network browser may mean more memory,
software upgrades to other components and training
for the users and if everything is not ready at
the same the change will fail or cause problems.
Therefore standardised methods and procedures are
critical. This is an easy goal to check because
either you have standardised methods or procedures
that are documented and imposed or you do not. If
you do not you should make the case that if different
teams working on the same change are not following
standardise methods and procedures the chances for
failure are much higher, you may be able to prove
this from failed change data.
Assess risk, impact, cost, and resource requirements
for all change requests — the secret here is that
you cannot have isolated pockets within IT making
decisions of this magnitude. These decisions can
only be made centrally with all affected parties
providing input and information. Too often the ROI
(Return-On-Investment) for a change is false because
it does not include components from other IT teams
contributing effort to the change. If IT does not
the cost of changes how can it plan budgets and
investments? If IT does know how many staff are
working on changes how can it schedule its staffing
levels? If IT is not jointly assessing risk who
is? If IT is not jointly assessing impact affecting
changes there will be more calls to the Service
Desk. Today simple changes can seriously affect
organizations if they fail and in some cases affect
the bottom line. So for this goal it is more a case
of stating the potential affect of getting these
items wrong rather than producing evidence to prove
failures.
Maintain balance between impact and cost - there
is a fine dividing line here between the potential
impact, benefits and deliverables from a change
when balanced against the cost of implementing a
change. For example there may be a Change Request
to remove a Problem that is causing 3 calls a day
to the Service Desk with very little impact on the
business; this seems like a good idea but what if
it is going to $200,000 to perform the change? This
is an exaggerated example but makes the point that
deciding between impact and cost requires careful
consideration. This is a difficult goal to prove
because you will not find it easy to obtain hard
data to prove your point therefore you must again
make the case for managing Change Requests centrally;
true costs will be identified because all teams
working on a change will be asked to provide input
while impact can be reviewed from different parts
of IT and from the customer viewpoint.
Maintain high visibility and effective communication
with both IT staff and business users — in simple
terms the feedback of the status of changes at regular
intervals to all interested parties. This is a simple
goal to prove because either you do it or you don’t!
If you are not this in itself is a justification
for Change Management.
Change Management is one of the keys to the future
success of IT within an organization. It is now
part of business processes and totally integrated
into the fabric of normal business activities therefore
failed changes, late changes, over budget changes,
under resourced changes, badly communicated changes,
isolated changes and poorly handled changes cannot
be tolerated. Be sure though to remember the difference
between Change Control and Change Management.
Business alignment indicator — there are so many
potential business alignment indicators here that
it can be daunting. However the key point to remember
is that the customers must be involved at all stage
of all Changes that will affect their environment.
This is best achieved by on-links so that the customers
can follow their Changes and contact IT with any
questions or concerns. This goal states ‘enabling
changes to be implemented with minimum disruption’
so this is where will concentrate. First of all
if a Change is the source of a new Incident then
the customers must notify the Service Desk when
they report the Incident. It is not always possible
for the Service Desk to relate an Incident to a
Change therefore it is important that the customers
play an active role if they do not then it will
be difficult for IT Service Management to meet this
goal because if IT do not know that a Change has
created new Incidents then they cannot put in place
measures to stop the same thing happening again.
When planning the implementation date of changes
it is important that customers are both involved
in this planning, because they may want some blackout
dates for business reasons, e.g. suspending any
Changes to the Payroll system for a period because
a new pay structure is to be implemented or suspending
Changes to financial systems at year end.
|
