Change Management

Description/Summary
Change Management deals with any kind of change to the IT infrastructure and services. A well-
defined and controlled process leads to the effective handling of these changes. Change
Management is triggered every time a request for change is received from one of the various of
sources which make such requests. Each requested change is classified by determining its
priority and impact, and afterwards the responsible change authority decides on the approval or
dismissal of the change. Change Management coordinates the incidental tasks in the context of
change building, testing and release. For this purpose, close collaboration between Change
Management and Project, as well as Release Management is critical for the success of this
process.

Objectives
The purpose of Change Management is to establish standardized procedures for the
handling of IT-related change requests and facilitates the assessment, scheduling,
coordination, documentation and evaluation of all changes.

Change Management contributes to an integrated Service Management approach by achieving

the following goals:

 Every change and all required data is recorded.

 Every change runs through a set of standardized activities and procedures in order to
ensure effective and efficient processing.
 Every change with a risk to normal service operation is carefully assessed and
sufficiently tested to avoid service disruption or degradation of service quality, in
particular in terms of SLA deviations.
 Every implemented change is documented and reviewed.

Roles & Functions

Change Management specific roles

Static Process Roles

See Change Management section, Service Management Roles x Person for details

Change Process Owner

Initiator of the process, accountable for defining the process strategic goals and allocating all
required process resources. See{Continual Process Improvement Management Process
Description en} Continual Process Improvement Management for a detailed description of these
activities

Change Process Manager (Change Manager)

Manager of the entire process, responsible for its effectiveness and efficiency. Team leader of the
function „Change Management Team“.

Change Management Team

Team associated to the Change Management Process.

Emergency Change Advisory Board (ECAB)

Decision Maker in the case of an emergency change. It is recruited from the Senior Management.

Senior Management

Senior Management of the IT provider

Dynamic Process Roles

These roles are dynamically created during the Change Management Process. See the process-
specific or activity-specific rules for details.

Change Owner

The attribute in the records contains the value of the Role/Function currently accountable for the
change (but NOT for the Change Management Process). The Change Owner can be changed
with the help of a Hierarchical Escalation.

Change Agent

The attribute in the records contains the value of the Role/Function currently responsible for
either an activity or task within the overall activity of the change. The Change Agent can be
changed with the help of a Functional Escalation , if permitted by the Rules.

Change Advisory Board (CAB)

Consulting body in category 2 and 3 changes. The members of the CAB are defined in the
activity „classification“ and recruited from:

 Service Owner
 Change Process Manager
 Service Expert or Service Specialist
 Customer
  Other persons necessary

Change Authority (CA)

The authority (person or group) authorizing a change; Change Authorities vary
depending on the change category. See the Activity Specific Rules in the activity Change
Classification for details.
Change Requester (CR)
This is the person who triggers a change via a Request for Change (RFC) form. This can
be identical with a service or customer specific role.

Service Specific Roles

Roles depending on the affected service are found in the Service Description. The Service
Description, including the service specific roles, is delivered from the Service Portfolio
Management.

Example: Service Description

Service Expert/Service Specialist

They can consult and/or act as

 Change Builder
 Change & Fallback Tester
 Change Implementer

Service Owner

Customer Specific Roles

Roles depending on the affected customer(s) are found in the Service Level Agreement (SLA).
The Service Level Agreement for the customer specific roles is maintained by the Service Level
Agreement Management.

Example: Service Level Agreement

Customer(s)
Customers of the affected Service with a valid SLA

Information artifacts

This section describes information/data required or recorded by the process. In general, a Process
Record (here: the Change Record) represents the current progress of a process and will contain
all information related to the execution of that process. Additional information items (artifacts),
such as the Request for Change (RFC) or the Forward Schedule of Change (FSC) in the context
of Change Management, typically can be realized by considering the information out of one or
more (up to all) process records and by either filtering, merging, correlating or interpreting these
information (sometimes with regard to the context of other data and information sources).

Change Record

