Related Articles

• Change Management - Octopus Module
• ITIL® Glossary

Introduction

This article introduces the key concepts of the ITIL® Change Management process. We included the essential components you need to understand to help you with your integration of changes in Octopus.

Whatever the size of a company, poorly managed changes have significant consequences for both the company and the IT organization. Changes are not only used to correct errors in the infrastructure at the moment they occur. By minimizing risks and impacts, an IT organization demonstrates its ability to sustain the needs of its customers, whose objectives are to grow and... survive.

The poor management of changes, for an IT organization, can manifest as:

• "surprise" outages
• the occurrence of incidents after a change
• a high number of urgent changes

From a user's point of view, it results in interruptions that prevent them from doing their job, which implies a cost for the company. It also has a negative impact on user perception of the IT organization. Changes are seen as "problems" and are received with both reluctance and suspicion.

What is a change?

The ITIL® definition of a change is the addition, modification or removal of anything that could have an effect on IT services. The real question is: what should be considered a change and how an IT organization needs to treat it so as to minimize impacts and risks, while being certain to meet the real needs of the company? There is no change without risk, and this risk must be known and managed. In this perspective, one could also say that a change is "any action that constitutes a risk to an IT service".

You will find more definitions in ITIL® Glossary, "Change Management" section.

The Process

Purpose & Objectives

The purpose of the Change Management process is to control the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services.

The main objectif is to ensure that all changes are recorded, evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner.

For this control to be carried out satisfactorily, Change Management process must oversee, among others:

• reuse standardized methods and procedures
• make sure that those methods are known and applied by all participants
• record all changes
• consider risks and impacts on business

Scope

Very simply, the scope of Change Management process may be identified by any addition, modification or removal of configuration items that are used in the delivery of IT services. What consist IT services? Physical assets (servers, network assets), virtual (virtual servers, virtual storage), softwares ou applications, documentation, IT services, processes or others. They involve IT resources, clients/users and external providers.

Realistically speaking, this does not mean that Change Management process should consider all types of assets from day one. For some organizations, the recording of all changes, by IT resources that understand clearly what is a change, represents a big step forward.

Categorization

There are three (3) categories of change:

Standard Change

• Change pre authorized by Change Management, relatively common, performed according to a pre established procedure or work instruction ("workflow"), and whose risk is controlled (examples of standard changes: patch upgrade, replacement of a printer, relocation of more than x users). A list of standard changes can be predefined; any change that is not part of this list whould be treated as a normal change. 

Normal Change

• Change that is not a standard or an urgent change. It follows activities defined in the Change Management process. According risks, impacts, costs and dependencies with other changes, it is divided into 3 categories:
  • Minor
  • Significant
  • Major

Urgent Change

• Normal change to be implemented as soon as possible. Essentially, it will follow the same process as the normal changes, but will be adapted to the emergency situation. If the CAB cannot meet quickly, the ECAB, having the autority level needed to make decisions, will be invoked. Testing must be carried out as much as possible, and documentation of change and configuration data may be completed later (example of urgent changes: solving a major incident, deploy an urgent security patch, etc.).

Prioritization

The priority of a change is derived from impact and urgency. In the context of a change, we could define them the following way:

• Impact : measures the effect of a change on the business. Relies on the business benefits or the extent of damages if the change goes wrong
• Urgency : time it takes for a change to have a significant impact on business. Relies on the acceptable implementation change delay
• Priority : identifies the relative importance of a change. Relies on impact and urgency. Considers the concept of risk management and the consequences on business activities

Activities

To better understand the progress of the Change Management process, here is a brief description of each activity:

1. Record

   A request for change can originate from the enterprise or the IT organization. First, there must be an agreement on who can submit a change (a super user, an application owner, an IT resource). All recorded changes are identified by a unique number. The impacts, risks, benefits of change, etc. are part of the information to provide for the validation and evaluation of the change. The documentation of these requirements can be a form, a document to fill out, or other.

2. Review

   We proceed with a filtering of submitted changes. Some of them may be illogical, unenforceable, incomplete, or have already been submitted by someone else.

3. Assess & Evaluate

   • The change is classified and the appropriate approval level is applied

   • The composition of the CAB is determined

   • Change justification, business benefits, impact, cost, risk are evaluated

