Change Request Lifecycle and Workflow

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. The states required vary by Change Type and specific tasks must be completed within a state before progressing to the next. The Cancel state is available for any RFCs needing to be canceled prior to implementation. 

Back to Top

Create: Creating a New Change

Create: Creating a New Change

In the Create state, the Change Requester creates an RFC and populates it with information such as the Risk Assessment Value (RAV), proposed maintenance window, and implementation and backout plans. 

For Standard Changes, the Change Requester creates an RFC from a pre-authorized active Standard Change Template. The template populates the RFC with pre-authorized information and allows the Change Requester to add any additional required information, such as the proposed maintenance window. Once all the required information has been added, the Change Requester submits the RFC, and it transitions directly to the Schedule state.

For Normal Changes, once the Change Requester submits the RFC, it transitions to the Assess state.

For Expedited Changes, once the Change Requester submits the RFC, it transitions to the Authorize state.

For Emergency Changes, the RFC is created after the incident is resolved to document the change. The Emergency RFC transitions directly to the Review state since the change has already been implemented.

• Create New: In the left-hand navigation panel select "Create New" Under Change 

• Type of Change:

Select from one of the following options shown below.

For more information about types of changes, review the knowledge base article KB0018316 - The Four Changes: Standard, Normal, Expedited, and Emergency

• Ticket Details:

Ticket details show you fields for a description of the change request, it's unique number, the requester, type, and state. This is also where you will assign the change an assignment group and configuration item.

For a detailed list of which assignment group owns a particular Change Management Configuration Item check out: KB0018293

The Risk field always starts at -none- but will auto generate depending on your answers to the risk assessment fields further on in the form. 

• Planning:

The planning fields are where the requester will detail the justifications for the requested change, how they will implement said change, a risk analysis, a back-out plan, and if there is any way to test the change before it goes into full production.

You can also control notifications to service owners and create a service portal outage from this tab.

1. • Justification: Detailed information explaining why change is being requested and reason it is needed.
   • Implementation plan: Detailed plan on how the change will be implemented.
   • Risk and Impact Analysis: A value that represents the expected risk and impact a proposed change may have on the IT service.
   • Back-out Plan: The steps required to restore a system to its original or earlier state in the event of a unsuccessful or aborted change implementation
   • Test Plan: The steps to test change before implementation into production.
   • Communication Plan:  The outline of customer notifications that will be sent prior to the implementation of a change, including the general message, method, frequency, and timing of the notifications.
   • Notify Dependent CI Owners: This will help notify service owners who may be dependent on this service.
   • Maintenance Type: Select between Disruptive and Non-Disruptive to determine what type of change will display on the ITS Maintenance Calendar. Selecting Disruptive will create an outage record and show on the ITS Alerts and Outage page.

• Schedule:

The Schedule contains all the information for when your change request will be implemented. These dates are provided by the change requester but can be changed by the request approver. If the change requires CAB approval, then the CAB delegate will also leave their name in the related field. 

These fields may be left blank if the Security Sensitive checkbox in Risk Assessment is checked.

1. • Requested by date and time: Optional field to select date from Requested By
   • Planned start date and time: Select the planned started date and time of Change Request
   • Planned end date and time: Select the planned end date and start time of Change Request
   • Actual start: Optional field to select the actual start date and time of when the change was implemented
   • Actual end: Optional field to select the actual end date and time of when the change was implemented
   • CAB delegate: Optional field to select CAB delegate from your team

• Risk Assessment:

The Risk Assessment fields are where you enter in the details on the magnitude of your change. Your answers to these questions will determine what the Risk field in ticket details will change to and the level of approvals your change will require.