The Change Record is the record holding any management-relevant information and history of a
specific change. On creation, it is based on (filled with) the information provided by the Request
for Change (RFC).

Unique identifier
Change ID
Change requester
Name of the Person triggering the change
Process instance
Unique Identifier of the Process Instance triggering the Change Management Process.
This can be a Change Instance also.
Status
Status of the change. Is set when passing a Control Activity
Services
Service(s) affected by this change
Customer
Customer(s) affected by this change
Change Sponsor
Change Description
The description of the change including the Change Argument
Change Category
Change Priority
 
Change Authority
 
Risk & Impact analysis
 
Feasibility Study
 
Change Builder
Date and implementation time of the change
Implementation plan
Project Plan including concrete working instructions and time schedule
Implementation plan test results
True or False
Fallback plan
Fallback Plan including concrete working instructions and trigger for fallback
Fallback Test
True or False
Functional Test Plan
Functional Test Plan including concrete working instructions and expected results
Functional test plan results
True or False
Post Implementation Review results
True or False
Documentation Test
Test method and frequency for documentation test
Additional Remarks
Text for additional information

Forward Schedule of Changes (FSC)

The FSC is a structured report referring to all open changes. It contains user- and customer-
relevant information on these changes and thus realizes a constricted view on all records of
planned changes. Information to include in the FSC are:

 Unique identifier of the change

 Date and implementation time of the change
 Description of the change
 Expected impact on IT service operation (What will be impacted, and how, if change
implementation proceeds successfully?)
 Potential impact (What might be impacted, and how, if change implementation fails?)

Accomplished Change Overview

The Accomplished Change Overview is a structured report referring to all closed or cancelled
changes. It is an important Information Resource for the Incident Management process and
should include is:

 Unique identifier of the change

 Date and implementation time of the change
 Description of the change

Key Concepts
Change Category & Standard Change

The following table outlines different category classes for changes.

By definition, changes from category 2 and 3 are also called „major changes“ and will be
handled in a special way during the Change Classifikation.

Standard Changes help to accelerate process execution and thus increase the efficiency of
Change Management. If a change of this category is requested, no delay is created through
waiting for the change authorization (see below). This is because for each standard change, the
required authorization has been given once in advance and will apply to all future changes of the
same kind. It is essential that procedures are in place for the definition and administration of
standard changes. This is achieved by the sub process Standard Change Admission.

In summary, a standard change is characterized as follows:

 Low risk
 Well-known costs
 Well-established procedures (e.g. working instructions) for change implementation
 Clearly defined roles:
o who sponsors the respective change
 o who is allowed to request (trigger) the standard change (e.g. which users)
o who is responsible for carrying the change into execution (e.g. the service desk)

Change Priority & Emergency Change

The following table gives an overview of priority classes and their relevance for Change
Management.

Emergency Changes are usually performed in order to avoid or resolve serious service
disruption, degradation in service quality or to eliminate a potential security risk. Therefore, it is
always related to one or more Major Incidents.

Change Controls
Process
High Level Process Flow Chart

This chart illustrates the Change Management process and its activities as well as the status
model reflected by the Change Record evolution.
 

Critical Success Factors

Critical Success Factors (CSF):

 Obey the process in every case

 Cooperation with the Configuration Management
 No personal union between Change- and Configuration Manager
 High ratio of standard/minor changes
 High ratio of changes with low/middle rated priority

Performance Indicators (KPI)

 Details from audit

o on time?
 o in budget?
 Ratio Fallback/Total number of changes
 Boost of Incidents/Problems after a change
 Causes of the changes
 Total number of non–authorized changes

These can be measured using the following measures: per service, per user, per customer, per
location, per category, etc.

Process Trigger

Event Trigger

 Any request for change

o from a user via a Support Process
 Incident Management
 Service Request Management
 Event & Alert Management
 Problem Management
o from the customer triggered by the Service Portfolio Management Process
o from the Change Management Process itself, when a „sub“ change is needed
o from a Delivery Process
 Availability Management
 Information Security Management
 IT Service Continuity Management
 IT Service Financial Management
 Capacity Management

