ITIL Change Management

Change is "the addition, modification or removal of anything that could have an

eefect on IT Services. The scope should include all IT Services, Configuration
Items, Processes, Documentation, etc."
Change Management is "the process responsible for controlling the Lifecycle of
all Changes. The primary objective of Change Management is to enable
beneficial Changes to be made, with minimum disruption to the IT Services".

Overview

A service might need to be changed for various reasons:

o
Customers, internal or external, might want to:

Reduce costs

Increase the efficiency of existing systems

Reduce errors

Adapt to changed work circumstances

Each of the above requires some Changes in the IT system

Manage these Changes in a well-defined, planned

manner to:

Reduce Risk Exposure

Minimize the severity of any Impact

Correctly implement the Change at the first

attempt

2.1. Purpose, goals and objective

Purpose
o
Make sure that standardized methods and procedures are used to
efficiently and promptly handle all Changes.
o
Make sure that all Changes to Services Assets and CIs are
recorded in the Change Management System (CMS)
o
Make sure that overall business Risk is optimized
Goals
o
Respond to the customer's changing business requirements while
maximizing value and reducing Incidents, disruption and rework
o
Respond to the Requests for Change (RFCs) of the business and IT
that will align Services with business needs
Objectives
o
Make sure that Changes are recorded and then evaluated,
authorized, prioritized, planned coordinated, documented and
reviewed in a controlled manner

2.2. Scope
A Service Change:

Is a Change to an existing Service or the introduction of a new Service

Is the addition, modification or removal of an authorized, planned or

supported Service or Service component and its associated documentation

Organizations must define the Changes that are within the scope of their
Service Change process. Those outside the scope might include Changes such
as at the department, organization, policy and business levels and routine
operational Changes, for example, repairs to printers or other routine Service
components.
Types of Changes
Predefined Change scope usually includes the following three types of Changes

Strategic Changes: Cover long-term planning and control over the

quality, stability and flexibility of the Service. The Service Strategy team
usually brings in these Changes.

Tactical Changes: Guarantee and maintain the quality stability and

flexibility of the Service. They manage Service levels ,costs, availability,
capacity and contingency planning.

Operational Changes: Achieve the quality, stability and flexibility of

Services. They help manage the Incidents, Problems, Changes, software
Releases and the configuration of the hardware and software elements of
the infrastructure.

2.3. Business Value of the Process

Change Management adds immense value to the business because it positions
the organization to:

Prioritize business and customer Change proposals

Respond to business and customer Change proposals

Implement Changes that meet Service requirements

Optimize costs when implementing Changes

Meet governance, legal contractual and regulatory requirements

Reduce the number of failed Changes and, consequently, reduce

instances of Service disruption, defects and rework

Deliver Change promptly to meet business timelines

Track Changes to learn from past errors/Incidents

Contribute to get better estimations of quality, time and cost of Change

Assess the Risks associated with the transition of Services (introduction

or disposal)

Aid in the productivity of staff by minimizing the disruptions caused by

high levels of unplanned or emergency Changes, maximizing Service
availability

Reduce the Mean Time to Restore Service (MTRS) through quicker and
more successful implementations of corrective Changes

Liaise with the business change process to identify opportunities for

business improvement
Success and Business Continuity
All organizations rely heavily on IT Services and IT infrastructure. An
organization may need to spend a lot of time on assessing the Impact of an IT
Change on the business, managing the Incidents caused by Changes,
identifying recurring Problems, and so on. As a result, ensuring that Service
disruptions and Incidents are minimal can result in considerable cost savings
for an organization.

Each organization counts on having reliable IT Services to perform its day-today functions. In fact, reliability and business continuity are two cornerstones
of the success and survival of any organization. Services and infrastructure
Changes can have an adverse Impact on the business by causing Service
disruptions.

2.4. Policies, Principles and Basic Concepts

Policy: A written statement of a plan of action adopted by an organization to
guide its decision-making processes.
Policies that support Change Management are:

Creating a culture of Change Management across the organization, to

have zero tolerance for unauthorized Changes

Ensuring that the Service Change Management process aligns with the
business, project and stakeholder Change Management processes

Ensuring the prioritization of Change, for example, innovation vs

preventive vs detective vs corrective Change

Defining accountability and responsibility for Changes through the

Service Lifecycle

Ensuring appropriate separation of duty controls

