Change Management Overview


Purpose

Change is the addition, modification, or removal of anything that could have a direct or indirect effect on services. The primary purpose of a Change Management process is to implement beneficial production changes while lowering risk and minimizing any disruption to business operations, thus ensuring the best possible levels of service quality and availability are maintained. In addition, communicating changes to potentially impacted units across campus is essential for success. 

The long-term goal is for all IT changes across the University to be logged in ServiceNow. Today, the following technical units are participating in the central Change Management process (i.e., utilizing ServiceNow for technical change requests):

 

System of Record

ServiceNow is the system of record (SoR) for the creation and cataloging of technical changes, as well as configuration items and services. It also provides the technical framework and workflows. In addition, ServiceNow provides the platform for weekly CAB meetings, as well as the document repository for change management knowledge base (KB) articles. 

 

Change Advisory Board (CAB)

The purpose of the CAB is to evaluate normal change requests scheduled for implementation and approve/reject each request. Evaluations consider:

CAB Membership and Meeting

 

CAB Membership

The following campus units are current CAB participants:

 

Change Management Definitions

Standard Change

A Standard Change is a low-risk, pre-authorized change that is well-understood, fully documented, and can be implemented without needing additional authorization.

  • Low impact and low risk (which is always well understood)
  • Repeatable and well-documented process with a high degree of success
  • Relatively common
  • Frequent occurring
  • Authority granted in advance (Pre-Approved by Change Manager/CAB)
  • Does not directly alter user/business data

Examples

  • “Standard” Banner GZAMIGR requests
  • Server patching or similar activity that is performed throughout the year
  • OS updates
  • Firewall changes coordinated with the system owner and will not create an interruption in service
  • DNS Changes

Escalation to a Normal Change Request

  • If a standard change template has a documented history of 2 failed implementations with any associated impacts, such as system or application outages, it will be referred to CAB and subject to elevation to a Normal change request.

Required Notification / Approvals

  • Auto Approved

Required Documentation

  • Change Requests must be submitted through ServiceNow using a Standard Change Template
Standard Change Request Documentation

Emergency Change

A high-priority change requires the bypassing of the normal change process in order to mitigate a production issue in the shortest possible time. Emergency changes fall within one of the following categories:

  • Fix on fail or retroactive situations where the impact to service has already been experienced.
  • Fix or fail situations where the impact to service is imminent if action is not taken.

Examples

  • Hot fix from vendors
  • Firewall changes in response to an attack
  • Response to exposure to critical system vulnerability
  • Restore system/service crash

Required Notification / Approvals

  • The requestor's manager or director required

Required Documentation

  • Change request in ServiceNow
  • Thorough information (in the change requests) that sufficiently explains the need and nature of the emergency change
Emergency Change Request Documentation

Normal Change

A Normal Change is a change that is not an emergency change or a standard change. Normal changes follow the defined steps of the change management process.

  • Change Window: Weekdays 5:30 pm to 7:45 am
  • Not auto-approved
  • Cannot be created after the event
  • Must go through the CAB
  • Requested and CAB-reviewed with enough lead time, depending on the risk level

Examples

  • Oracle DB Upgrade
  • Banner Upgrade
  • Critical application upgrades, such as DegreeWorks
  • Network hardware changes
  • Large-scale changes or upgrades to various telecom systems
Normal Change Request Documentation


Change Implementation Schedule/Validation Period

When scheduling the anticipated start and end times for a change (in particular, a Normal change), this period should cover not only implementing the change but also the time needed to complete all necessary validations. This way, if a change needs to be backed out, the appropriate Close Code can be selected. If a person closes a change prior to validations being completed and an issues arise, they will be unable to make adjustments in ServiceNow.

Example Scenario: A change is scheduled from 8 am Sunday morning to 8 pm Sunday evening. This period is deemed needed to implement the change and have various teams conduct smoke checks, validations, etc. If, at 6 pm, issues are detected, the POC can then back out the change and select “Unsuccessful” as the Close Code.

 

Lead Times

Change Type Required Lead Time
Standard No lead time is necessary
Emergency No lead time is necessary
Normal 

1 week from CAB approval

Note: Lead times are based on calendar days, not business days

Risk Calculation

A critical component of managing changes in ServiceNow is the calculation of risk. The risk level is directly correlated to lead time. Several factors are used to evaluate risk. Some factors may affect only the specific change type.

Standard Changes

Risk is calculated during template creation. Currently, the number of users will help calculate the risk for standard changes.

Emergency and Normal Changes

Risk is calculated when the user clicks the "Calculate Risk" button after saving the initial record (see training documentation). The risk calculation elements for these changes include: