This article is for non-iSolutions staff and explains:

• How to raise a Request For Change (RFC)
• The different types of RFC
• How an RFC is structured 
• How to find an RFC

These guidelines are designed for business teams who have frequent Changes for systems managed by a third party.

For further information around what a RFC is and who is involved in the process, please refer to the article "Request For Change (RFC) Process - Introduction for non-iSolutions staff".

How to raise an RFC

Using Copy RFC

For routine Changes the simplest way to raise an RFC is to copy a previous RFC and make any necessary changes.

Select the Copy RFC button to open a new Change Request. Guidance on locating previous RFCs can be found in the Find an RFC section below.

 

Raising a new RFC

1. Log in to ServiceNow

2. Go to the All menu and enter New Change in the search bar

Different types of RFC will be listed in the menu and are detailed in the section below.

---

Back to the top

 

Types of Change

There are several Change types that can be selected when raising an RFC. For raising third party Changes these will mostly be Minor Normal Changes, occasionally Minor Emergency Changes and rarely anything else.

• Minor Normal Change - Low to moderate impact and low to moderate risk, affects a single Service with no interaction or dependency on other Services. If an outage is required, it would not exceed an hour. Verified by the Change Manager who may decide to reclassify as Normal RFC if  deemed necessary. Must be scheduled for implementation with a minimum of 2 working days’ notice.
• Minor Emergency - A Change that is minor in nature that is required to resolve an issue that is service impacting or to prevent imminent impact to a system or service.
• Normal Change - A Change that is complex, medium or high/very high risk and/or high/very impact and/or involving multiple services or dependencies and with any outages in excess of 1 hour.
• Standard Change - A Change that is routine, regular, very low risk, very low impact, has been done before, and will do again
• Emergency - A Change that is significant in nature that is required to resolve an issue that is service impacting or to prevent imminent impact to a system or service.

---

Back to the top

 

Find an RFC

You can access existing RFCs in several ways:

Outlook calendar

ServiceNow will generate an Outlook meeting for the Change window, this contains a link to the RFC  

Email

Emails requesting approval will contain links to the RFC  

Search in ServiceNow

Each RFC has a unique reference in the format CHG0xxxxxx . This will appear on all emails relating to the Change. This can be entered in the ServiceNow global search field  (at the top right of the ServiceNow window)

 

The RFC Form

This section provides guidance on what information is required in the RFC.

The guidance for the Planning section of the RFC can also be seen in the text boxes when a new RFC is created (that is, from the All menu and select New Change).

 

Details section

This section takes the details of the Change using options selected from drop downs or lists.

Details section at the top of the RFC looks like:

Affected System or Service

Start typing the name of the service the Change is related to and select from the presented options or use the magnifying glass icon and select from the list. The name must be a selection from the list and cannot be free form.

Environment

• The development environment (Dev) – a separate environment where new software is written, or Changes are made where the impact is unknown.
• The preproduction environment (PreProd) – this should be as close to the Live environment as possible. Changes made in Dev are tested here.
• The production environment (Prod or Live) – the environment that runs the application that the business uses. Only Changes that have been fully tested in their current form should be moved into Live.

Service Outage Duration

If the Change is being performed by a supplier, they should provide you with this information based on evidence such as how long the outage was on the previously tested environment (such as the preproduction outage informing the production outage). This is only the time that the service will be unavailable so, for example, if the Change will take two hours but will be available except for 30 minutes for a restart, enter 15 to 30 minutes.

Affected Users

Select an option to describe the scope of the Change from the list. The options are:

• None
• Individual
• Department
• Multiple Departments
• University Wide

This information can be used to prepare teams for the potential risk or to troubleshoot in the case of something unexpected going wrong.

Approvals

The approval process ensures that any potential issues with a Change are spotted before it goes ahead. The approvers are responsible for assessing the impact, risk and feasibility of the proposed Change.

If any of the approvals are missing, the Change should be rescheduled and a new RFC raised.

Approval request emails are generated and sent automatically to the approver(s) once the Request Approval button is selected.

Typology of approvers:

• Business Owner – The colleague outside of iSolutions responsible for the non-technical aspects of an application
• Service Owner – The iSolutions colleague responsible for the technical aspects of an application
• Technical/Peer Approver - Someone with some technical knowledge of what the Change involves
• User Group Representative (optional) - Outside of iSolutions, the person or group who actively uses the system or service and isdeemed to have sufficient expertise on how the system or service should normally function

Planned Start Date / Planned End Date

This should be the total time for the Change; work should not take place outside of these times, either before or after. The times can be adjusted with good reason but record this in the notes.

1. Select the calendar icon at the right of the box
2. Select the date and enter the time (in the boxes at the bottom)
3. Select the green tick when finished

