ITIL Change Management Types: Standard vs. Normal vs. Emergency

What Is ITIL Change Management? 

The Information Technology Infrastructure Library (ITIL) is a framework for implementing IT management strategies like IT service management (ITSM). Change management is a systematic approach within ITSM that ensures changes to IT services and infrastructure are carried out in a controlled, consistent manner. 

The ITIL change management process aims to minimize the impact of change-related incidents on service quality and improve the day-to-day operations of an organization. By assessing, authorizing, and monitoring changes, organizations can adapt to new requirements while maintaining stability and reliability in their IT services.

ITIL change management tries to balance the need for changes within IT systems against the potential risks those changes pose. It provides a framework for evaluating the benefits of proposed changes against their potential to disrupt services, ensuring that only beneficial changes are implemented. This process involves various stakeholders, including IT professionals, business managers, and end-users, to ensure that changes serve the broader objectives of the organization.

This is part of a series of articles about IT change management

The ITIL Change Management Lifecycle

The ITIL change management lifecycle outlines the stages through which a change must pass from initiation to completion. This is a general ITIL change management process, but the process might be slightly different for specific types of changes:

1. The lifecycle begins with the Request for Change (RFC), where the need for a change is identified and formally documented. 
2. This is followed by the assessment phase, where the impact, cost, benefit, and risk of the proposed change are evaluated. The decision to approve or reject the change is made based on this assessment.
3. Once a change is approved, the planning phase begins. During planning, detailed steps for executing the change are developed, resources are allocated, and timelines are set. 
4. Next, the implementation phase involves the actual execution of the change according to the plan. 
5. The lifecycle concludes with a review and closure stage, where the success of the change is evaluated, and any lessons learned are documented for future reference. 

This structured approach ensures that changes are managed efficiently and effectively, reducing the risk of negative impacts on services.

Types of Changes in ITIL and Their Use Cases 

The ITIL framework can be used to manage three primary types of changes to IT services: normal, standard, and emergency. The following diagram illustrates how to classify changes into these three types.

Normal Changes

Normal changes are those that require a full assessment, authorization and scheduling process due to their potential impact on IT services. Normal changes involve significant modifications to IT services or infrastructure, where the scope or impact requires thorough scrutiny.

The change management process for normal changes involves:

1. Request for Change (RFC): An RFC is submitted detailing the proposed change, including the rationale, impact, resources required, and proposed implementation date.
2. Assessment: The change is assessed for impact, cost, benefits, and risks. This involves detailed analysis and may require input from various stakeholders across the organization.
3. Authorization: Based on the assessment, the change is either approved, rejected, or sent back for further information. Approval may come from a Change Advisory Board (CAB) or a designated authority, depending on the organization’s policies.
4. Implementation planning: Once approved, detailed planning for implementing the change is undertaken. This includes scheduling, resource allocation, and defining clear steps for execution.
5. Implementation and Review: The change is implemented as planned. After implementation, a review is conducted to ensure the change has achieved its objectives without causing unintended disruptions.

Standard Changes

Standard changes are pre-approved, low-risk, and follow a specific procedure. These are routine changes that occur frequently, have a known risk and predictable outcome, and do not require full assessment and authorization for each instance. 

Standard changes help in streamlining routine tasks and reducing the workload on change management processes by minimizing bureaucracy for low-risk changes. They are commonly automated to reduce the load on ITSM teams.

The process for managing standard changes includes:

1. Pre-approval: These changes are pre-approved due to their routine nature and well-understood impact. A typical example might be a software update or password reset.
2. Documentation and procedures: Detailed procedures and documentation are established for executing standard changes to ensure consistency and efficiency.
3. Execution: Given their pre-approved nature, standard changes can be implemented quickly following the established procedure without the need for further authorization.
4. Post-implementation review: Even though these changes are pre-approved, monitoring their execution and outcomes is important to ensure they continue to meet the criteria for standard changes.

Emergency Changes

Emergency changes are required to address urgent issues that pose an immediate risk to business operations, such as security vulnerabilities or critical system failures. The process for emergency changes is expedited to resolve such issues quickly while minimizing negative impacts. 

This process includes:

1. Identification and initiation: An emergency change is initiated in response to an urgent issue, bypassing the normal RFC process.
2. Expedited assessment: Given the urgent nature, the assessment process is expedited. The focus is on quickly understanding the impact, risks, and benefits of the proposed change.
3. Emergency authorization: Approval is obtained from an Emergency Change Advisory Board (ECAB) or designated authority capable of making swift decisions.
4. Rapid implementation: The change is implemented as quickly as possible to mitigate the identified risk or restore service.
5. Post-implementation review: A thorough review follows the implementation to assess the change’s effectiveness and to document any lessons learned for future emergency changes.

Examples of ITIL Change Management Use Cases 

Requesting a New Service (Normal Change)

Consider a global eCommerce company that identifies the need to integrate a new chatbot service. This request is categorized as a normal change. The initiative aims to provide instant responses to customer queries, improving service availability and customer satisfaction. 

The process begins with the submission of a Request for Change (RFC) that outlines the objectives, the technical specifications of the chatbot, the expected impact on existing IT services, and a detailed implementation plan. The change undergoes a thorough assessment to evaluate its potential benefits against the costs and risks involved. Stakeholders across various departments, including customer service, IT, and security, are consulted to ensure that the integration aligns with the organization’s overall objectives. 

Once approved, a comprehensive implementation plan is developed, detailing the deployment phases, necessary resources, and a timeline for completion. The successful implementation of the chatbot is then reviewed to ensure it meets the initial objectives without negatively impacting other IT services.

Decommissioning a Server (Standard Change)

Decommissioning a server in a medium-sized software development company is an example of a standard change. This process is part of the company’s routine infrastructure maintenance to phase out older, underutilized servers and consolidate resources for efficiency. 

As a standard change, the procedure for server decommissioning is pre-approved, documented, and includes steps such as backing up critical data, informing relevant stakeholders of the downtime, physically decommissioning the hardware, and updating the inventory records. The process is designed to be executed with minimal risk and disruption to the company’s operations. 

Due to its routine nature and the predictable outcomes, the IT team can quickly carry out the decommissioning without needing a detailed assessment or authorization for each server. Post-implementation, a brief review ensures the change was executed according to the standard procedure and that all data and services were successfully migrated or archived as planned.

Applying a Security Fix (Emergency Change)

An example of an emergency change is a critical vulnerability in an online banking system, which puts customer data at risk. To address this urgent security threat, an emergency change is initiated to apply a security patch. The process bypasses the usual Request for Change (RFC) procedure, moving directly to an expedited assessment to understand the vulnerability’s impact, the risks of not acting swiftly, and the benefits of the proposed security fix. 

The Emergency Change Advisory Board (ECAB) is convened to review the situation and approve the rapid implementation of the patch. Given the urgency, the IT security team works around the clock to apply the fix, test the system for stability, and restore secure service to customers. 

After the implementation, a detailed review assesses the change’s effectiveness, documents the incident, and extracts lessons learned to improve the response to future emergencies, ensuring the bank maintains the trust and security of its customers’ data.

Faddom: Supporting ITIL Change Management with Application Dependency Mapping