For more information see the relevant Process Interface Description in the Process Interfaces
Overview

Time Trigger

 None (Change Management is typically event-triggered)

Process Specific Rules

 every RFC triggers the creation of a new Change Record.

 the Change Agent is responsible for documenting each activity in the Change Record
 the Change Owner has to control the Change Agent
 the Change Owner and Change Agent can only transfer their duties if the new person or
group agrees
 the subsequent Change Owner or Change Agents must then be recorded in the
appropriate attribute in the Change Record.
 the Change Owner and Change Agent should preferably be a person rather than a group.
  refer to the Service Description and Service Level Agreement in order to take service
specific and customer specific rules into account

Note: for the different types of rules see Rules.

Process Activities
Change Recording

The Request for Change (RFC) is checked for completeness and formal correctness; i.e. it is
verified that all mandatory information has been provided by the requester through the RFC
form, with respect to the desired change. If this is not the case, or if the requester is not
authorized to send RFCs in general, the RFC can be rejected. The Change Record is then shifted
into the status „recorded-accepted“, „recorded-emergency“ or „recorded-rejected“.

Activity Specific Rules

 Change Requester is set to the person who triggered the change

 Change Sponsor is set to the person who triggered the change if no other sponsor is
known
 Change Agent is set „Change Management Team“ if there is not a person as change
agent available
 Change Owner is set „Change Management Team“ if there is not a person as change
owner available
 Change Description The RFC must contain a meaningful description of the desired
change as well as a comprehensible rationale stating the reasons for the change.
 Change Priority is set to „3 (Middle)“ if no other priority is known. When requesting an
emergency change the priority has to be „1 (Emergency)“
 Process Instance which triggered the change This should refer to the respective
process instance e.g. Unique Identifier of the Incident (see also possible triggers of the
change management process )
 Affected Service At least one service must to be defined
  Change Builder At least one person out of the Service Expert or Service Specialist group
has to be set as Change Builder. This can be a group of experts/specialists if more then
one service is affected.

Change Emergency Handling

The Priority „emergency“ has to be confirmed by the Emergency Change Advisory Board
(ECAB). The testing can be skipped by the ECAB if necessary. The ECAB must allocate all
resources and has the right to postpone other changes.

Activity Specific Rules

 Change Agent is set to Emergency Change Advisory Board (ECAB)

 Change Owner is set to ECAB
 Change Change Authority is set to ECAB

 if the priority „emergency“ is Confirmed by the ECAB

o the requester and customer are informed
o the Change Builder, Change Tester and Change Implementer is defined by the
ECAB
o the Change Agent is set to Change Builder
o after planning the change the Change Agent is set to Change Tester
o after successful testing, the Change Agent is set to Change Implementer

 if the priority „emergency“ is NOT confirmed

o the Change Agent, Change Authority and Change Owner are set to their
previous values
o the Change Priority is set to a value other than „emergency“
Change Classification

The classification of a change aims at providing a control factor for the change, which will be
used for factual decision making with respect to change scheduling. In order to classify a change,
its priority and category are determined. While the change priority often depends on the urgency
and impact of related incidents and problems, reflecting the degree of importance to implement
this change, the category also will depend on the risk of the change with respect to IT service
operations, potential disruptions, or to degradations in quality. A recorded and accepted change
needs to be categorized and then processed according to its resulting category.

A standard change („Category 0“) is preauthorized. The record has to be completed according to
the standard change description.

For a minor change („Category 1“), the next activity to be undertaken is a Risk Analysis and a
Feasibility study. If assistence is needed, then the appropriated delivery processes can be
triggered. e.g Security Implementation Assistance

