IT Technical Change Management (also known as “change control”* in the ITIL framework) is the practice 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 practice applies to all Normal, Emergency, Expedited, 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 the risk of changes requested. The CAB is typically moderated by the WashU IT Technical Change Management practice owner or a delegate. View the IT Change Management CAB Roster.
- Emergency Change Advisory Board (eCAB) – Representatives from each WashU IT functional area responsible for reviewing all emergency changes. One representative from each of the functional areas must review and approve the change within 24 hours. View the Emergency Change Advisory Board (eCAB) Process (PDF) to see the eCAB roster.
- Customer – Business owner of service(s) impacted by change
- Service Owner – WashU IT staff accountable for overall health of the service
Normal and Expedited Change Process
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)
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.
Note: Emergency changes are not presented at the weekly CAB meeting.
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
Canceled: Change is canceled
Changes may have two outcomes from the change review meeting.
- 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 a new schedule.
- 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.
- Note:
- A Single CAB member’s rejection will halt the change
- Denied by CAB may be overridden by an Executive Director or the CIO
- Note:
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 one week prior to the change.
Changes will begin at the assigned time and follow a change schedule. After the change is implemented, testing will begin.
RFC Completion Status
The Change Requester must update the RFC in ServiceNow to close it out. Changes can have two statuses.
- Successful
- 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.
Emergency Change Process
Emergency Changes must follow these steps:
- Requestor must use the ServiceNow change request form to submit emergency RFC.
- eCAB members will receive a ServiceNow approval request email. A representative from each of the WashU IT functional areas must approve the RFC within 24 hours.
- Note: Approval is not required for implementation to occur.
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 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
High priority change required to restore service or prevent an imminent disruption in service (break/fix only).
High priority changes that are required quickly due to a pressing need such as customer requirements, a missed CAB deadline, or a vendor requirement but are not related to restoring service.
Forms and Documentation
Charter
Communications
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 Practice Owner or for the CAB? Email us.