Process Overview

In the ITS Change Management Process, changes begin as an individual Request for Change (RFC). RFCs then progress through the states of the Change Request Lifecycle. Each state in the lifecycle represents a unique phase and groups together related tasks with specific tasks requiring completion before progressing to the next state. The process supports four types of changes: Standard, Normal, Expedited, and Emergency.

As and RFC proceeds through the lifecycle, depending on the change type, some states may be skipped. An RFC may be canceled at any point prior to implementation.

 Refer to Terms & Definitions for a glossary of terms used.

Back to Top

1. Create the Change Request

In the Create state, the Change Requester starts an RFC and populates it with information such as the risk assessment value (RAV), proposed maintenance window, and implementation and backout plans.

• To create a Normal, Expedited, or Emergency change, from the ServiceNow fulfiller interface, select All,search for "change", select Create New, then select Models to view and select the appropriate change type.

ℹ For more information about change types, see KB0018316

• To create a Standard change, from the ServiceNow fulfiller interface, select All, search for "change", select Create New, then select Preapproved to view and select the appropriate preapproved standard change template.

ℹ For instructions on creating a Standard change Template Proposal, see KB0019654

2. Complete the Change Request Form

Once the RFC has been created, the Change Requester will be required to fill in several fields, indicated below by a red asterisk ✳, before the request can be saved.  A green flag ⚑ indicates a field that is included in the weekly change report.

Header

• ⚑ ✳ Configuration Item (CI)

The configuration item represents the service the change requested will be performed against. Either start typing a service name or select the magnifying glass icon to the right of the Configuration Item Field to choose. Examples: "Active Directory", "Office 365", and "Residence Hall Network (Resnet)". If there is more than one CI in the list with the same service name, please select the "Business Service".

• ⚑ ✳ Short Description

The short description should contain a brief, customer-friendly non-technical explanation of the change(s) planned. The short description should include the action being taken and what is being affected. Examples: "Oracle Production Exadata  Quarterly Patching", " VSP -06/05/2024 - Building Router Replacement - HSM", and "UDC-C - UPS-B2 - Post flood repairs".

• Assignment Group

The assignment group represents the ServiceNow group that is responsible to implementing the change, once it is approved and should, in most cases, auto-populate based on the CI chosen once all the required fields are completed and the change is submitted. If that does not occur, the submitter should click on the magnifying glass icon to the right of the Assignment Group field to select the correct one and then contact the ServiceNow team to populate the correct assignment group for the CI.

• Risk

The risk value will auto-populate the change is submitted based on the answers chosen for the Risk and Impact Analysis. It will always default to "-- None --" .

Planning

The planning tab includes the reason for the change, the work to be done, the risk of the change, what to do if the change is unsuccessful, and what has been done to test the change beforehand.

• ✳ Justification: A detailed information explaining why change is being requested and reason it is needed.
• ✳ Implementation plan: A detailed plan on how the change will be implemented. The submitter may include a link to documentation where this detail is stored and can be viewed, if desired.
• ⚑ ✳ Risk and Impact Analysis: A customer-friendly description of the expected risk and impact a proposed change may have on the IT service.
• ✳ Backout Plan: The steps required to restore a system to its original or earlier state in the event of a unsuccessful or aborted implementation
• ✳ Test Plan: The steps to test change end-to-end prior to implementation in production.
• ✳ Communication Plan:  An outline of notifications to customers and campus (if required) that will be sent prior to implementation. Notifications are expected to follow ITS Change Management Process Standards and Guidelines, Section 8.2 Change Communication and utilize the ITS Email and Campus Communications Template.
• ⚑ ✳ Maintenance Type: Select the type of effect the maintenance will have for customers.
  • Disruptive implies the maintenance will make the service unavailable or noticeably degrade the service for the customer. Choosing disruptive will display the event on both the IT Maintenance Calendar and ITS Alerts and Outage page.
  • Non-disruptive implies the maintenance will be transparent to customer and will only display the event on the IT Maintenance Calendar.

Schedule

The schedule tab includes when the implementation of the change is planned to start and end.

• ⚑ ✳ Planned start date and time: The planned implementation start date and time.
• ⚑ ✳ Planned end date and time: The planned implementation end date and time.

Risk Assessment

ℹ Although the RAV questions are not required in the form, ITS requires they be completed before completed before submitting an RFC.

The Risk Assessment tab is used to assess the potential risk and impact of the change through a series of questions. Answers to these questions determine the risk assessment value (RAV) of the RFC and the level of approvals required.

