This article explains what changes and Requests For Change (RFC) are within the university informatics systems.

The article also gives an overview of:

• The request process
• The information required
• The types of change 
• The approval process

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

The article will cover everything that could be involved in this process. In most cases, RFCs are expected to be routine and have low impact.

Overview of Changes and Request For Change (RFC)

Definition of Change

A Change is an alteration to a University of Southampton system that could:

• Cause an outage
• Alter the way the system looks, acts, or interacts with other systems.

Definition of Request For Change (RFC)

You can request a change through the Request For Change (RFC) form. By raising an RFC you will:

• Provide documentation that all risks and mitigations have been considered.
• Allow other teams to see what is happening in the case of an unexpected issue.
• Allow other teams to plan their own activities so as not to interfere with the change.
• Create a reference for supporting services such as communications and pausing monitoring.

Third-party applications 

There might be applications implemented by third-party providers without the involvement of iSolutions.

If you need changes to those applications, you need to

1. Contact the team(s) that have the relationship with the provider
2. Ask the team(s) to raise the RFC on your behalf.

---

Back to the top

 

People and teams involved into the process 

RFC Requestor / Initiator - The person asking for the Change to happen.

Change Implementer - The supplier.

Approvers- Assess the change for impact and soundness:

• Service Owner – The iSolutions colleague responsible for the technical aspects of an application
• Business Owner – The colleague outside of iSolutions responsible for the non-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 are deemed to have sufficient expertise on how the system or service should normally function.

Change Manager - Manages the Change Management process and runs the Change Advisory Board (CAB).

Change Advisory Board (CAB) - Weekly meeting to consider RFCs and approve or reject as appropriate.

---

Back to the top

 

Information required in a Request For Change

Before ANY Change is made, an RFC must be submitted with the following information:

• What the Change is 
• Why it’s necessary (Business case)
• What communication is required?
• When you would like to have it done
• How the change will affect users during and after the implementation
• Explanation of the testing already performed
  • In case you cannot test a proposed Change, please explain why you are not able
• How it will be implemented - please add as much detail as can easily be provided
• How you will determine that the Change was successful - this is called "post-implementation testing"
• A backout plan - please explain what the supplier will do if something goes wrong.

---

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

• This Change has low to moderate impact and low to moderate risk. It affects a single Service with no interaction or dependency on other Services.
• If an outage is required, it would not exceed an hour.
• This Change is verified by the Change Manager who may decide to reclassify as Normal RFC, if the deemed necessary.
  • If reclassified, the Change must be scheduled for implementation with a minimum of 2 working days’ notice.

Minor Emergency Change

A Change that is minor in nature and is required to:

• Resolve an issue that is service impacting,
  or
• To prevent imminent impact to a system or service.

---

Back to the top

 

Workflow of a regular Minor Normal Change 

The following workflow shows what happens for Changes that are done on a regular basis and are classified as routine. 

Since you are requesting a routine Change, you can raise a new RFC following this simplified process:

1. Copy the previous RFC
2. Make the (small) amendments you need
3. Be sure that your amendments cover the specifics needed for this case
4. Raise your new RFC

Workflow

Description

1. You agree with the cloud service provider a routine change that needs to be made to the system
2.  Now:
   1. Copy a previous RFC
   2. Update the details to reflect the new change
3. Save and submit the new RFC
4. The system generates a request approval
5. The request can be approved, rejected, or might need clarifications:
   • If approved, proceed to point 6
   • If rejected, your ticket gets closed. Make any necessary changes to address concerns, and start again the process from point 2
   • More information needed: if you can satisfy the requester's concerns, they can grant the approval and proceed to point 6
     The approver can also set the approval to Request Additional Information if they are not sure about something which can then be approved.
6.  Decide whether you need a SUSSED announcement or other kind communications. If you need them, contact the Service Owner 
7. The provider performs the Change
8. Post-implementation testing 
9. The Change goes live and the RFC is closed

Please note: any actions taken or updates from the supplier should be recorded in the 'notes' section on the Change.

 ---

Back to the top

 

Approval process

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:

• If the approver is temporarily unavailable, the Change should be rescheduled
  or
• If a new approver is required, a new RFC should be raised

Step 1

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

Approvers can re-assign an approval to another person by overwriting their name in the Approver field of the Approval Request form.

Step 2

By selecting the Change request link within the approval request (for example "Change Request: CH G0071971", as in the picture above), the approver can open the Approval window:

Step 3

The Approver can add a comment and then Approve or Reject the request

Step 4

A Change request approved email is generated and sent to requestor.

If an approver becomes unavoidably unavailable, contact the Service Owner to discuss changing approvers.

---

Back to the top

 

Unexpected scenarios

The Change Window Needs to be Moved

The Change Window can be moved at any point prior to the Change.

Ideally there should be a firm plan in place before the RFC is submitted, but if there is a good reason to push the Change back this can be done by amending the Planned Start and End dates.

If moving the date forward, ensure there is sufficient time for approval (48 hours for Minor Normal Changes, after the next Tuesday and at least 48 hours for Normal Changes).

Make a note on the ticket about the reason and contact the approvers to make sure they are aware (in case the new date clashes with something you were not aware of).

The Approvers Need to be Changed

Before approval has been requested, the approvers can easily be changed by replacing the names on the RFC.

Once approval has been requested, you will need to contact the Service Owner to request the approvers be amended.

Staff should ensure they set up a delegate in ServiceNow to minimise scenarios where they are added as an approver and are absent (there will be cases of unexpected leave on occasions though).

---

Back to the top

 

Related content

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

How to set up a delegate in ServiceNow