Change Management

Objective: ITIL Change Management aims to control the lifecycle of all Changes. The primary objective of of this process is to enable beneficial Changes to be made, with minimum disruption to IT services.

Contents

• 1 ITIL 4 Change Management - Change Enablement
• 2 Process Description
• 3 Sub-Processes
• 4 Definitions
• 5 Templates | KPIs
• 6 Roles | Responsibilities
• 7 Examples
• 8 Notes

ITIL 4 Change Management - Change Enablement

The Change Management process described here follows the specifications of ITIL V3, where Change Management (fig. 1) is a process in the service lifecycle stage of Service Transition.

ITIL V4 is no longer prescriptive about processes but shifts the focus on 34 'practices', giving organizations more freedom to define tailor-made processes.

ITIL 4 therefore refers to Change Management as a service management practice, and has renamed the practice to "Change Enablement". ITIL V4 describes Change Enablement key activities, inputs, outputs and roles. Based on this guidance, organizations are advised to design a process for managing Changes in line with their specific requirements.

Note: The ITIL 4 practice of Change Enablement was called "Change Control" in the early editions of ITIL 4 and later renamed to "Change Enablement".

Since the processes defined in ITIL V3 have not been invalidated with the introduction of ITIL V4, organizations can still use the ITIL V3 process of Change Management as a template.

Note:
In our YaSM Service Management Wiki we describe a leaner set of 19 service management processes that are more in tune with ITIL 4 and its focus on simplicity and "just enough process".

The YaSM service management model includes a process for managing changes that is a good starting point for organizations that wish to adopt ITIL 4.

Process Description

Change Management seeks to minimize the risk associated with Changes, where ITIL defines a Change as "the addition, modification of removal of anything that could have an effect on IT services". This includes Changes to the IT infrastructure, processes, documents, supplier interfaces, etc.

ITIL distinguishes between three different types of Changes:

1. Standard Changes: Pre-authorized, low-risk Changes that follow a well-known procedure.
2. Emergency Changes: Changes that must be implemented immediately, for example to resolve a Major Incident.
3. Normal Changes: All other Changes that are not Standard Changes or Emergency Changes.

Normal Changes are often further categorized as Major, Significant or Minor, depending on the level of risk involved. Organizations should define these types of Changes and the required Change Authorities in their Change Policy. For example, Major Changes may require a full review by the CAB (Change Advisory Board), while Significant Changes may be approved by the Change Manager.

If a Non-Standard Change is needed, the party requiring the Change will typically submit a Request for Change (RFC) to Change Management. Change Management will then record, analyze and approve (or reject) the Change.

Emergency Changes are assessed and approved by the ECAB (Emergency Change Advisory Board), a core group of CAB members that is available on short notice to respond to emergencies.

For certain types of Changes, a formal Change evaluation takes place by the Change Evaluation process and is documented in a Change Evaluation Report.

Organizations should streamline Change Management and avoid unnecessary bureaucracy by using the full Change Management process only for a small number of significant Changes. Effectiveness and efficiency of Change Management can be improved, for example, by

• Creating Change Models for recurring Changes
• Decentralizing Change approval for Standard Changes
• Breaking bigger Changes into smaller pieces that carry less risk
• Using automated checks, testing and deployment.

Change Management interfaces with a number of other ITIL processes:

• The Service Strategy process submits Change Proposals, so Change Management can review proposed strategic Changes for their impact on other services, resources, etc.
• Several other ITIL processes will submit RFCs to Change Management if Changes are required. For example, Problem and Incident Management may need to implement Changes to resolve Problems and Incidents. Service Design will typically submit RFCs in preparation for a new or enhanced service, and Service Improvement may propose Changes to improve the services.
• Configuration Management provides essential information for the assessment of proposed Changes and their impact on related Configuration Items. Configuration Management receives updated configuration data from Change Management as Changes are implemented.
• Change Evaluation will be triggered from the Change Management process for those Changes that require formal evaluation.

The process overview of ITIL Change Management (fig. 1) shows the key information flows of the process.

Sub-Processes

These are the ITIL Change Management sub-processes and their process objectives:

Change Management Support

• Process Objective: To provide templates and guidance for the authorization of Changes, and to supply the other IT Service Management processes with information on planned and ongoing Changes.

Assessment of Change Proposals

• Process Objective: To asses Change Proposals which are typically submitted for significant Changes by Service Strategy. The purpose of assessing Change Proposals is to identify possible issues prior to the start of design activities.

RFC Logging and Review

• Process Objective: To filter out Requests for Change which do not contain all information required for assessment or which are deemed impractical.

Assessment and Implementation of Emergency Changes

• Process Objective: To assess, authorize and implement an Emergency Change as quickly as possible. This process is invoked if normal Change Management procedures cannot be applied because an emergency requires immediate action.

Change Assessment by the Change Manager

• Process Objective: To determine the required level of authorization for the assessment of a proposed Change. Significant Changes are passed on to the CAB for assessment, while minor Changes are immediately assessed and authorized by the Change Manager.

Change Assessment by the CAB

• Process Objective: To assess a proposed Change and authorize the Change planning phase. If required, higher levels of authority (e.g. IT Management) are involved in the authorization process.

Change Scheduling and Build Authorization

• Process Objective: To authorize detailed Change and Release planning, and to assess the resulting Project Plan prior to authorizing the Change Build phase.

Change Deployment Authorization

• Process Objective: To assess if all required Change components have been built and properly tested, and to authorize the Change Deployment phase.

Minor Change Deployment

• Process Objective: To implement low-risk, well-understood Changes which do not require the involvement of Release Management.