Short Description

This should be in the format "system" "environment" - "few word summary". For example, Blackbaud CRM Prod - Apply Service Pack 35.

Using this format makes it much easier to find that Change later if needed.

 

Planning Section

This section contains more detailed sections about the specifics of the Change.

How the Planning section looks like:

Communications Plan

In this section list what is happening in the Change, who will be affected and what the effect will be. This should be a broad description rather than going into technical detail.

You must also select whether the communications manager has been contacted.

Business Case

The business case should be written in plain English, with links to projects or plans if required.

Describe the Change, from a technical point of view explaining:

• Why this Change is required
• Whether it contains urgent bug fixes
• What actions will be undertaken
• What risks there are and any mitigations that are in place
• What is the impact to users/service if the Change is NOT performed

Service Impact Post-Change

Detail the impact to the Service post-implementation, assuming the implementation is SUCCESSFUL:

• Consider changes to the user experience.
• Will working practices or methods change?
• What documentation has been provided?
• Has ServiceLine been provided with updated information?

There is also a drop-down box to quantify this as:

• No impact
• Minor
• Significant
• Major.

Resources and Contacts

In this section list all the resources (University of Southampton staff) and contacts (from suppliers and other third parties) and some contact information such as an email.

UAT Completed?

This refers to the pre-implementation testing, with options for:

• Yes
• In progress
• N/A.

Test Plan

Pre-Implementation Testing

(Supply as attached Word document if appropriate)

What has been done to ascertain that the Change is likely to succeed when implemented.

In the best case this will be details of how the testing was performed and what the results were but as this level of information may be difficult to get from a third party, the most important part is confirming testing has taken place with whatever detail is available.

If no UAT or other Pre-Implementation testing was carried out, then state the reason why.

Post-implementation Testing

(Supply as attached Word document if appropriate)

How is testing going to take place once the Change is performed? Again, this should cover as much detail as possible but the important part is that a supplier has a testing plan.

Backout Plan

(Supply as attached Word document if appropriate)

As with the testing plan, this should cover as much detail as can be provided by the supplier but the most important part is that the supplier has a plan to backout the Change if something were to go wrong.

---

Back to the top

 

After Submitting

Notes

Notes can be either Public or Work Notes. A Public Note will email the person who raised the RFC, while Work Notes can be read only by staff in the tenancy. As an example, iSolutions staff will be able to see any work notes published in tickets assigned to iSolution, but will not be able to see the working notes published in a ticket assigned to other tenancies - such as HR or Finance.

These should be used to note any additional information relating to the Change not listed in the original form, such as a minor Change to the listed implementation plan or Change window.

Approvers

Once the form is submitted and approval has been requested, the Approval section at the top of the form should show Requested.

Once all the approvers have approved the Change, this should change to Approved.

   
If you need to check on the status of individual approvers, scroll down below the Notes section and you can see the status of the individual approvers.

If an approver has requested additional information, you can click on the Status link to see any notes they have added regarding this.

Change Tasks

Change tasks can be created when work needs to be carried out by others as well as the requestor.

1. Open the Change Request to which the additional task(s) is to be added
2. Navigate to the Change Tasks related list
3. Select New
4. Complete the following fields:
   • Configuration item
   • Assigned to
   • Due date (if necessary)
   • Short description and a more detailed Description of the task to be performed
5. Once the Change has been implemented, successfully or otherwise, the Task must be  updated and then closed using the  Close task button

Rejected Change Request

A rejected Change Request is closed using the Closed Rejected option.
Once the issues causing rejection are resolved, the Copy RFC button on the original Change can be used to resubmit the change.

---

Back to the top

 

Close Change Request

To close a Change Request:

1. Add appropriate text to the Public Notes field

2. Set the State field to the appropriate Closed option

3. Select Update

The options for closing a Change are:

• Closed Complete - Everything was successful, if there were any significant changes from the plan, a note should be added.
• Closed Cancelled - The Change could not go ahead according to the original plan or at the original time. Add a note about why and raise a new RFC with updated details.
• Closed Backed Out - Rarely used for third party Changes. The Change was started but then reverted. Add a note about why and raise a new RFC with updated details.
• Closed Failed - Rarely used for third party Changes. The Change was attempted but could not go ahead. Add a note about why and raise a new RFC with updated details.
• Closed Rejected - One of the approvers has objections to the RFC plan or timing. Where possible this can be avoided by discussing the plan before raising the RFC. The person rejecting approval should add a note explaining why. Once the issue is resolved a new RFC should be raised.

---

Back to the top

 

Related content

Request For Change (RFC) Process - Introduction for non-iSolutions staff