Maintaining a single focal point for Changes to minimize the probability

of conflicting Changes and potential disruption to the production
environment

Preventing unauthorized users from having access to the production

environment

Making sure that Change Management integrates with other Service

Management processes to establish traceability of Change, detect
unauthorized Change, and identify Change-related Incidents

Defining enforcement and authorizations for exceptions

Defining the performance and risk evaluation of all Changes that impact
Service capability

Defining performance measures for the process, for example, efficiency

and effectiveness
Principles of the Change Management Process
1 Filtering RFCs
2 Assessing the Impact of Changes
3 Authorizing Changes
4 Reviewing Changes
5 Closing RFCs
Design and Requirement Considerations of Change Management

Planning in conjunction with Release and Configuration Management to

help evaluate the Impact of the Change on the current and planned
Services and Releases

Defining requirements, for example, to comply with relevant legislation,

industry codes of practice, standards and organizational practices

Having an approach to eliminate unauthorized Change

Identifying and classifying

o
Change document identifiers

Change document types, templates and expected content

Change Impact, Urgency and priority
Organization, roles and responsibilities, including
o
Conducting independent testing and evaluation of Change
o
Defining Change authorization details, such as the levels of
authorization and rules that govern decision making and actions
o
Defining the structure of advisory boards, for example, the CAB
and Emergency CAB (ECAB)
Stakeholders
o
Planning Changes and Releases to enable stakeholders to plan
their activities
o
Informing all stakeholders of Changes, Change schedules and
Release plans
o
Grouping and relating Changes into one build or baseline Release
by linking several child RFCs to a master RFC
Procedures to follow
o
Defining Change authorization policies, rules and procedures
o
Defining procedures for raising an RFC, including preparing and
submitting a Change proposal
o
Defining the process to track and manage Change Requests
o
Defining the process to ensure that Change Requests are promptly
impact-assessed and evaluated
o
Defining the process to detect dependencies and incompatibilities
between Changes
o
Defining the process to verify the implementation of a Change
o
Defining the process to oversee and evaluate deliverables from
Change and Release implementation
o
Defining the process to review Changes regularly to identify trends
and improvements
o
Managing interfaces with other Service Management processes
o
Defining the approach to interface Change, Release and
configuration Management with the Problem and Incident
Management processes, to measure and reduce Change-related
Incidents
Configuration Management interfaces
o
To provide quality information for Impact assessment and
reporting
o
To identify high-risk, high-impact Cis
o
To capture Cis, Configuration Baselines and Releases
o
To capture related deliverables
o
o

Basic Principles
A Change Request is a formal communication seeking an alteration to alter one
or more CIs.
Types of Change Requests

Standard Change (preauthorized)

Is a Change of a Service or infrastructure that is preauthorized by

Change Management and has an accepted and established procedure
to provide a specific Change requirement
Normal Change
o
Is raised by a request from the initiator (the individual or
organizational group) that requires the Change
Emergency Change
o
Is sometimes required and should be designed carefully and
tested before use, if at all possible, or the impact of the emergency
Change may be greater than that of the original Incident. Details are
often captured at a later date. The ECAB reviews these Changes.
o

It is crucial to define the approach to manage Standard Changes and define all
related Change processes and workflows. These should become part of the
Change Process Model.
No Change should be approved without explicitly addressing the steps to take if
the Change fails. This includes back-out plans for reversible Changes and
alternative remediation approaches for irreversible Changes.
Change Process Models
Change Process Models are a way of predefining the steps that should be taken
to handle a process in an agreed way

Defined workflows

Chronological sequence of:

o
Steps
o
Roles and responsibilities
o
Timelines
o
Escalation procedures
Any organization will find it useful to have a well-defined Change Process Model
that can be applied to appropriate Changes when they occur. It is good practice
to associate a Change Process Model with each Standard Change. This ensures
that each Standard Change is handled consistently.
Characteristics of a Change Process Model

Built prior to implementation

Intended as a tool to manage Risk

Owned and managed by Change Management

Most often applied to Standard Changes

Facilitates Capacity Model building, which allows extraordinary Changes

in terms of complexity, scale or both

Has defined steps that seek help from other Service Management
processes to evaluate the Impact of Change
Scope of a Change Process Model
Change Process Models are designed with tasks specific to the level of control
desired by the organization. They are predefined by Change Management and
agreed with the organization. The model may be specific to type, for example,
network or PC; to severity of Impact, or to whatever is specific to the
organization.