Post Implementation Review and Change Closure

• Process Objective: To assess the course of the Change implementation and the achieved results, in order to verify that a complete history if activities is present for future reference, and to make sure that any mistakes are analyzed and lessons learned.

Definitions

The following ITIL terms and acronyms (information objects) are used in ITIL Change Management to represent process outputs and inputs:

CAB Agenda Template

• The CAB Agenda lists the topics for discussion in a CAB meeting.

• The addition, modification or removal of anything that could have an effect on IT services. The scope should include changes to all architectures, processes, tools, metrics and documentation, as well as changes to IT services and other configuration items.

Change Evaluation Report

• Certain types of major Changes, like the introduction of a new service or a substantial change to an existing service, require formal Change evaluations before being authorized. The results of a formal Change evaluation are documented in a Change Evaluation Report. Change evaluations may be used at different points in a Change’s lifecycle, for example before authorizing the Change/ Release build or during the Post Implementation Review (PIR).

Change Management Policy

• The decision to authorize or reject a proposed Change is based on the completed Change Assessment. In particular, the assessment is about properly understanding the risks associated with the implementation of a Change. In this context, the Change Management Policy specifies the levels of authorization required to authorize different types of Changes and other rules for assessing Changes.

Change Model

• Change Models describe procedures for the handling of recurring Changes. While Change Models can be created for Changes of any scale, they are often used to define Standard Changes (low-risk, pre-authorized Changes like installing additional hardware on a client PC).

Change Proposal

• A Change Proposal describes a proposed major Change, like the introduction of a new service or a substantial change to an existing service. The purpose of Change Proposals is to communicate a proposed major Change and assess its risk, impact and feasibility before design activities begin. Change Proposals are typically created in Service Portfolio Management.

Change Record

• The Change Record contains all the details of a Change, documenting the lifecycle of a single Change. It is usually created on the basis of a preceding Request for Change (RFC).

Change Schedule

• A Document that lists all approved Change Proposals and Changes and their planned implementation dates. A Change Schedule is sometimes called a Forward Schedule of Change (FSC).

Emergency Change

• A Change that must be introduced as soon as possible - for example, to resolve a major incident or implement a security patch.

Projected Service Outage (PSO)

• The Projected Service Outage (PSO) document lists any expected deviations from the service availability agreed in SLAs.

Request for Change (RFC)

• A formal request for a Change to be implemented. An RFC, specifying the details of the proposed Change, must be submitted to Change Management for every non-standard Change (see also: ITIL Checklist Request for Change - RFC).

RFC Template

• A template to be used when formally requesting a Change. An RFC includes details of the proposed Change, and may be recorded on paper or electronically.

Templates | KPIs

• Key Performance Indicators (KPIs) Change Management
• Change Management templates and checklists:
  • Request for Change (RFC template), and
  • Change Record
  • Change Classification
  • CAB Agenda
  • Forward Schedule of Changes (FSC checklist)
  • Post Implementation Review (PIR template)

  Roles | Responsibilities

  Change Manager - Process Owner

  • The Change Manager controls the lifecycle of all Changes.
  • His primary objective is to enable beneficial Changes to be made, with minimum disruption to IT services.
  • For important Changes, the Change Manager will refer the authorization of Changes to the Change Advisory Board (CAB).

  Change Advisory Board (CAB)

  • A group of people that advises the Change Manager in the assessment, prioritization and scheduling of Changes.
  • This board is usually made up of representatives from all areas within the IT organization, the business, and third parties such as suppliers.

  Emergency Change Advisory Board (ECAB)

  • A sub-set of the Change Advisory Board who makes decisions about high impact Emergency Changes.
  • Membership of the ECAB may be decided at the time a meeting is called, and depends on the nature of the Emergency Change.
  Responsibility Matrix: ITIL Change Management

  ITIL Role / Sub-Process [Details]	Change Manager	Change Advisory Board (CAB)	Emergency Change Advisory Board (ECAB)	IT Operator[3]	Other Roles involved[3]
  Change Management Support	A[1]R[2]	R[4]	-	-	-
  Assessment of Change Proposals	AR	R	-	-	-
  RFC Logging and Pre-Evaluation	AR	-	-	-	-
  Assessment and Implementation of Emergency Changes	AR	-	R	-	R[5]
  Change Assessment by the Change Manager	AR	-	-	-	R[6]
  Change Assessment by the CAB	AR	R	-	-	R[6]
  Change Scheduling and Build Authorization	AR	R	-	-	-
  Change Deployment Authorization	AR	R	-	-	-
  Minor Change Deployment	AR	-	-	R	-
  Post Implementation Review and Change Closure	AR	-	-	-	-

  [1] A: Accountable according to the RACI Model: Those who are ultimately accountable for the correct and thorough completion of the Change Management process.

  [2] R: Responsible according to the RACI Model: Those who do the work to achieve a task within ITIL Change Management.

  [4] The documents created or managed by this process must be approved by the CAB.

  [5] Applications Analyst, Technical Analyst, IT Operator (and others, as appropriate)

  [6] Configuration Manager, Applications Analyst, Technical Analyst (and others, as appropriate).

  Examples

  The ITIL Process Map screenshots show samples of the ITIL process templates with contents from Service Transition and ITIL Change Management, including the

  • high-level view of the ITIL Service Lifecycle (Level 0)
  • overview of the Service Transition process (Level 1)
  • overview of the Change Management process (Level 2)
  • detailed process flow for the process "Assessment of Change Proposals" (Level 3)

  Notes

  By: Stefan Kempter , IT Process Maps.