4. Approve

   The approval of the changes allows access to the production environment; this is the responsibility of Change Management. Impacts, risks, benefits, backout procedure, etc. have been evaluated and the approval authority agrees or refuses deployment. First, we must agree on who approves what. For example, we might agree that:

   • Standard changes are preapproved

   • Change manager approves minor changes

   • The CAB authority approves significant, major and urgent changes, with the ECAB taking over in case the CAB is not available
      

   What is the CAB / ECAB ?
   • The CAB is the Change Advisory Board. Its role is to contribute to the assessment, prioritization and schedule of changes, and it participates in their approval. During CAB meeting, all addressed changes must be evaluated by considering two perspectives: technical and operational (business perspective). The important thing is to identify the right participants and the correct hierachial level to involve; this could include IT resources and managers, business users and managers, and external suppliers.
     
     A permanent CAB can be constituted and for particular changes, other participants are implicated. It is the responsibility of the change manager to form and chair the CAB.
   • The ECAB is the Emergency Advisory Board. It is invoked when the regular CAB cannot be rapidly constituted. ECAB must have the authority to take urgent decisions and business has to be represented.

   _________________________________________________________________

   CAB MEETINGS

   CAB meetings may be conducted remotely - sometimes the situation requires it - by email, telephone or any other remote means of communication such as video conferencing. As the decision level is higher for changes with a high risk and impact, it is necessary that participants be in optimal communication conditions to facilitate exchanges leading to a sound decision (email is not an option here).

   CAB will be adapted to the context and the size of the IT organization. The important thing is to have sufficient authority that ensures that changes can be monitored, the risks assessed and the service disruptions minimized to target a successful deployment at the first attempt. The relevant documents must be made available in advance to allow CAB members to evaluate changes and prepare for meetings. A change submission deadline will prevent changes from being presented at the last minute, and is considered a good idea.

   Like any effective meeting, the CAB must have an agenda, and is not meant to discuss the construction of the change. Changes submitted to the CAB should be prepared before being assessed and approved. The CAB meets at regular intervals to prioritize, evaluate the presented changes, make a review of completed changes, discuss the changes implemented without authorization, etc. In principle, it is an advisory entity, but could be designated as the approval authority. In case of disagreement, the IT manager will be asked to make the decision. 

   An approval model needs to be constituted to clarify the hierarchical levels involved in significant, major and urgent changes, which have variable impacts and risks.

    

   Example of an Approval Model

   

5. Coordinate & implement

   Execution tests for approved changes must be forwarded to the relevant technical teams and "test" users to prepare for implementation. Changes must be tested carefully, a backout procedure identified and documented, temporary solutions for potential incidents documented, etc.
    

6. Review & Close

   Implemented normal and urgent changes are reviewd after deployment; CAB instance determines if the review is necessary. The following questions may be addressed:

• ​Has the change achived the desired goal?

• Are stakeholders satisfied with the result?
• Were there unexpected side effects?
• Were there cost and effort overruns compared to the initial assessment?
• Can we do better next time and improve the process?

If the change is successful, it can be closed. Otherwise, change management or CAB decides what to do: a new change or a modification of the unsuccessful change. 

Before closing, change manager verifies that the documentation is complete, and ensure to include the change review. All this information can serve as knowledge base for a similar new change, or as a contribution to the continuous improvement of the process.

Metrics

• Number or % of changes successful / partially successful / unsuccessful
• Number or % of unsuccessful changes without backout plan
• Number or % of non authorized changes
• Number of backlog changes
• % of completed changes in time
• % of changes that has caused incidents
• Number or % of urgent changes

Change or service request?

By definition, a service request is a standard change. Both are pre approved, relatively common, with a pre defined workflow and their risk is controlled. It is up to each organization to define a formal list of requests meeting these criteria; service requests are mostly requests submitted by end-users. Supported by the Request Fulfilment process, they are followed by the Service Desk and lighten the Change Management process.

Here are clarification about this:

• Clearly define what is a service request and what is a change for your organization, and ensure that all team members understand the difference
• Record a change if an action represents a risk or an impact on business, event if it is low, and/or needs a service interruption (system unavailability)
• We could decide that any change to a specific CI type passes through Change Management process, as a network equipment, by example
• All requests that are not part of the list of service requests must be recorded as changes
• Service requests and standard changes are pre approved and do not need CAB assessment and approval

The clearer, better known, understood and followed rules are, more succesfull will Change Management be.