1. • Security Sensitive: Checking Security Sensitive will make it so that a planned date is NOT required for that particular change. You may use this when you don't want to advertise when a change is happening.
   • End Users Impacted: Number of End Users impacted by change.
   • ITIL Users Impacted: Number of ITIL Users impacted by change.
   • Change Risk Assessment Value (RAV) Calculator: Risk level for a Change is calculated using the pre-defined Risk Assessment Value (RAV) Calculator. Change Risk Assessment Value (RAV) Calculator – KB018388
   • Outage Scope and Complexity: Select one of the following.

• • • Complete outage or high complexity. Coordinate many services, groups, or vendors.
    • Partial service outage/degradation or moderate complexity. Coordinate services, groups, or vendors.
    • Minor service outage/degradation or low complexity.
    • No service outage/degradation or redundancy available.
    • N/A – Not applicable

• Location and Customers Impacted: Select one of the following.

• • • Enterprise or >2500 customers
    • Region or 100 – 2499 customers
    • Multiple locations or 250 – 999 customers
    • Single location or 1 – 249 customers
    • N/A – Not applicable

• Business Impact: Select one of the following.

• • • Very high impact or visibility for campus. Will impact downstream systems.
    • High impact or visibility for affected customers. Likely to affect downstream systems.
    • Medium impact or visibility for affected customers. Not likely to affect downstream services.
    • Low impact or visibility for affected customers. Not likely to affect downstream services.
    • N/A – Not applicable

• • Back-out Rollback Plan: Select one of the following.

• • • Unable to back-out. Complete restore required. Additional downtime expected.
    • Difficult to back-out or not desired due to data & system dependencies.
    • Moderate difficulty to backout. Dependencies on data, system, or inadequate docs.
    • Routine backout. Adequate docs and similar past backout. Completes in maintenance window.
    • N/A – Not applicable

12.  
    • Experience With Change: Select one of the following.

• • • No experience with this type of change or unable to fully test the change. No similar prior changes.
    • Limited experience or success in making this type of change or unable to fully test the change.
    • Moderate experience with this type of change or the ability to partially test the change.
    • Extensive experience with this type of change or ability to fully test the change.
    • N/A – Not applicable

• • CAB Required:  Checking CAB Required box is a reportable field and it will ALSO add an extra step of authorization to the change request. If CAB Required is checked, then the CAB will need to approve the change request after the manager of the assignment group authorizes it.

• Notes:

The Notes fields will be familiar to anyone who's used ServiceNow for ticket handling before. Additional Comments are messages that will go out to watchlist members on the tickets, while work notes are for internal use. You can add as many users as you'd like into the watch list field for customer visible notes and add users to the work notes list for work notes updates.

• • Watch list: add interested users to watchlist to be notified of any changes or updates to the form.
  • Work notes list: add interested users to watchlist to be notified of any changes or updates to the form including the work notes field.
  • Additional comments (customer visible): Journaled field that is shared with the end user.
  • Work notes: internal notes communicating work being done through out the change process.

Once these fields are filled out, click Save. Review the form to make sure all information is filled out correctly. Once you have reviewed the form, click Request Approval to move to the Assess step of the change process.

Back to Top

Assess

In the Assess state, one or more Change Reviewers review the submitted RFC. If the RFC is complete and technically sound, the Change Reviewer(s) will approve the request and it proceeds to the Authorize state. For Standard, Expedited, and Emergency Changes, this state is skipped.  

Back to Top

Authorize

In the Authorize state, the Change Approver performs an initial review of the RFC and, depending on its RAV and Change Type, may refer it to CAB for additional review. If the RFC is rejected, the reasoning shall be provided in the RFC so that the Change Requester may amend and resubmit it. Once all the required authorizations have been granted, the RFC transitions to the Schedule state.

Back to Top

Schedule

In the Schedule state, the Change Approver, or their delegate, publishes the change to the Change Calendar in a new or previously published IT Maintenance Window and sends out any required communication according to the Change Communication Guidelines.

 Back to Top

Implement

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 the outcome of the change in the RFC, and it proceeds to the Review state.

Back to Top

Review

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