Following the outcome of the Risk Analysis or Feasability study, the category of a change may
need updating. However these studies may also confirm the current existing value for the change
category. If the category is not changed, the next process step will be Change Authorization; if
the catergory is changed, the Change Classification process needs to be repeated.
For major changes („Category 2 or 3“) it will be checked if there is an existing Service Design
Package (SDP). The Service Portfolio Management needs to be involved as next activity if there
is no existing SDP covering that change. The Service Design updates or creates the SDP
according to cover the change. Next activity depends on whether category will be confirmed or
updated.

Activity Specific Rules

 if the category is „standard“ the Change Owner and Change Agent is set to „Service

Desk“
 if the category is NOT „standard“
o the Change Agent is set to the Change Builder.
o the outcome of the „Risk Analysis“ and the „Feasibility Study“ has to be
documented in the Change Record
o the „Change Priority“ is defined according to the outcome. The priority
„emergency“ is no longer possible
o the „Change Category“ is defined reflecting the risk as diagnosed in the Risk
Analysis
o at the end of the activity, the Change Agent is set to the Change Owner
 if the category is „2 – Significant -“ or „3 – Critical“ – define the members of the Change
Advisory Board (CAB)
 define the Change Authority (CA)
o for category 1 it is Service Owner
o for category 2 it is Change Advisory Board (CAB)
o for category 3 it is Senior Managment

Change Authorization

In this activity, a change is approved, dismissed or cancelled. Change Authorization takes into
account the priority and category of the change, as well as the projected costs, time and resource
constraints. The decision concerning the Change Authorization must be reflected by the Change
Record. The decision between approval or dismissal of the change is met by the Change
Authority (CA) responsible for that respective change. The nature of the CA depends on the
category (risk) of the change. That is why the CA can either be the Service Owner of the affected
service, the CAB, or the Senior Management after a consultative meeting of the CAB. The
Change Record is then shifted into the status „authorized-approved“ or „authorized-dismissed“
depending on the vote of the CA.

To authorize, the following factors have to be taken into account:

 the change priority and category (Risk Analysis).

 the projected costs, budgets, time and resource constraints (Feasibility Study)

Activity Specific Rules

 if the category is „1 – Minor -“ the Change Authority (CA) is set to Service Owner
 if the category is „2 – Significant -“ the Change Authority (CA) is set to CAB
 if the category is „3 – Critical“ the Change Authority (CA) is set to Senior Management
(consulted by CAB)
 after selecting the Change Authority (CA) the Change Agent is set to Change Authority
(CA)
 at the end of the activity the Change Agent is set to Change Owner

Change Building, Testing and Implementation

Approved changes are coordinated during the building, testing and implementation tasks.
If new hardware models or software products are needed, which have not yet been released, the
Release Management process is then activated. Release Management is responsible for releasing
the Configuration Items by testing their functionality and accuracy, as well as their compatibility
and operability with other Configuration Items. Release Management should also provide a
Deployment Plan to the Change Management.

Every change has to be delivered with relevant and current documentation. In the change record,
it is stated how and when the documentation needs to be tested.

Activity Specific Rules

 a Change Builder is defined from Expert/Specialist Group

 a Change & Fallback Tester is defined from Expert/Specialist Group
 a Change Implementer is defined from Expert/Specialist Group
 the Change Builder has to be different from the Change & Fallback Tester
 the Change Implementer has to be different from the Change & Fallback Tester
 at the beginning, the change agent is set to the Change Builder
 after the task „building“, the Change Agent is set to the Change & Fallback Tester
 if the task „testing“ is successful, the Change Agent is set to the Change Implementer
 an implementation plan is recorded and made available to Release Management.
 the implementation plan is tested, and the test results are stored in the Change Record.
 a fallback plan is recorded and made available.
 the fallback plan is tested, and the test results are stored in the Change Record.
 functionality test procedures are described.
 documentation is developed and the test procedure for documentation verification is
defined

Change Documentation
In this activity, the change is documented in the CMDB using information supplied from the
change record. The CMDB is then updated via the Configuration Management process. In
particular, Configuration Management must record:

 any change of a Configuration Item (CI) attributes

 any change in the relationships between Configuration Items
 in some cases guidelines and policies need to be adjusted