• Security Sensitive: Selecting security sensitive will prevent the RFC from being published to the maintenance calendar or to alerts and outages and should only be used with direction from leadership.
• End Users Impacted: May enter how many end users will be impacted.
• ITIL Users Impacted: May enter how ITIL Users will be impacted
• See KB0018388 for explanations of the RAV calculation questions and answers below:
  • ✳ Outage Scope and Complexity
  • ✳ Location and Customers Impacted
  • ✳ Business Impact
  • ✳ Back-out Rollback Plan
  • ✳ Experience With Change
• CAB Required:  Selecting CAB required will ensure that the RFC is routed to the Change Advisory Board (CAB) for review and authorization, even if the calculated RAV does not require it.

Notes

The Notes tab is used to provide additional information about the RFC

• Watch list: Users added will be notified of any comments are added to the RFC.
• Work notes list: Users added will be notified when any work notes are added to the RFC.
• Additional comments (customer visible): Used for communication with the customer and anyone on the watch list.
• Work notes: Used for internal communication or anyone on the work notes list.

Once all required fields are complete, the RFC can be saved. The Change Requester selects the Request Approval button to move the RFC to the Assess state.

Back to Top

3. Assess the Change Request

ℹ The Assess state is skipped for Standard and Emergency changes.

In the Assess state, the Change Reviewer, a member of the RFC Assignment Group / technical peer, reviews the RFC to 1) verify that it is complete and technically sound and 2) either rejects or approves it. If the RFC is rejected, the reviewer should include their reasoning on the Notes tab so the requester can understand what adjustments are needed before resubmitting it.

• While multiple individuals may be listed as approvers (seen on the "Approvers" tab at the bottom of the RFC in ServiceNow), action by only one of the approvers is required to move the RFC forward. Approvers should receive an email requesting their approval, with a link to the RF to review, once the RFC enters the Assess state. The Change Requester can view the list of approvers in the "Approvers" tab at the bottom of the RFC in ServiceNow.
  
  
  

Once the Change Reviewer approves the RFC, it moves to the Authorize state.

 Back to Top

4. Authorize the Change Request

ℹ The Assess state is skipped for Standard and Emergency changes.

In the Authorize state, the Change Approver, the manager of the Assignment Group for the RFC and usually the service owner, performs an initial review of the RFC and either approves or rejects it.

• If the RFC is rejected, the approver should include their reasoning on the Notes tab so the requester can understand what adjustments are needed before resubmitting it.

Depending on its RAV and Change Type, the RFC may require an additional review and approval by CAB. See KB0018388 for additional detail on the risk level calculations and review levels.

• • If the RFC requires CAB Approval, it will be added to the CAB Dashboard. Each week, the CAB facilitators review any pending changes and contact the change requestor to schedule review for an upcoming CAB meeting.

Once the Change Approver approves the RFC, it moves to the Schedule state.

Back to Top

5. Schedule the Change

ℹ The Schedule state is skipped for Emergency changes.

In the Schedule state, is published to the Change Calendar and the Change Approver, or their delegate, sends out any required communication following the communication plan documented in step 2 of the RFC. For Standard, Normal, and Expedited Changes, the Change Implementer then waits until the designated Maintenance Window to execute the RFC’s implementation plan while for Emergency Changes, the Change Implementer does not wait to execute the change.

At the planned start date and time from the RFC, the Change Implementer selects the Implement button to move the RFC to the Implement state, and then begins the maintenance.

 Back to Top

6. Implement the Change

In the Implement state, the Change Implementer executes the change according to the RFC’s documented implementation plan. Once the change is complete, the Change Implementer documents any additional comments in the Notes tab and the outcome of the change on the Closure Information tab. 

• Close Code: Select one of the options to describe the outcome of the change:
  • Successful: The outcome of the change implementation plan was met with no unanticipated effects.
  • Successful with Issues: The outcome of change implementation plan was met with minor deviations such as:
    • extended time needed to complete the maintenance
    • additional steps or resources (not in the implementation plan) needed to successfully complete the change
  • Unsuccessful: The outcome of change implementation plan was NOT met resulting in the a the backout plan being implemented or the change cancelled. Select one of the options to describe why the change was unsuccessful:
    • Technical Issue: An unforeseen issue results in the implementation plan being unable to be completed, as planned, within the maintenance window.
    • Human Error: A person's mistake results in the implementation plan being unable to be completed, as planned, within the maintenance window.
    • Change Cancelled: A change is unable to be implemented because of emerging circumstances, such as critical resources being suddenly unavailable within the maintenance window.
• Close Notes: Used to provide any additional context related to the close code chosen.
• PIR Required: Will be automatically checked (set to true) when the Unsuccessful close code is chosen. The Change Implementer should complete a Post Implementation Review (PIR).

Once the documentation is complete, the Change Implementer selects the Review button to move the RFC to the Review state.

Back to Top

7. Review the Change Request

In the Review state, the outcome of the change implementation is reviewed. Once all required reviews are complete, the RFC transitions to the Close state.

Back to Top