Serviceware Blog

IT Change Management
according to ITIL

Roles and responsibilities in the ITSM change management

process, goals, the 7 Rs, and differences between ITIL v3
and v4 – to keep you on top of things in ITSM.

Contents:

The 7 Rs of IT change management

Standardized processes via ITSM tool
Best practices and pitfalls
Organizational change management: Focus on people
Differences between ITIL v3 and v4 in IT change
management
Success factors in IT change management

What is IT Change
Management?
Changes in IT can quickly lead to problems: Be it the simple
replacement of a workstation computer, the introduction of
new software, a switch to the cloud or increased security
requirements. In order to optimally implement such
innovations in the company, firmly defined processes help.
With change management, the entire process can be better
planned. This minimizes risks and avoids interruptions. The
goal is to always further develop the existing IT strategy.

The 7 Rs of IT change
management
The 7 Rs of IT change management are a checklist of
relevant aspects that should be considered when creating
and processing a change request. The seven simple
questions help to launch changes in a structured way,
which would otherwise be rejected because of too many
ambiguities.

1. Who RAISED the change

request?
In the abundance of departments, contact persons and co-
decision makers, change requests on demand are a
guarantee for chaos. First, we need to clarify where the
request comes from. For whom are we doing this? Where
do I get answers to queries? Systematically documenting
this is the first step for structured IT change management.

2. What is the REASON for the

change?
Why are we doing this? For what reason is the change
needed? A good solution is worth nothing if it solves the
wrong problem. On the other hand, a change often
sketches out solutions that block the view of a better idea.
If we gain clarity about the reasons for the change, risks and
opportunities can be better assessed. For important issues,
we then look for the solution that best fits the context,
while avoiding high-risk changes with minimal business
benefit.

The portfolio analysis along the four-field matrix helps with

the classification, whereby the changes can be sorted along
the two axes (1) impact (e.g., number of users and devices)
and (2) urgency, similar to incident management.

3. What RETURN is required from

the change?
Nobody knows the future and yet it is important to play out
different scenarios. What should the change result in, so
that we can say afterwards: it was worth it. Not every
change translates directly into customer benefits that
justify a surcharge for the software, for example in the form
of a software feature. The automation of time-consuming
manual tasks, on the other hand, can free up capacities in
development for innovations. Automated regression and
load tests relieve technical support. The reduction of
technical debt keeps the development environment future-
proof so that it can react quickly to innovations on the
market. These soft factors need to be translated, as well as
possible, into hard metrics with an eye to costs and benefits
that can be used to prioritize.

4. What are the RISKS involved in

the requested change?
While we focus on the optimistic side of returns with a best-
case scenario at the end of the scale, we take a pessimistic
view of risks with a worst-case scenario. Every change
involves risks. Some can be avoided, others may have to be
accepted if the opportunities on the one hand or the
disadvantages of not implementing the change on the
other hand outweigh the risks. But it is to be expected that
changes in one part of the system will have an impact on
other areas. The consequences should therefore be worked
through in advance.

5. What RESOURCES are required

to deliver the change?
At the macro level, this is always about time and money. At
the micro level of IT change management, it is about
people (skills) and machines (capabilities). These do not
exist – or are missing – in a vacuum. If the forces are tied up
in one project, they are missing in another. Do we tackle
both anyway? At the same time? What delays occur
elsewhere when we implement a change? The question
does not stop with the internal IT organization, but
encompasses the entire customer value chain all the way to
the customer. Answers to these questions must also be
incorporated into the prioritization of IT projects.
6. Who is RESPONSIBLE for the
"build, test, and implement" part
of the change?
Who is going to do it? Who builds, tests and implements the
change? In most cases, there are different people in the
team or even different departments for the individual sub-
steps. Therefore, it is all the more important to make
responsibilities transparent and comprehensible on the
one hand, and thus implementable and enforceable on the
other. It is then unmistakably clear who must take action
for which task and, in the event of failure, unproductive
recriminations can be avoided. Throughout change and
release management, responsibility must be clearly
distributed and transparent to all.

7. What is the RELATIONSHIP

