Change Management

Change Management

ITIL Change Management: Overview

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

Part of: Service Transition

Process Owner: Change Manager

ITIL Change Management: Process Definition

ITIL Change Management

Essentially, the activities and process objectives of the Change Management process are identical in ITIL V3 and V2. ITIL V3 introduces "Change Models", putting more emphasis on defining different types of Changes and how they are to be handled.

Emergency Changes in ITIL V3 are authorized by the Emergency Change Advisory Board (ECAB), which was known as the Emergency Committee (EC) in ITIL V2.

The following sub-processes are part of Change Management according to ITIL V3:

Sub-Processes

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.

RFC Logging and Pre-Evaluation

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

RFC Classification

Process Objective: To verify if the priority of the proposed Change was correctly set by the initiator, and to determine the adequate level of authority to approve or reject the RFC.

Assessment of Urgent RFC by the ECAB

Process Objective: To authorize, adjust or reject an urgent Requests for 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 authorize or reject a proposed Change as well as to ensure a preliminary scheduling and incorporation into the Change Schedule.

Change Assessment by the CAB

Process Objective: To authorize or reject a proposed Change as well as to ensure a preliminary scheduling and incorporation into the Change Schedule.

Change Scheduling

Process Objective: To agree a preliminary schedule for Change implementation and to transfer responsibility for Change deployment to Project Management and Release Management.

Change Evaluation

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 analysed and lessons learned (Post Implementation Review).

ITIL Terms: Change Management

Change Authorization Hierarchy

The Change Authorization Hierarchy defines who is to assess a proposed Change, depending on the Change’s level of risk.

Change Model

Change Models describe procedures for the handling of recurring Changes. Typically, a Change Model is provided by the Change Manager for each Standard Change (low-risk, pre-authorized Change)

Change Record

The Change Record contains all the details of a Change, documenting the lifecycle of a single Change, where a Change is defined as the addition, changing or removal of any object with an influence upon the IT services.

Change Schedule

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

Post Implementation Review (PIR)

The Post Implementation Review takes place after a Change has been implemented. It determines if the Change and its implementation Project were successful, and identifies opportunities for improvement.

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 includes details of the proposed Change, and may be recorded on paper or electronically. The term RFC is often misused to mean a Change Record, or the Change in itself (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.

Additional Information on Change Management

ITIL KPIs and Checklists

• Key Performance Indicators (KPIs) Change Management
• Checklists Change Management: Checklist Request for Change - RFC

ITIL Roles and Boards in Change Management

Change Manager - Process Owner

The Change Manager authorises and documents all changes in the IT Infrastructure and its components (Configuration Items), in order to maintain a minimum amount of interruptive effects upon the running operation.

In the case of further-reaching changes, he involves the Change Advisory Board (CAB).

Change Advisory Board (CAB)

A group of people that advises the Change Manager in the Assessment, prioritisation and scheduling of Changes.

This board is usually made up of representatives from all areas within the IT Service Provider, the Business, and Third Parties such as Suppliers.

Change Owner

The person backing a Change and holding a budget for its implementation.

In most cases the Change Owner is identical with the RFC initiator.

Typically Changes are owned by Service Management roles (e.g. the Problem or Capacity Manager) or members of IT management.

Configuration Manager

The Configuration Manager is responsible for maintaining information about Configuration Items required to deliver IT services.

To this end he maintains a logical model, containing the components of the IT infrastructure (CIs) and their associations.

Emergency Change Advisory Board (ECAB)

A sub-set of the Change Advisory Board who make 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.

Release Manager

The Release Manager is responsible for planning, scheduling and controlling the movement of Releases to test and live environments.

His primary objective is to ensure that the integrity of the live environment is protected and that the correct components are released.