After a successful verification, the change record is shifted into the status „documented“.

Activity Specific Rules

 The change agent (which is the Change Implementer at the moment) triggers the

Configuration Management Process to update CI attributes and/or relationships in the
CMDB.
 The change agent (which is the Change Implementer at the moment) triggers the
responsible Process Manager to update guidelines and policies of a process if relevant.
 It is not forbidden that Change Implementer and Configuration Librarian is the same
person
 The Change Owner has to verify the documentation, therefore the Change Agent is set
to the Change Owner
 If the verification is NOT OK, the Change Agent is set back to the Change
Implementer to improve the documentation
 Process Interface: Information about Services and Configuration Items affected by the
change are updated in the CMDB via the help of Configuration Management

Change Evaluation and Closure (PIR)

In this activity, the success of an implemented change is evaluated. Therefore, a Post
Implementation Review (PIR) is performed according to the testing procedures defined during
the change building phase of Change Coordination. A PIR is performed, and its results are
recorded. If the PIR does not attest to a successful change, a rollback must be triggered. The
change record is shifted into the status „closed-verified“ or „closed-failed“ depending on the
success of the change reflected by the post implementation review and the necessity of a
rollback.

The following evaluation questionnaire should be considered for the PIR:

 Did the change meet the desired targets?

 Was the change implemented in time?
 Did any incidents occur while the change passed through the process?
 Was the change performed without exceeding the assigned budget of money?
 Has the change been documented and the CMDB updated respectively?
 Did everyone involved in the change follow the process?
 Was any information missing, which was needed to make a decision at any stage of the
process?
 Have the stakeholders been informed about change progress in accordance to the RASCI
chart?
 Were changes (if applicable) to policies and rules monitored in the service documentation
(Test of documentation)?

Activity Specific Rules

 at the beginning the Change Agent is set to Change & Fallback Tester

 if the task „testing“ is successful, the Change Agent is set to Change Owner
  the test result has to be recorded
 if the task „testing“ is NOT successful, the Change Agent is set to Change
Implementer

Change Fallback and Documentation

In case of a failed change, reflected by a negative result of the Post Implementation Review
(PIR), the change is then revoked by putting the fallback plan into action. This rollback is
performed according to the fallback plan that is part of the change record. The Change Record is
then shifted into the status „Fallback Executed“.

Activity Specific Rules

 a Change & Fallback Tester is defined from Expert/Specialist Group

 the Change Implementer must be different from the Change & Fallback Tester
 after the execution of the fallback plan, the Change Agent is set to Change & Fallback
Tester
 the test result must be recorded.
 if the task „testing“ is successful:
o the Change Agent is set to Change Owner
o the Configuration Management Process is triggered for documentation in the
CMDB
o the requester of the change is informed about the rollback.
 if the task „testing“ is NOT successful, the Change Agent is set to Change
Implementer
Change RACI

RACI matrix stands for Responsible, Accountable, Consulted, and Informed.

 Role that is tagged as Responsible in RACI matrix, will perform the task/ tasks.
 Role that is tagged as Accountable in RACI matrix, will have the complete authority, will
make decisions and will be answerable for the success or failure of the task.
 Role that is tagged as Consulted in RACI matrix, will be like a subject matter expert who
will be approached for recommendations and feedback.
 Role that is tagged as Informed in RACI matrix, will be a stakeholder who should be
communicated about the actions taken in performing the specific task.

Lack of matrix in ITSM operations will lead to ambiguity in performing respective duties, blame
games, and confusions at their work activities.

Roles and Responsibilities Template for Change

Management
Generic roles that are available in change management are change manager, change analyst, and
CAB (Change advisory board).

Change Manager
  Maintaining change management system, including policies, processes, systems, metrics
and procedures that are used across the entire IT business and adheres to all regulatory
requirements.
 Research & proactively identify opportunities to process, measurements, and systems in
order to improve the effectiveness and efficiency of change management services.
 Work closely and communicate effectively with users and stakeholders of the change
