Change Management Process

What is a Change?

A Change is defined as adding, removing or updating a component within an existing software or data, production and UAT environment.  All Changes must comply with the Change Management process and be recorded and tracked with a corresponding “Change Record” (CR).

What is Change Management?

Change Management is responsible for controlling the “System Development Life Cycle” (SDLC) of all changes.

  • The purposeof the Change Management process is to ensure that changes to information technology, applications, and databases must be controlled using appropriate change management procedures.
  • The goals of Change Management are to:
    • Respond to customer’s changing requirements with minimal disruption while maximizing value
    • Evaluate and respond to requests for change that will align <<Company’s>> services with client needs
  • The objectiveof the Change Management process is to ensure that changes are recorded and then evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner.

Policy Statement 

The policy of <<company>> should be to manage the production environment, UAT environment, supporting its business and technical objectives. As such, the processes and procedures for Change Management set forth in this policy and subordinate procedures define the expectations and methods for governing change and release management activities within the production environments.

Documentation supporting a production change must contain a minimum of:

  • A Change Request entry detailing change information
  • Appropriate testing
  • Approval by the <<Company’s>> “Change Advisory Board” (CAB)
    • Change Advisory Board (CAB)ensures that all proposed changes are reviewed and approved.  Prior to releasing a change to the production environment, the change must be approved by an appropriate member of the CAB.
  • Change monitoring

Note: Non-production (development and/or test) environments are exempt from the expectations contained in this policy (and subordinate procedures).

Upon completion of the change, it is expected that the affected applications and/or systems be validated and monitored for a brief period to ensure that the change expectations were met and that there is no additional risk introduced to the production environment.

Change Categories

SN   Categories Description
1 Normal A standard change is a change that is approved by the CAB using normal change management processes. Standard changes need to be scheduled as per planned maintenance windows.
2 Urgent/Exceptions  Urgent changes are changes that are scheduled outside of planned maintenance windows. The change must be implemented as soon as possible in a controlled context of evaluation, testing and authorization. Urgent changes should follow the normal approval process.
3 Emergency Changes intended to repair an error in an IT and/or application service that is impacting the business to a high degree or to protect the organization from a threat. Emergency change may be scheduled outside of maintenance windows but must follow the emergency change procedure.

Emergency Infrastructure changes should be driven by Sev1/Sev2 incidents only. For Application changes, emergency change may arise from ‘Blocker’ or ‘Critical’ incidents.

Change Management Procedures

Normal (Planned) Changes

  1. Change Initiation: A Request for Change (RFC) is entered in the form of a Change Request ticket through <<Any tool like Jira/Rally>> containing the following minimum information:
    1. Brief description of the change requested with business reason.
    2. Time frame for implementation of the change
    3. Impact of the change
    4. Risks of implementing the change (if any)
    5. Change implementation plan (including FSC if required)
    6. Test Plan
    7. Backout Plan
  2. Change Review:  All RFCs must be reviewed by and approved by the Change Advisory Board (CAB) before implementation. Additionally, if an impacted CI has an owner assigned to it, the CI owner must also approve the change before implementation. The CAB can reject a change or request additional information regarding the change.
  3. Change Implementation: Approved changes are implemented and tested as planned. Task assignments related to the change will be tracked in <<Any tool like Jira/Rally>>
  4. Change Log: Change log will be maintained in <<Any tool like Jira/Rally>>

Urgent Changes (Exceptions)

Urgent/Exception changes apply to changes that have a shorter turnaround time than Normal/Planned changes. They follow the same process as Normal changes above with the exception that Exception Type and Exception Justification needs to be provided before the change request can be submitted or approved.

Emergency Changes 

  1. Change Initiation: Emergency Changes must follow the same Change initiation process as Normal Changes.
  2. Change Review: Approval for Emergency Changes can be obtained verbally from a CAB member. Emergency Changes do not require CI owner approval.
  3. Change Implementation: Approved changes are implemented and tested as planned. Task assignments related to the change will be tracked in <<Any tool like Jira/Rally>>

Regular Maintenance Windows

All efforts must be made to schedule changes during regular maintenance windows as below:

  1. Weekdays <<Time>> to <<Time>>(Only Low Risk Changes)
  2. Weekends between <<Time>> and <<Time>>(Only Low Risk Changes)
  3. Patch Deployment: Weekdays <<Time>>

Post Implementation Tasks

  1. Any subsequent incidents arising due to a Change implementation must be linked back to the originating Change Request.

Responsibilities

Change Advisory Board (CAB): A CAB consisting of two or more senior members of the team, who will be responsible for reviewing and approving changes. A CAB member can open a change request but cannot approve any request they have opened by themselves.

CAB MEMBERS

  1. (Primary Approver)
  2. (Emergency/Urgent changes during Nepal hours)