between the suggested change
and other changes?
IT environments are complex and have many dependencies
across other areas and functions in the system. Sometimes
it is enough to point out effects in other areas, in other
cases you have to rely on their preliminary work. An
integrated configuration management database (CMDB)
makes mutual dependencies transparent and enables joint
time and sequence planning for implementing changes
with the least possible downtime and time delays.

Standardized ITSM processes

via the integrated service
management tool
In order to optimally implement IT change management in
the company, changes must always be made according to
defined points. First, the current state must be analyzed
and the target state defined. Then a schedule is drawn up
for the change. A test model helps to prevent problems - for
example with service quality. If the test model runs, the
change is implemented as planned. This works more easily
if the ITSM processes are supported and standardized with
service management software. This should meet the
following requirements:

better process control over:

a tool-based forward schedule of change (FSC),
a cross-organizational calendar planning,
comprehensive resource management, as well as
management and control of all change
management roles and responsibilities
Authorizations for all process activities exclusively via
integration with the company-wide LDAP system
Transparency about dependencies and possible
effects in the IT infrastructure
Transparency across all change and release
management activities from initial request to post-
implementation review
Processing and documentation of all change
management and release management activities in
the change management tool; completely based on
the asset & configuration management database
(CMDB) inventory
Simple, traceable communication on the process
steps in all change management phases – at best
automatically mapped within the tool
Comprehensive, transparent risk management as a
prerequisite for successful work in the change
advisory board (CAB) – especially in the evaluation of
emergency changes in the eCAB
Low-effort measurement and reporting of all relevant
key performance indicators (KPIs)
Simplification of the ITIL change management
workflow

ITSM software is a powerful tool that can greatly enhance

change management processes. However, it's important to
remember that success is not solely dependent on the
tools and policies in place. Ultimately, it is the people
within the company who drive its success. After all, it is the
dedication and hard work of employees that create value
for customers. Their expertise and commitment are
essential in ensuring a smooth and efficient change
management process.

Organizational change
management (OCM)
After successful implementation, the entire process is
evaluated. What should be optimized next time? Were all
set goals achieved? Was the schedule adhered to? It is best
to use a dedicated change manager for this review, who
monitors and constantly optimizes the entire IT service
management project.

Focus on people
Despite all the technical support, the people behind it must
not be forgotten. Tried and tested, sometimes beloved
processes and routines have been established for years.
Changes can therefore quickly lead to discontent,
demotivation and political intervention at management
level.

ITIL 4, which is based on the principle of "simple and

practicable", provides a remedy. While the 26 life cycle
processes from ITIL 3 formulate relatively rigid, rule-based
procedures, the 34 management practices from ITIL 4 grant
freedom for defining customized processes.

The differences between ITIL

v3 and v4 in IT Change
Management
ITIL v3 ITIL v4

Describes change Describes change

management as a process in management as a service
service transition. management practice and
calls it change enablement.
 ITIL v4 lists the basic
activities in change
enablement as well as the
key inputs, outputs and
roles.

(IT) organizations can use

these guidelines to design a
customized process for
managing changes that
reflect their individual
requirements.
Process steps: Change enablement
practice:
Change management
support The change management
Evaluation of change process according to ITIL v3
proposals does not become obsolete
RfC capture and review and can be used as a
Assessment and template for individual
implementation of adaptation in the IT
emergency changes organization.
Change assessment by
the change manager Main activities:
Change assessment by
the change advisory Record
board (CAB) Plan
Change planning and Approve
release of the build Execute
phase Review
Release of the change
deployment phase
Implementation of
minor changes
Post implementation
review and change
completion

Focus on service transition Focus on the service value

and deployment chain including the design
and development phase

Change enablement should

be designed to keep the
end-to-end service
 management value chain in
mind.

An iterative approach is
designed to balance rapid
implementation of an RfC on
the one hand with managing
the associated risks to
existing services on the
other.

Best practices and pitfalls of

IT change management
Let's take a deep dive into the process by illustrating it with
a real-life example.

Christian Klaus has a problem. After a serious failure in his

company's IT system, he is called upon to revise the change
management process. He clearly focuses on risk
management, one of the seven requirements in ITIL Change
Management.

The trigger for Christian's headache was a small change to

