Develop > Processes and Best Practices > Change Management Workflows > Emergency Change (process ST 2.4)

Emergency Change (process ST 2.4)

Emergency changes can also be initiated in the Incident Management process. They should be used only to repair an IT service error that is negatively impacting the business at a high level of severity. Changes that are intended to make an immediately required business improvement are handled as normal changes, although they may be assigned a high priority based on the urgency of the required business improvement.

The emergency change process follows the normal change process, except for the following:

  • Approval is given by the Emergency Change Approval Board (E-CAB) instead of waiting for a regular CAB meeting.
  • Testing may be reduced, or in extreme cases eliminated, if doing so is considered necessary to deliver the change immediately.
  • Updating of the change request and configuration data may be deferred, till normal working hours.

If the E-CAB decides to handle an emergency change as a normal change, the emergency change is recategorized and implemented using the normal change process.

The following user roles are involved in Emergency Change Handling:

  • Change Manager
  • E-CAB
  • Change Owner

The following figure depicts the Emergency Change workflow in Process Designer.

For details of the Emergency Change process, see the following figure and table.

Emergency Change process

Process ID

Procedure or Decision

Description

Role

ST 2.1

Register RFC

Emergency Change activities provide the expedited Change Management process, which implements changes to the production environment due to an emergency occurring by a service outage.

RFCs are logged by the Change Requestors.

Change Requestor

ST 2.4.1

Assign a Change Owner

The Change Coordinator assigns the Emergency change to the Change Owner.

Change Coordinator

ST 2.4.2

Assess the RFC

The Change Owner receives the RFC and assesses it to determine whether it is valid. It is recategorized as Normal if it does not qualify as Emergency Change. Risk and Impact Analysis is done at this stage.

Change Owner

ST 2.4.3

Convene ECAB

The Change Owner convenes Emergency Change Advisory Board (ECAB) members to authorize the change. The E-CAB members are authorized to make decisions about high impact emergency changes.

Change Owner

ST 2.4.4

Approve Emergency Change

ECAB reviews the Emergency Change and assesses its urgency, impact, and risk. Based on their review the ECAB members either approve or deny the change.

Emergency CAB (ECAB)

ST 2.4.5

Emergency Change Approved?

If ECAB approves, the change is implemented.

Else the change is denied by the Change Approver and re-categorized as a Normal Change.

Emergency CAB (ECAB)

ST 2.4.6

Plan and Design Solution

The Change Owner plans the resources required, designs the solution to implement Emergency Change.

Change Owner

ST 2.4.7

Build and Test Required?

If Build and Test is required, Change Owner performs the building and testing activities by creating change tasks at this phase of the change.

If build and test is not required the change is scheduled for implementation.

Change Owner

ST 2.4.8

Coordinate Emergency Change Build and Test

The Change Owner coordinates the Build and Test activities for Emergency Change.

Change Owner

ST 2.4.9

Schedule Emergency Change

The Change Owner reviews, revises and updates the schedule as needed for Emergency Change.

 

Change Owner

ST 2.4.10

Coordinate Emergency Change Implementation

The Change Owner coordinates the activities for implementing the Emergency Change. Successful change implementation is followed by update of the CMDB and formal turnover to support.

Change Owner

ST 2.4.11

Abandon the Change

If an Emergency change is denied by the ECAB, the RFC is abandoned. Go to 2.5 to close the change.

Change Owner

ST 2.5

Review and Close Change

The Change Owner reviews the change implemented and closes if it is successful. Unsuccessful change is backed out and the emergency RFC is closed after PIR (Post Implementation Review). Change tasks are created to roll back the change and to bring the environment to agreed stable state.

Change Owner