IT Technical Change Management (also known as “change management”* in the ITIL framework) is the process responsible for controlling the lifecycle of all changes with minimum disruption to IT services. IT Technical Change Management systems and procedures are implemented to ensure that WashU IT policies and approvals are met before system changes are implemented. Done correctly, IT Technical Change Management integrates seamlessly into the overarching risk management program and can decrease approval times for critical changes.

*Organizational Change Management (also called “change management”) is the process, tools and techniques used to manage the people side of change to achieve required business outcomes.

Purpose: The purpose of IT Technical Change Management is to prevent unintended consequences and ensure that changes or alterations to systems are implemented according to an approved framework or model.

Scope: The IT Technical Change Management process applies to all Normal, Emergency and Standard changes scheduled to all WashU IT supported systems, services, networks, servers and applications.

Roles & Responsibilities

  • Change Requester – IT person requesting the change; must attend change meeting or send delegate to discuss the change.
  • Change Implementer – IT person that will actually perform the change
  • Change Tester(s) – Business and IT personnel scheduled to test success of change
  • Change Advisory Board (CAB) – Representatives from each WashU IT functional area responsible for assessing risk of changes requested. The CAB is typically moderated by the WashU IT Technical Change Management process owner or a delegate. You can find the CAB roster in the WashU IT Change Management Charter here.
  • Customer – Business owner of service(s) impacted by change
  • Service Owner – WashU IT staff accountable for overall health of the service

Normal Change Process

Submit a Request for Change (RFC)

All changes will be entered via the Change Management Form in ServiceNow.  These requests will be referred to as Requests for Change (RFCs).  The form allows the change request to describe the change, the impact of the change, a roll-back or remediation plan, the risk of the change, and if high risk, what will be done to mitigate the risk.

The following items must be provided when submitting the RFC:

  • The system that the change will be performed upon (via CI or short description field)
  • Risk of Change
  • Complex changes need to provide drawings or process flows of the environment (via attachment)
  • Date of Change (via schedule section of form)
  • Outage Window (via schedule section of form, note this should include time from beginning of change to completion, including any time that might be required for rollback, not just the time the system is down)
  • Availability Impact (Actual time down  via the Requires Downtime field)
  • Customer Impact (via customer impact and notification section of form, note must include department and number of customers impacted)
  • Change Steps, Test Plans, Back-out Process (via Change, Backout and Test Plan section of form)
  • Who will implement the change (via Implementation Assigned to field in Schedule section of form)
Change Submission Deadline

The CAB meets each Wednesday at 10 a.m. to review upcoming changes. Changes scheduled for any given week must be presented at or before the previous week’s CAB meeting.

RFC Statuses

Changes have the following statuses:

New: New request for change (RFC) is entered – approval is requested

Assess: Initial Change Approval step

Authorize: Change Advisory Board (CAB) approval

Scheduled: Approved by CAB and awaiting implementation

Review: End change in Service Management System when change has completed

Closed: Change is complete and all closure information has been documented

Cancelled: Change is cancelled

CAB Review Outcomes

Changes may have 2 outcomes from the change review meeting.

  1. Approved – Change is approved, which will result in an RFC status of Scheduled in ServiceNow, and the change can proceed. Requires 100% CAB approval.  Some changes may conflict with other changes, in such instances CAB will approve after identifying new schedule.
  2. Denied – Change is rejected, which will result in the change going back to the initial State of New, where the requestor may update or change whatever is necessary based on CAB recommendations. Reasons may include not enough information, no representation at change meeting and or risk too high to proceed.
    1. Note – A Single CAB member’s rejection will halt the change.
    2. Note – Denied by CAB may be overridden by an Executive Director or the CIO
Change Communication

The OCM Communications team, or someone they designate as the change communicator, will distribute notifications of changes to all affected business owners and affected customers after the change meeting. Communications must be sent to customers at least 1 week prior to the change.

Change Implementation

Changes will begin at the assigned time and follow a change schedule. After the change is implemented, testing will begin.

RFC Closure

RFC Completion Status

The Change Requester must update the RFC in ServiceNow to close it out.  Changes can have 3 statuses.

  1. Successful
  2. Successful with Issues
  3. Unsuccessful/Rollback

Updating Activity Resumption Plan

The Change Requestor must update any disaster recovery plans that require modification based on the change.

Update Process Documentation

The Change Requestor must update existing process documentation that require modification based on the change.

RFC Completed with Issues Documentation

Changes that are closed with a completion status of “Completed with Issues” will need to complete a “RFC completed with issues” document to identify the adverse events that occurred and their resolution.

Emergency Change Process

Emergency Changes must follow these steps:

  1. Requestor must use the ServiceNow change request form to submit emergency RFC.
  2. Director-level supervisor must approve the emergency change.
  3. The change must still come to CAB at the first available CAB meeting after the change is implemented.

Types of Changes


Pre-authorized, low risk, low impact changes that follow documented, repeatable procedures. Standard changes are not reviewed by the CAB, but can only be made using a pre-approved template. Examples of these tasks include but are not limited to: virus updates/signature files, adding tapes to tape library, and deploying new computers for a department.

Normal Changes

Normal changes are those that do not fall under the Standard change or emergency change categories and will encompass the majority of changes reviewed by the CAB. All changes in this category will be presented to the CAB, and require CAB—and where appropriate—business unit approval. Normal changes include recurring changes, which are those that follow a predictable schedule, and project changes, which are subcomponents of a larger change. Examples include:

Corrective Changes – Changes required to correct a problem that currently exists and is impacting service availability

Continued Service Changes – Changes required to keep system up to date or respond to an alert

Add/Remove Changes – Changes required to add or remove systems or services to/from the environment

Enhancements – Changes required to add or remove functionality of systems or services

Emergency Changes

Emergency changes typically involve a change needed to resolve a major incident.  to implement a security patch, or to enhance a service where the CAB deadline was missed,. Emergency changes can be implemented outside the weekly CAB review process so long as the requestor completes the RFC form, receives Director-level approval for the change and finishes testing before implementing the change.

Forms and Documentation

Documentation of Standard Change Processes

CAB Meetings

Every Wednesday (unless otherwise noted), 10:00 a.m. – 12:00 p.m.

Contact Us

Have a question for the IT Technical Change Management Process Owner or for the CAB? Email us.