It includes:

Steps to be taken to handle the Change

The chronological order of the steps

Responsibilities regarding who should do what

Escalation procedures
Standard Change
Is a low-impact Change implemented in the usual way. This includes fully
defined and preapproved Change Models that are individually recorded but not
individually assessed by Change Management. Examples include low-impact,
routine application Changes to handle seasonal variation.
A delegated authority grants approval for each standard Change.
Elements of Standard Change
The crucial elements of a Standard Change are:

A defined trigger to initiate the RFC

Well-known, documented and proven tasks

Authorized in advance

Preordained budgetary approval

Low risk
Communicating Standard Changes
After you have decided on the approach to manage all Standard Changes, you
must develop the following and communicate them to all concerned personnel
to ensure the effective application of Standard Changes:

Standard Change processes

Associated change workflows

Another helpful task is to identify all Standard Changes early on, when building
change Management. This promotes efficiency and avoids high levels of
supervision and resistance to Change Management.
Finally, all Changes, including Standard Changes, must have details of the
Change recorded.

2.5. Main activities, methods, techniques and

relationship with Release, Control and Validation (RCV)
The Change Management activities to manage Services Changes effectively
are:

Plan and control changes

Make Change and Release schedules

Communicate Change-related information

This topic will cover approaches to manage Service Changes effectively

Make decisions regarding Changes, Authorize Changes

Outline remediation plans for Changes

Measure and control Changes

Manage reporting

Comprehend the Change impacts

Ensure consistent process improvement

2.5.1 Overall Process, including normal and standard Change Requests

Normal Change Request activities

o
Create and record an RFC
o
Review the RFC
o
Assess and evaluate the Change
o
Authorize the Change
o
Plan updates
o
Coordinate the Change implementation (includes the Change build
and test activities)
o
Review and close the Change
2.5.2 Logging, reviewing and assessing Change Requests
An individual or organizational group can raise Change Requests. Regardless of
the initiator of the change Request, you need to log, review and assess all
Change Requests as part of Change Management.
Ways to submit RFCs

On paper, using a form called a Change form or Change proposal

Through e-mail

Via a Web-based interface

IT Service Management Tool

Important: Maintain and update all information related to RFCs in the CMS.
The Change form or change proposal has a full description of the change and
the reason for the Change. In the Change form or proposal, you need to record
all information related to the RFC, such as the priority of the request. As the
process progresses, information will be added, including the authorities
involved in authorizing, assessing and evaluating the Change. Work orders to
get the Change implemented will also be added. You should maintain and
update all information related to RFCs in the CMS.
Logging a Change Request
An organization must have set procedures to log and document RFCs. Logging
a Change Request is the first activity performed after receiving a Change
Request.
Procedure to log a Change Request:
1 Submit a Change Request in a document or through e-mail or any webbased application
2 Log RFCs
3 Allocate a unique identification number to each RFC to ensure RFC
tracking. Ideally, you should use an integrated Service Management tool
to log the RFCs. This type of tool also helps store the complete data as
well as the relationships between all assets and Cis, enabling you to easily
assess the Impact on other Services.
4 Review and filter out any unwanted Requests that are not feasible for
implementation, are incomplete or have been accepted or rejected earlier.

5
6

The
1
2
3
4
5
6
7

Return the rejected Requests to the initiator along with reasons for the
rejection. The initiator can request for the Change again through the
correct management channels.
Assess change Requests to identify their Impact on other Services, Cis,
business operations, current Change schedules, resource requirements,
continuity plans, security plans and Service Operation practices.
Seven Rs of Change Management
Who Raised the Change?
What is the Reason for the Change?
What is the Return required from the Change?
What are the Risks involved in the Change?
What Resources are required to deliver the Change?
Who is Responsible for the build, test and implementation of the Change?
What is the Relationship between this Change and other Changes?

Assessing the Impact of Changes

It is very important to assess the potential Impact of failed changes on the
Service, Service Assets and configurations. The 7 Rs of change Management
are used to measure the Impact and evaluation of Changes. For all Changes,
you must answer the questions.
Without this information, Impact Assessment cannot be completed and the
balance of Risk and benefit to the live service will not be understood.
In many organizations, specific Impact assessment forms are used to answer
the 7 Rs. It is also useful to discuss all major changes with stakeholders, to
decide upon responsibilities and improve communication regarding the Impact
of Changes.
Considerations for Impact and Resource Assessment
Must Consider:

