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:
- who sponsors the respective change
- who is allowed to request (trigger) the standard change (e.g. which users)
- 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
- on time?
- 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
- from a user via a Support Process
- from the customer triggered by the Service Portfolio Management Process
- from the Change Management Process itself, when a „sub“ change is needed
- from a Delivery Process

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
- the requester and customer are informed
- the Change Builder, Change Tester and Change Implementer is defined by the ECAB
- the Change Agent is set to Change Builder
- after planning the change the Change Agent is set to Change Tester
- after successful testing, the Change Agent is set to Change Implementer

if the priority „emergency“ is NOT confirmed
- the Change Agent, Change Authority and Change Owner are set to their previous values
- 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“
- the Change Agent is set to the Change Builder.
- the outcome of the „Risk Analysis“ and the „Feasibility Study“ has to be documented in the Change Record
- the „Change Priority“ is defined according to the outcome. The priority „emergency“ is no longer possible
- the „Change Category“ is defined reflecting the risk as diagnosed in the Risk Analysis
- 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)
- for category 1 it is Service Owner
- for category 2 it is Change Advisory Board (CAB)
- 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:
- the Change Agent is set to Change Owner
- the Configuration Management Process is triggered for documentation in the CMDB
- 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