- Information Technology Solutions
- Mission, Vision & Values
- Partner Directory
- Academic Technology
- Duplicating Services
- Virtual Computing
- news
- Software available to current Students, Faculty and Staff
- Internet Access Resources
- Processes & Policies
- Artificial Intelligence Guidelines
- AI MEETING ASSISTANTS
- Zoom Session Recording & Privacy Considerations
Change Management
The goal of Change Management is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of change related problems upon the service quality.
General Guidelines
- Do not make changes during normal business hours (8:00am – 6:00pm M‐F)
- Change implementer must be present the day after a change is implemented
- Notify clients 1 or more weeks in advance for Critical and High Risk changes
Terminology & Roles
Change Management is responsible for controlling change to all devices within the live production environment. It is not currently responsible for change within test and development environments.
Type | Description |
---|---|
Change Requester | Individual or department submitting a Request For Change (RFC). This individual can be either a customer or IT representative, but requests must be approved by an ITS MPP prior to submission to the CRB/CAB. |
Change Review Board (CRB) | Team responsible for reviewing all low and medium risk Request For Change (RFC). This team consists of a cross‐functional team of members with process and technical expertise. |
Change Advisory Board (CAB) | Team responsible for approving all high and critical risk Request For Change (RFC). This team currently includes the ITS Deputy CIO and several other ITS managers. |
Emergency Change | Requires immediate implementation to correct a disruption or outage of service. |
Impact | A measure of the effect of a Change on business processes or services. Impact is often based on how service levels will be affected. Impact can be measured by the number of people affected or the criticality of the system |
Risk | A measure of the vulnerability of each service affected by the change. |
Standard Change | A pre‐approved change that is relatively common, follows an established procedure, and is the accepted solution to a specific requirement or set of requirements. The CAB determines which changes can be defined as a Standard Change. Standard Changes still require an Request For Change (RFC) that is approved by the appropriate MPP. |
Normal Change | Any change that is not categorized as an emergency or standard change. |
Urgency | A measure of how long it will be until a Change has a significant impact on the Business. Urgency reflects how quickly a change must be implemented, or the time available to reduce the impact of the change on the business. |
Risk Assessment and Levels
Each Request for Change (RFC) is assigned a Risk Level, general description, required advanced notice to the approver:
Level | Type | Description | Notice | Approver |
---|---|---|---|---|
4 | Low | Low impact and low probability and Pre‐approved Standard Change (or candidate for standard change) | 1+ week | ITS MPP |
3 | Medium | Change is related to a single application or service and side‐effects can be safely excluded | 1+ week | CRB |
2 | High | Change affects several applications or services; or a large number of users | 2+ weeks | CAB* |
1 | Critical | Change affects a major part of the business‐critical infrastructure | 2+ weeks | CAB* |
*CRB sends recommendation to CAB
When assessing the Change, consider the following to determine the Risk Level:
Factors
- Number of clients affected
- Duration and scope of the service disruption
- Availability of a work‐around
- The criticality of the services being disrupted
- Awareness of the impact to the university
Considerations
- Does the change have to be done during normal business hours?
- Possible impact if the change fails?
- Does the change involve a router or switch?
- Does the change involve a major system?
- Can the change be easily rolled back?
Qualitative Risk Scores are determined by considering the proposed changes’ probability and impact. Probability describes the likelihood that the risk will occur, while impact considers the scope of the risk.