Impact on the customer's business operation

Effect on the customer's infrastructure and Service delivered to the

customer, as defined in the Service Model

Impact on other Services that run on the same infrastructure

Impact on items that are not part of the infrastructure of the

organization

Effect of not implementing the Change

Resources needed to implement the Change

Current Change schedule and Projected Service Outage (PSO)

Additional resources
o
Impact on

Continuity plan

Capacity plan

Security plan

Regression test scripts

Data and test environment

Service Operations

Changes and Associated Risks

No change is without Risk! Even the simplest Change can cause damages that
seem completely out of proportion to the complexity or simplicity of the
Change itself.
Risk Assessment
Depending on the Impact and risk assessments and the impending benefits of
the Change, each Change assessor must decide whether he/she approves or
disapproves of the Change. All members of the Change authority must evaluate
the Change based on:

Impact

Urgency

Risk

Benefits

Costs
Risk Categorization
The organization should also assess and categorize the associated Risks to
prevent disruptions to the business or to the delivery of Services. Many
organizations use a simple matrix to categorize Risks.
2.5.3 Authorizing Changes
Before implementing a Change:

Obtain authorization from the defined authorities in your organization.

Make sure that the organization has defined the Change authorization
hierarchy.
Different types of Change will have different authorization levels. In addition,
each authorization level might include a delegated authority based on some
predefined parameters of assessment, such as the type, size, cost or Risk of
the Change.
The culture of the organization will also dictate the levels of Change
authorization.
2.5.4 Coordinating, reviewing and closing Changes
Coordinating Change Requests
Change Management is responsible for ensuring that Changes are
implemented as scheduled. This is largely a coordination role. After change
authorization, you need to coordinate the Change implementation.
Coordinating Change Requests includes tracking and coordinating them. It is
good practice to track the building of Changes in a formal way, for example,
through work orders. Change Management coordinates the Change
implementation while technical specialists build, test and implement the
Change.
Change Management has a supervisory role to ensure that all Changes that can
be tested are thoroughly tested. While testing the Change before

implementation is mandatory, further testing can be done after the

implementation to test for unusual or unforeseeable situations.
Reviewing and closing Change records
To do so, you need to:

Collate the Change documentation, for example, baselines and

evaluation reports.

Review the Change(s) and Change documentation.

Close the Change document.

After implementing the Change, you must record all the relevant information
and send the report to the management team for review and evaluation. When
reviewing the Change, you must also look at any Incidents that might arise
because of the Change, and ensure that all related Incident, Problem or Known
Error records are also closed on successful completion of the Change.
Post-Implementation Review
The next step is to conduct a PIR. A PIR is a formal review of a program or
project.
It is used to answer the question "Did we achieve what we set out to do in
business terms, and if not, what should be done?".
For a major Change program, there may be several PIRs over time. This is only
after a predefined period to analyze whether or not the Change has met its
proposed objectives. Because the organization conducts the PIR on a large
scale, it involves the CAB members.
A normal review takes place after implementing a Change. You usually conduct
this review on a smaller scale than the PIR. In a small organization, you need
not conduct a large-scale PIR and, instead, implement a spot review to verify
the Change. In a big organization, spot reviews are also helpful to monitor
many small Changes.
Facts Established by a PIR

The Change has met its objectives

Users and customers are happy with the Change

The Change does not have an unexpected or undesirable effect on other

Services

Resource utilization was per the estimated resource requirement

The Release and Deployment of the Change was as scheduled

The implementation of the Change was per schedule

The remediation plan was functioning correctly, when needed

The CAB
The CAB is a body that supports the Change Management team by approving
requested Changes and assisting in the assessment and prioritization of
Changes.

Because the CAB is expected to consider and recommend whether to adopt or

