Normal Change (process ST 2.3)

Normal Change is a change that is categorized, prioritized, planned and that follows all approvals before deployment. The Normal Change activities describe the steps necessary to process a Normal Change by coordinating work effort. A Normal Change can be further categorized as Major, Significant, and Minor. All Major, Significant, and Minor changes go through the same workflow except that, for a Normal Major RFC or a Normal Significant RFC the Build Authorization phase is a manual transition and the change has to be approved manually by Change Advisory Board (CAB) members. In a Normal Minor RFC the Build Authorization phase is auto approved. The Build Authorization phase is optional in a Minor RFC but it is still configured in the out-of-box system. The Change must be appropriately reviewed, approved, and executed successfully through the Normal Change process at least once prior to acceptance.

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

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

Normal Change process

Process ID

Procedure or Decision

Description

Role

ST 2.1

Register RFC

RFCs are logged by the Change Requestors. All RFCs are reviewed for completeness and accuracy.

Change Coordinator

ST 2.3.1

Assess Change

Assessing a change includes determining the risk and impact and identifying if the change requires a release to be generated. If a release is required, a Release and Deployment Manager is identified.

Change Owner

ST 2.3.2

Is a Release Required?

The Change Owner determines whether a release is required to implement the change.

Change Owner

ST 2.3.3

Determine Approval Requirements

The Change Manager reviews the change and decides whether a TCAB needs to be convened.

Change Manager

ST 2.3.4

Build Authorization Needed?

If Build Authorization is not needed, the Change Manager determines whether the change should be approved or rejected.

If Build Authorization is needed, members are identified and change is submitted for approval.

Change Manager

ST 2.3.5

Build Authorization

Change Manager works with CAB and approves the Change.

CAB

ST 2.3.6

Review RFC

The Change Owner reviews the RFC for approvals.

Change Owner

ST 2.3.7

Approval Received?

Upon approvals, build and test is performed either by Release and Deployment process or Change Management process.

If unapproved, the RFC is closed.

Change Owner

ST 2.3.8

Coordinate Build and Test

The Change Owner initiates the Release and Deployment Management process to perform build and test. The Service Validation Testing process is involved in validating and testing the build created by release.

In case the build and test is unsuccessful, it is recommended to abandon the change to RDM which in turn is informed to the Change Owner.

The Change Owner coordinates between the experts within Change process for building and testing activities. The change is built and tested thoroughly and validated.

Change Owner

ST 2.3.9

Build and Test Result Acceptable?

If the Build and Test result is acceptable, deployment is scheduled; else the RFC is sent for closure.

Change Owner

ST 2.3.10

Schedule for Normal Change

Change Owner involves the RDM and prepares the schedule for normal change. This schedule is based on the draft deployment plan obtained from the Release and Deployment Management process received.

Change Owner

ST 2.3.11

Release Related?

If release is related, the detailed deployment plan is created by the RDM process; else, Change Owner creates the same.

Change Owner

ST 2.3.12

Create and Submit Deployment Plan

The Change Owner creates the Deployment plan and submits it to CAB approval. The same is also received from RDM and is sent for CAB’s review.

Change Owner

ST 2.3.13

Deployment Authorization

CAB reviews the Build and Test results and approves / abandons / rejects as deemed fit. If the Build and Test results are approved, CAB reviews and updates the implementation schedule and authorizes the Normal Change implementation to commence.

CAB

ST 2.3.14

Rejected?

If the deployment plan is rejected, the change moves back to Build and Test.

CAB

ST 2.3.15

Decision on Rebuild

If CAB decides on rebuilding, the change is rebuilt and tested again.

CAB

ST 2.3.16

Rebuild?

If a rebuild is required, the Change Owner is informed; else, the change is deployed.

CAB

ST 2.3.17

Review RFC after Rebuild Decision

The Change Owner reviews the RFC to check whether the rebuild will be performed by RDM or within change. Also a decision is made on what modules to be rebuilt and the timeline.

Change Owner

ST 2.3.18

Release Related?

If the rebuild is related to RDM, the request is sent to RDM for rebuilding and testing; if not, these are performed within the Change Management process.

Change Owner

ST 2.3.19

Review RFC after Deployment Authorization

The Change Owner reviews the RFC to go ahead with the deployment.

Change Owner

ST 2.3.20

Release Related?

If RDM is involved for deployment, RDM carries out the deployment activities;

else it is carried out by the Change Management.

Change Owner

ST 2.3.21

Coordinate and Monitor Change Implementation

The Change Owner coordinates and monitors the Normal Change implementation. Various tasks are created for carrying out the deployment activities as mentioned in the deployment plan.

After the deployment, the Change owner verifies whether the deployment was successful or not.

Change Owner

ST 2.3.22

Remediation Required?

If the change is unsuccessful it is backed out and moved to closure; else CMDB is updated for successful changes.

Change Owner

ST 2.3.23

Provide CMDB Updates

Change Owner generates CMDB updates that are to be submitted to Service Asset and Configuration Management for processing.

Change Owner

ST 2.3.24

Determine if implemented RFC Is a Release

If the implemented change involves a release, control is returned to Release and Deployment Management for further review and closure.

Change Owner

ST 2.3.25

Implemented RFC for a Release?

If the RFC was for a release, the post-deployment activities will take place in the Release and Deployment Management process; else move on to PIR.

Change Owner

ST 2.3.26

Assess Change Success

The Change Manager determines whether the change implementation is successful.

Change Manager

ST 2.3.27

Remediation Required?

If a release needs to be backed out, this is done in the Release and Deployment Management process.

Change Manager