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:
- Office of Information Technology (OIT)
- Alumni Affairs and Development
- Office of Student Affairs
- Office of the Provost
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:
- Technical conflicts, including overlapping changes
- Social conflicts, including important University calendar events
- Risk assessment
- Likelihood of success
CAB Membership and Meeting
- The CAB meets each Wednesday from 2:00 PM to 2:45 PM
- Each OIT and non-OIT team/unit should send a primary or secondary representative to CAB, regardless if their area has a change request to present
- Technical representation for submitted change requests should be available for questions
Change Management Definitions
Standard Change
A Standard Change is a low-risk, pre-authorized change that is well understood and fully documented, and which 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
- 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
Required Documentation
- Change Requests must be submitted through ServiceNow using a Standard Change Template
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
- System breach by hackers
- Firewall changes in response to an attack
- Response to exposure of 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
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
- SharePoint Server Upgrade
- Network hardware changes
- Large-scale changes or upgrades to various telecom systems
Lead Times
| Change Type |
Required Lead Time |
| Standard |
No lead time is necessary |
| Emergency |
No lead time is necessary |
| Normal |
- Low and Moderate risk changes - 1 week (subject to change as the process matures)
- High and Very-High risk changes - 1 week (subject to change as the process matures)
|
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 direct correlation to lead time. There are several factors that 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:
- Number of users impacted
- Business Criticality of both the Service and the Configuration Item (CI)
- Maintenance window
- Lead time