reject Changes, it is usually made up of people who have a clear understanding
of the entire range of stakeholder needs.
In fact, CAB members should be chosen carefully to ensure that the requested
Changes are thoroughly checked and assessed from both a technical and a
business perspective. The considered Change will necessitate the required
personnel to convene in a CAB meeting. The Change Manager will chair CAB
meetings.
Any RFC should be circulated in advance to allow CAB members to decide
whether to attend in person, send a representative or communicate via the
Change Manager. A standard agenda may also be sued to conduct the CAB
meetings.
The CAB must also review new or changed Services after a predefined period.
Their main aim is to ensure that the Change has met its objectives and has not
affected or disrupted other Services that the resources used to implement the
Change were as planned, that the Change was implemented on time and to
cost and so on. If the Change has not met its objectives, the CAB members
raise a request for a revised RFC to be raised to initiate another Change.
However, if the Change is successful, the RFC is formally closed in the logging
system.
CAB board members need not meet face-to-face to discuss each requested
Change, but can use electronic support and communication tools as a medium.
It is, however, advised that a quarterly meeting be scheduled to review
outstanding Changes, sign-off approved Changes and discuss any future, major
Releases.
2.5.5 Emergency Changes
Building and Testing Emergency Changes
At times, your organization might require Emergency Changes. Before
implementing these Changes, you should design and test them to avoid
Impacts that are greater than those of the original Incident. You must also
document the details of the emergency Changes for future analysis.
Not all RFCs raised in an organization are of the same priority. An Emergency
Change is the highest priority Change in an organization. For any Emergency
Change, you need to evaluate, assess, reject or approve an Emergency Change
in a short period of time.
An Emergency Change is not an Urgent Change (often called urgent because of
poor planning). Emergency Changes are typically in response to a major
operational failure in the ability to deliver critical business services.
Aspects of Implementing Emergency Changes to consider

Conditions for implementing Emergency Changes

You must construct and design Emergency Changes cautiously,

and you may document details retrospectively if time does not allow
you to document them immediately. A Change is only considered an
emergency if it is essential for the organization such as the repair of
an error and only if the error is negatively impacting the business to a
great degree.
Disruptive nature of emergency Changes
o
These Changes are usually disruptive and are less likely to be
successful. As a result, you need to minimize their number.
Emergency Changes should be carefully tracked and reported on.
Authorization of Emergency Changes
o
You must follow the correct authorization channels for an
Emergency Change. In an emergency, CAB members might not be
able to hold a meeting. In this situation, ECAB members authorize the
Change. However, you might not need their approval in all situations,
such as an operational repair, for example, to a mainframe or large
server.
Implementation of Emergency Changes
o
After authorization from ECAB members, you need to send the
Change Request to the relevant technical team for building the
Change. You must also test the Change, if possible, before
implementing it. Consider comparing the cost of testing the
Emergency Change with the cost of the failure of the Emergency
Change. You might need iterative attempts to come up with an
effective fix if the first or subsequent attempts fail. After testing and
implementation, you need to document all the relevant details for
future reference.
Guidelines for implementing emergency Changes
o
You need to follow the normal Change procedure to implement
Emergency Changes as well. The only exceptions are that instead of
CAB members, ECAB members authorize the Change. You can reduce
or bypass testing, and you can defer the documentation phase based
on the decisions taken by the ECAB. Be sure to follow up after the
emergency Change is completed to make sure all bypassed
documentation is updated.
o

Elements of the Emergency Change Procedure

Need for emergency established (conforms with the Change

Management policy)

RFC completed

Change Manager notified

Change built and tested simultaneously, if possible; back-out options

identified

Change Manager assesses RFC

Change Manager convenes ECAB

ECAB reviews RFC, test results, and back-out plan

Change Manager informs the business of Impact

RFC implemented (if ECAB satisfied)

Further testing, if appropriate

Close RFC and PIR

Change Implementation failure

You may come across situations where the implemented Change fails to resolve
the reported error. In these situations, you might have to attempt to fix the
Change multiple times. The Change Management team must also ensure that
the attempts do not disrupt business Services and correct procedures are
followed to fix the Change.
However, if the Change Management team is unable to rectify the error after
multiple attempts, you should analyze the situation by answering questions
such as:

Did you identify, analyze and diagnose the error correctly?

Did you test the proposed resolution adequately?

Did you implement the solution correctly?

To test and implement the Change correctly, you can stop the Service partially,
withdraw access for some users or suspend the Service for a specific duration.
You must also document and update all actions for future reference. However,
sometimes you may not be able to do so because of the urgency. In this case,
record the essential updates and then complete the documentation after you
implement the Change successfully.

2.6 Triggers, inputs, outputs and interfaces with other

processes
Triggers
Changes that can trigger Change Management are:

Strategic Changes
o
These Changes aim to achieve specific objectives with respect to
predefined parameters, such as organization Change, sourcing model
Change and legal or regulatory Change.

Changes to Multiple Services

o
These Changes to planned Services or Services in the Service
Catalogue trigger Change Management. Examples are Changes to the
Service Catalogue, Service Package and Service definitions and
characteristics

Operational changes
o
These Changes aim to affect operations. Examples are access
requests or requests to move an IT asset across locations.

Continual Improvement Changes

o
These Changes aim to deliver continual improvement, for
example, Changes to processes
Inputs
Inputs to Change Management are:

Policies and strategies for Change and Release

RFC (this is the primary input)

Change proposals

Plans for

Change
Transition
Release
Deployment
Test
Evaluation
Remediation
Current Change schedule
Current asset or configuration Changes
Planned Configuration Baseline
Test results
Reports such as
o
Test reports
o
Evaluation reports
o
o
o
o
o
o
o

Outputs
The outputs of a Change Management are:

Rejected RFCs

Approved RFCs

Changes in Services and configurations

Change schedule

Revised PSO

Authorized Change plans

Change decisions and actions

Change documents and records

Interfaces with other Services Lifecycle Processes
Various Service Management processes might require Change Management
from time to time and may be exposed to the Impacts of various Changes.
Some of these processes are:

Asset and Configuration Management

o
The CMS provides accurate information about Cis and assets,
helping stakeholders and staff evaluate and assess the Impact of the
proposed Change. The CMS also lists the assets and Cis that the
Change will affect.

Problem Management
o
Problem Management interfaces with Change Management by
raising RFCs to implement Workarounds and to fix Known Errors.
Many RFCs originate from Problem Management. They plan an
important role in CAB meetings.

IT Service Continuity
o
You can update many procedures and plans in ITSCM through
Change Management. This is necessary to ensure accuracy and to
inform stakeholders of all the Changes.

Security Management
o
RFCs also originate from Security Management. You need to follow
Change Management to implement these Changes. Security is also a
key contributor to the CAB (to discuss security issues).

Capacity and Demand Management

Sometimes, poorly managed demand increases costs and Risks

for Service Providers. Capacity Management assesses the proposed
Changes against Service capacity. Capacity Management also
submits RFCs that you process through Change Management.
Other Interfaces
o
You might also come across situations where the proposed change
will affect the other parts of the organization on a wider scale. To
avoid this, the Service Change process must interface with the other
processes involved.
o
You should implement Change Management in synchronization
with various other interfaces within an organization because of the
Impact of the proposed Change.
o
Some of these interfaces are

Business Change processes

Program and Project Management

Internal and external sourcing and partnering entities

o

Program and Project Management must work together to align all the processes
and people involved in Service Change initiatives. The Change effort also
improves based on how closely you align the processes. The Change
Management team is allowed to attend project-related meetings.
The partnership agreement between the entities involved in the Change
process should clearly define the roles and responsibilities of each entity and
how much influence each of them can have on the Change process. You must
also check how well you align the Change processes and the tools in the
organization. If the supplier is responsible for the operational Services, conflicts
may arise.
The different entities involved in the Change process may include internal or
external vendors and suppliers that provide new or changed Services. To
manage the Change process efficiently, ensure that:

You maintain a good relationship between entities

You assess how well partners manage the Change process

Service Providers follow the same Change Management process as the

organization they work with. Some organizations also refer RFCs to the
Service Providers for approval.

2.7 Process Measurement

Key Performance Indicators
KPIs are measurable metrics used to help an organization define and measure
progress toward organizational goals. All Change Management KPIs must have
a specific meaning. This is because, while you can easily count the number of
Incidents that generate Changes, it is more valuable to be able to identify
trends and measure their Impact by looking at their underlying cause. Over
time, you will also be able to measure the speed and effectiveness of your
response to business needs for Change.

In Change Management, KPIs help analyze patterns and reasons for requested
Changes. When implemented correctly, KPIs and metrics help you measure the
Impact of Changes on the organization.
Let us now understand how the KPIs implemented in your organization help you
analyze Change Requests to spot trends.
Change Management KPIs
The KPIs applicable for Change Management are:

Number of implemented Changes to Services that meet customer

requirements

Benefits of a Change comparing favorably to the costs of the Change

Fewer disruptions to Services, fewer defects and less rework

