Back to Basics – ITIL Change Management Process

Digital transformation is a high priority activity for most IT leaders now. Businesses undergo similar transitions on a regular basis that differ in risk and impact. Seamless operation is a gift for any business to improve efficiency. Therefore, it is important to streamline this process to ensure minimal disruption or downtime. The ITIL change management process is a precursor to release management and this includes detailed assessment & planning before the change is actually released.

Objectives

◈ Reduce risk and impact
◈ Retain current working state
◈ Streamline communication and approvals
◈ Effective change planning
◈ Reduce incidents due to change execution

Examples – Windows patch, new software installation, changes to network infrastructure components, changes to ERP application

Change Management process flow

ITIL Change management process follows different stages that include every change detail. Following is the change management process flow

Request for Change

The first step is to request for a change with valid justifications. A Change record is created in one of the following scenarios

◈ Incident causes a new change
◈ A known problem leads to a change
◈ End user requests a new change
◈ Change manager creates a change as result of an ongoing maintenance

Request for Change (RFC) proposal contains following information along with necessary details

Change evaluation and planning

Change assessment committee evaluates submitted RFC and suggests necessary changes. This is followed by Change planning that follows a standard procedure such as

◈ Prioritizing a change – Prioritize change request and determine change type depending on risk and impact
◈ Scheduling a change – Schedule the change based on release window. Decide on the planned start date and end date
◈ Roll out plan – Implementation activities and approach
◈ Back out plan – Back out activities in case of any failure

Change approvals

Effective communication is the key to managing approvals on time. Automate approval process to reduce manual effort and save time. For example, major change requires CAB approval as well as management’s whereas standard changes are pre-approved and do not require any approval.

Change implementation & review

Release management takes care of the actual deployment. It includes build plan, test plan and batching. Change review happens post implementation to determine whether it’s a success. Review of completed changes helps in revisiting and modifying existing change management process if necessary.

Types of changes

Let us look at different types of changes and some of the common examples for each change type.

Major change 

Major changes are high impact and high risk items that might affect production systems. This requires CAB approval as well as management approval. This has a huge impact on ongoing business operations and also has financial implications. Therefore, RFC contains a detailed proposal on cost-benefit, risk-impact analysis.

Examples – migration from one datacenter to another; replacing an existing enterprise solution, ERP.

Standard change 

Standard changes are usually pre-approved changes and have low impact & low risk. These changes occur in a regular interval and follow the standard template. CAB approval is not required as these changes are evaluated and approved initially.

Examples – OS upgrade, deploying patch, setting up an user account etc.

Minor change

Minor changes are generally normal changes that do not have a major impact and are less risky to execute. These are non-trivial changes that undergo every stage of change lifecycle including CAB approval. Eventually, minor changes are converted to standard changes in future.

Examples – application performance improvement, website changes.

Emergency change

Emergency changes are unexpected interruptions that need to be fixed as quick as possible. This does not follow the conventional workflow whereas retrospective RFC is created post implementation. Emergency CAB (ECAB) is responsible to manage approvals. Review is completed later to avoid potential infrastructure risks in future and detailed documentation is done post implementation.

Examples – security fix, server outage.