process to drive the improvements.
 Assure service quality objectives, governance compliance, and responsiveness through
KPIs and metrics.
 Attends all CAB meetings.
 Support the development and execution change management activities in partnership with
customer teams – including stakeholder engagement, communication, training, and
readiness and adoption measurement plans.
 Collaborate with the team and key stakeholders to ensure timely delivery and quality of
assigned deliverables.
 Identify possible issues/concerns, escalate risks and issues to management and project
leadership teams, and implement mitigation plans if necessary.
 Identify training needs by analysis of common errors.
 Keep the customers and internal stakeholders up to date on high priority changes through
timely and regular written and verbal communications.
 Review the business case of all RFCs/change requests and formulate a plan of action for
handling the change based on area of expertise/responsibility.
 Ensure change management documentation is updated.
 Gather and analyze information on a variety of changes and develop action plans to
contain and control incidents.
 Liaison with internal training and communications staff to produce user guidance and
bulletins explaining best practice and common issues.
 Provide information and reports on change implementations, successful changes, and
failed changes.
 Verify implemented changes.
 Conduct PIR on successful and failed changes and conduct RCA.

Change Analyst

 Register, categorize, and prioritize changes after conducting thorough analysis

 Conduct risk analysis before submitting it for CAB approval
 Facilitate CAB meetings
 Maintain a balance between the business need for prompt change and the necessity of
ensuring that stability of existing systems is not compromised.
 Document and publish the CAB – MOM (Minutes of the meetings)
 Reroute misdirected changes that have not been handled in a timely manner
 Identify changes that needs special attention or escalation
 Ensure change report is created immediately after successful implementation
 Draft and send out communications to ensure that all relevant stakeholders are aware of
procedures
  Work with change manager to ensure change activities are properly communicated
 Ensure change implementers are adhering to the process and procedures as defined

CAB

 Responsible for making decisions on whether or not the RFC would bring positive
results, value to the organization, reduce the manual efforts, and reduce the costs.
 Approve changes/reject the changes based on:
1. the risk to IT services and business services
2. impact of a change on availability, performance, security, compliance, and SLAs
3. provision of procedures
4. test plans defined
5. test results gathered
 Ensure that the change is planned well and is equipped with all procedures to test and
implement.
 Review the implemented changes
 Discuss previously failed, rolled back, and backed out changes to understand what went
wrong
 Participating in CAB meetings
 Authority to represent a particular group or function
 Preparing for CAB meetings by circulating RFCs within their own group and
coordinating feedback
 Reviewing RFCs and recommending whether they should be authorized
 Reviewing successful and failed changes
 Reviewing unauthorized changes
 Reviewing the change schedule and providing information to help identify conflicts or
resource issues
 Reviewing the projected service outage and providing feedback on the impact of planned
outages.

How to implement RACI matrix

1. First, define the process, which will be a sequence of activities that will result in a
specific outcome with the help of some roles and capabilities. Here you need to define the
different roles needed for the process like change manager, change implementer, CAB,
etc.
2. Second, Identify the sequence of activities in a lifecycle based approach. For example:
Raise change request, Categorize the change request, Assess the change request, etc.
3. Third, Identify the decisions in every activity. For example: Approve the test plan,
Approve the rollback plan, etc.
4. Fourth, each and every defined activity and decision should be tagged to a specific role.
5. Fifth, define the matrix with columns and rows. Naming the first column heading as
‘Activity’, and below it (that is Activity column) define the different activities in a
sequenced order. Define the other columns headings with the respective roles defined in
the process.
6. Finally, populate the information ‘R’, ‘A’, ‘C’, ‘I’ in the rows and columns ensuring there
is:
o One and only one ‘A’ (i.e. accountable role) for a specific task
o Every task should have one ‘R’ and can also have many ‘R’s (i.e. responsible
roles) based on the task
o Lastly, tasks can have one or more ‘C’s (i.e. consulted roles) and ‘I’’s (i.e.
informed roles) based on the task.