Fewer unauthorized Changes

Smaller backlog of Change Requests

Fewer unplanned Changes and emergency fixes

Improved change success rate

Fewer Changes where remediation is invoked

Fewer failed Changes

Less time to implement each Change per Urgency/Priority/Change type

Percentage accuracy in Change estimate

Fewer Incidents related to Changes

For these KPIs to provide the expected results, you need to gather and analyze
the required information from your organization. Just reporting the number of
Changes might not be helpful; reporting their cause and comparing all current
and previous Changes will be useful to plan future Changes.
Remember that all measures vary between organizations and over time, as the
Change process matures.

2.8 Roles and Responsibilities of the Process

Change Authority
o
May be a role, person or group of people that provides formal
authorization for each Change
Change Manager
o
Receives, logs and allocates a priority level to all RFCs and rejects
the impractical ones
o
Prepares all RFCs for a CAB meeting, issues the agenda and
circulates all RFCs to CAB members before meetings to allow priori
consideration
o
Determines the participants of meetings, who receive specific
RFCs based on the nature of the RFCs, the required Changes and
their areas of expertise
o
Convenes urgent CAB or ECAB meetings for all urgent RFCs
o
Chairs all CAB and ECAB meetings
o
Authorizes acceptable Changes after considering the advice of the
CAB or ECAB

Issues Change schedules via the Service Desk

Liaises with all necessary parties to coordinate Change building,
testing and implementation
o
Updates the Change log with all progress records, including
opportunities to improve service quality
o
Reviews all implemented Changes to ensure that they have met
their objectives
o
Reviews all outstanding RFCs waiting for consideration or action
o
Analyzes Change records to determine any trends or apparent
problems that occur and seeks rectification by relevant parties
o
Closes RFCs
o
Produces regular and accurate management reports
CAB
o
Supports the authorization of Changes and assists Change
Management in the assessment and prioritization of Changes.
Potential members include:

Customer(s)

User manager(s)

User group representative(s)

Application developers/maintainers

Specialists/technical consultants

Services and operations staff, for example, Service Desk,

test management, ITSCM, security and capacity

Facilities/office services staff (where Changes might affect

moves/accommodations and vice versa)

Contractors or third-party representatives, for example, in

outsourcing situations

Other parties, as applicable to specific circumstances, for

example, marketing if public products are affected
o
It is important to emphasize that the CAB

Will be composed according to the Changes being

considered

May vary considerably in make-up even across the range of

a single meeting

Should involve suppliers when that is useful

Should reflect both the user and customer views

Is likely to include the Problem Manager, Service Level

Manager and customer relations staff for at least part of the time

Should have stated and agreed evaluation criteria as a

standard template to evaluate Changes
o
o

2.9 Service Operation activities in the Process

Change Management in Service Operations
Although Change Management is part of the Service Transition phase, in some
instances, Changes involve the day-to-day involvement of Service Operation.
For example, Service Operation staff:

Submit RFCs to address Service Operation issues

Participate in CAB or ECAB meetings to ensure that Service Operation

Risks, issues and views are taken into account
Implement Changes, as directed by Change Management, where they
involve Service Operation components or Services
Back out Changes, as directed by Change Management, where they
involve Service Operation components or Services
Help define and maintain Change Models relating to service Operation
components or Services
Receive change schedules, and ensure that the entire service Operation
team is aware of and prepared for all relevant changes
Use Change Management for standard, operational Changes
Involve Service Operation staff as early as possible in the process
Use communication channels between the service Desk and IT
organization effectively

To ensure that you consider all operational issues while processing an RFC,
involve the Service Operation staff in the process, right from the initial stages
(not just at the CAB or ECAB). You must also make sure that the staff is
involved in the actual Change implementation if it is in the Operations area.
This will ensure that the various scheduled tasks do not raise any conflicts.

2.10 Relationship between CSI and Organizational

Change
John Kotter's 8-steps Change Model (increasing top-down)
1 Create urgency
2 Form a powerful coalition
3 Create a vision for Change
4 Communicate the vision
5 Remove all obstacles
6 Create short-term wins
7 Consolidate gains and produce more Change
8 Anchor the Changes in the corporate culture
Implementing a Change program is difficult. This is because it involves many
people who generally do not accept a change in their way of working. As a
result, it is important to explain the benefits of implementing Change to
everyone and gain their support.