the hardware in a regional branch. The glitch had spread
area-wide and ended up severely impacting the entire
organization's communications and video systems.
Employees in the home office were cut off. Meetings
between management and customers as well as suppliers
could not take place. IT worked for three hours until
essential business processes were up and running again.

As an ITIL expert and process owner for IT change

management, Christian was now aware of all the factors
that had led to the outage.
The root cause analysis had been performed, but there was
no post implementation review. The change in the field
office had not been approved by the change process, nor
had it been made by a qualified and authorized person.

Risk management
The change management process provided concrete steps
for risk management to prevent precisely such failures. In
addition, two years ago Christian and the IT change
manager had already drafted a policy that defined the best
practices of change management according to ITIL and
mapped them for the company's own IT organization.
Regular training sessions were held for the teams, in which
the content was repeated and discussed. All of the
specifications from the risk management section of the
change management policy had simply been ignored - they
had simply not been taken into account.

Success factors in IT change

management
Change can only succeed if it is clear what you are doing it
for and everyone involved has confidence that the effort can
succeed. Creating this transparency and confidence was
Christian's biggest challenge.

Christian did not have to do much convincing to prevent

future failures like the recent one in the communications
systems. No one wants errors and inconsistencies in the
process workflow, disrupted processes, failures and
escalations. Everyone who wanted a cleanly functioning,
high-performance IT infrastructure could agree on simply
regulated, comprehensible and well-documented
processes with clear responsibilities and controlled risk
management.

Christian summarizes his plan:

He would make a strong case for his list of requirements for

the future ITSM tool in the purchasing process. In doing so,
he would once again emphasize the importance of an
integrated Asset & Configuration Management Database
and underline the connections with the recent incident.

At the same time, he would push to add to the Request for

Information (RfI) those aspects that did not solely serve
process-related, system-related functionalities. Tool
functions that enable transparency and automation and
thus make routine work superfluous should be given more
weight. More attention should also be paid to ease of use
across different devices and channels.

Only then, he was sure, would colleagues quickly embrace

the changes. Only then could the changes be quickly
activated in the IT change management process. And only
under this condition can systems be optimized, processes
improved and major failures reliably prevented in the
future. Business goals are thus better achieved and
digitalization in the company is driven forward.

Written by André Jung

During more than 30 years in the IT industry,

André Jung has gained a wide range of
experience in working with people – in
management positions, in sales and in
professional services. He was responsible for
customer service management for Orange
Business Services in Germany, Austria and
Eastern Europe for over two decades. Today,
he enjoys sharing his expertise, thoughts and
viewpoints on the subject of IT service
management and ITSM tools in specialist
articles and videos – when he's not on the
road as a motorcycle safety trainer or
orchestral musician.

Related posts

Using a CMDB to succeed: Here's what companies should keep in

mind
Read More

ITSM ordering processes: 4 steps to save you time and money

Read More

What makes a good ITSM tool?

Read More

Subscribe to our newsletter and

we'll keep you up to date!
I am interested in the following
topics:
Multiple selection possible:*
IT Service Management
 IT Financial Management

Corporate Performance Management

Knowledge Management

IT Infrastructure Solutions (Data Management, Security

Management, Endpoint Management)

First name Last name*

Business e-mail*

Company*

Serviceware requires your contact information, which you provide to us in order to contact you, as
you request, about our products and services, both personally and through marketing e-mails
related to your interests. You may unsubscribe from these communications at any time. For
information on how to unsubscribe, as well as our privacy practices and commitment to
protecting your privacy, please review our Privacy Policy.

Subscribe

Serviceware SE Serviceware SE UK Limited

Serviceware-Kreisel 1 Building B, Watchmoor Park -
About
65510 Idstein Riverside Way
Serviceware
Germany Camberley, Surrey GU15 3YL
England Newsletter
+49 6434 9450 0
Investor
contact@serviceware-se.com +44 1276 402345
Relations
contact@serviceware-se.com
Partners
Locations
Careers at
Serviceware
Contact
 | Terms of Service | Imprint |
Privacy Settings Privacy |
© 2023 Serviceware
Code of Conduct | Modern Slavery Statement | Sitemap