Technology Change Management Process
INTRODUCTION
Change Management is a process used to ensure that changes to our Technology Services are carried out in a controlled manner, with relevant approval, visibility and risk mitigation.
By following the Change Management process, we:
- Minimize risk.
- Ensure appropriate rollback plans are in place.
- Highlight scheduling clashes.
- Ensure that changes are made after the consideration of likely impacts including those to BAU, security and our SLAs.
The change process helps us to make changes that are designed to have a positive impact on the Rugby Football Union with the minimum of disruption to the services that we provide.
DEFINTION OF CHANGE
A change is considered to be anything that affects a Technology Service via addition, modification, or removal. The effect on the service could be a change to its function. It could also have a potential or actual impact on the availability of a service.
Additionally, the change process can be used to gain approval and visibility of activities carried out by Rugby Football Union.
The change process must be followed to ensure our legal and regulatory obligations have been adhered to, including audit purposes.
CHANGE TYPES
Standard – Must use one of the Standard Change templates pre-approved by CAB. Can be submitted anytime. Can be approved at any time.
Major – This may include the major releases of software on the production. Needs to be submitted by EOD Thursday for review Friday, for potential approval at CAB Monday morning
Emergency – Only to be used when there is a time-sensitive need to fix, or prevent, an interruption to a business-critical service
ROLES & RESPONSBILITIES
Role
Responsibility
Process Owner:
Dan Hart
- Ensure process is used by all of Rugby Football Union Technology.
- Promote process
- Maintain and update process
Change Managers:
Daniella Moses, Dan Hart
- Provide advice on Change Management
- Assess changes for suitability
- Carry out Post Implementation Reviews
Change Owner:
Varies
- Raise Change Request
- Assign change tasks
- Close change tasks
- Record outcome of change
CAB Members:
Daniella Moses, Chris Shire, Lucy Butt, Dan Hart, Paul Harvey, Simon Jones
- Representatives from all 5 areas of the Dept: Service, Projects, Infrastructure, Applications, and Architecture
- Change Requester and Business Users may also be required
- Review and approve changes
- Review the change schedule and provide information to help
- Identify conflicts or resource issues
- Review projected service outages
- Review unauthorized and failed changes
- Reviewing proposed Standard Change templates/models
Implementers:
Varies
- Carry out assigned change tasks
- Record outcome of tasks
CHANGE ACTIVITIES
Logging a Change Request
All changes must be logged in SCRUM as Change Requests, and not undertaken until the CR is approved. The Change Request form has several mandatory fields which must be completed to submit the change.
Key points on the change form that need to be completed include:
- Description – Summary of why this change needs to raised, and what it entails, including reference to any related incidents or requests in SCRUM
- Associate – Link any incidents, problems, assets, or project references to the change form
- Downtime – Will there be any interruption to service(s) while this change is implemented?
- Business Approval – An email attachment must be added to the change request form if this is a major change with an Outage.
-
Planning – Ensure any documentation is updated which could include the following:
- Reason for Change
- Implementation Plan
- Rollback Plan
- Testing Plan
- Documentation
Where possible, all changes should be linked to the Incident or Request that precipitated it, and the Asset affected by the change.
Further help on how to log a Change Request can be found here
Assessing Change
All changes other than Standard Changes will be reviewed by the Change Manager before they progress to the CAB meeting for approval. The function of the assessment stage is to ensure the change has been submitted correctly, and the supporting information is correct.
Once assessment has taken place, the change will be sent to the Change Advisory Board (CAB) group.
Emergency Changes require approval from the Head of Service Delivery before Approval. The Change Manager will then arrange an ECAB for review, which may if required take place via Teams or email
Standard Changes must use pre-approved templates which require one member of the Change Advisory Board to approve in SCRUM before moving to implementation.
Approving Change
The CAB approves all changes. Standard Changes are sent to all members of the CAB, and Emergency changes are approved by an expanded CAB that includes the Change Owner.
All Major Changes that involve the introduction of a new service must be accompanied by a completed Service Transition Form. Change Requests without this will be Rejected and need to be resubmitted.
From time to time, a Change Manager may need to override an approval (due to absence or unavailability).
Approval should be based on the suitability of:
- The Change Window
- Risk
- Impact to Services (including security, data and SLA considerations)
- Testing Plan
- Rollback Plan
- The business Sign Off
- Implementation Plan
- Documentation Plan
For a Standard Change, when an approver believes they have enough information to make a decision, it can be either Approved or Rejected by them.
For a Major Change, the CAB must be in agreement that the change can be approved and the Change Manager will approve.
A rejection will include details of why, and what remedial action can/should be taken to ensure a resubmission gains approval.
Implementing Change
Changes can only be implemented once the change has been approved and only at the planned implementation date and time. The work that is carried out must follow the documented change plan, including any pre and post change checks.
Closing Change
Once a change has been implemented, the outcome of the work must be recorded. The Change Outcome field must be completed with the following:
- Successful – The change completed as per the change plan and testing showed the aim of the change was achieved.
- Failed – The change was implemented but the aim of the change was not met.
- Rollback – The change was rolled back as per the rollback plan.
- Withdrawn – The change request was not carried out.
Post Implementation Review
Changes with risk calculated by SCRUM to be higher will be escalated to the change manager group once the change has been completed. If the change was not carried out successfully, or it caused an incident or outage, a member of the change manager group will review the change to identify any areas for improvement or lessons learnt. When this task is complete, it will be closed.
Major Change Request
Major Changes are raised for releasing changes in most circumstances. These are changes that would go to the Change Advisory Board and must be submitted by 5:00pm Thursday each week, for discussion at CAB the following Monday. This allows time for these to be reviewed by the Change Manager for any issues that might otherwise prevent them being approved at CAB on the Monday.
Change notifications will contain details such as:
- Change ID
- Change Subject
- Change Dates
- Change Agent
The request is logged in SCRUM. Please check the change calendar to ensure no conflicts on changes or affected services or configuration items which could have work already scheduled at the same time.
The risk of the change will define the next step. Each approval group should assess changes as per the guidelines to decide if it should be approved. Once the change has been approved, an email notification is sent to the change owner, and the Implementation can take place during the planned implementation time. Once implemented, the change should be closed.
Standard Change Request
Standard changes are raised where the work being carried out:
-
Has an authorised template that is to be followed
- The change must not deviate from the template
- Template must be approved at a CAB
- Carries little or no risk
- Is a routine and well documented task
- Has a documented implementation and backout plan
- Has minimal data or information security risk
Standard changes do not have a lead time requirement; however, they must still be approved before taking place. The level of approval required is reduced compared to Major and Emergency changes
The request is logged in SCRUM. Please check the change calendar to ensure no conflicts on changes or affected services or configuration items which could have work already scheduled at the same time.
This will show work being carried out on the same CIs, or implementers already scheduled to be carrying out work at the same time.
All Standard changes are deemed to be low risk and follow an approved template. This means they bypass the Change Managers group. CAB members assess and approve or reject the change.
Once the change has been approved, an email notification is sent to the change owner, and the implementation can take place during the planned implementation time. Once implemented, the change should be closed. Because standard changes are for low-risk routine work, a post implementation review is not required as part of the usual process.
Emergency Change Request
Emergency Changes are used when there is an urgent requirement to carry out essential work sooner than the Major change lead time allows. Emergency Changes should only be used under the following circumstances:
- To resolve a P1 incident
- When a service is likely to fail imminently without the change
- There is a risk to Rugby Football Union if the change is not carried out imminently
- With agreement from a Change Manager & Head of Service Delivery.
It is important we plan changes to avoid the use of Emergency Changes unnecessarily. Emergency Changes should not be raised to bypass the need to provide a lead time in the event of poor planning.
To help mitigate the risk of carrying out Emergency changes, an additional level of approval is required from the Head of Service Delivery.
Emergency changes can be logged retrospectively only when submitting prior to the work would cause an unacceptable delay to restoring service, or the work is of a sensitive nature and cannot be advertised prior to it taking place. There should always be agreement from a Change Manager.
The request is logged in SCRUM. Please check the change calendar to ensure no conflicts on changes or affected services or configuration items which could have work already scheduled at the same time. This will show work being carried out on the same CIs, or implementers already scheduled to be carrying out work at the same time.
The change will be passed to the Head of Service Delivery for approval. Once approved, it is then passed to the CAB group for assessment to ensure the change is valid and requires no further information. Each approval level group should assess changes as per the guidelines to decide if it should be approved.
Once the change has been approved, an email notification is sent to the change owner, and the Implementation can take place during the planned implementation time. Once implemented, the change should be closed. For emergency changes, the change will be passed back to the CAB group to decide if any post-implementation review is required.
SERVICE PROTECTION WINDOW
Blackout windows or change freezes can also be known as a service protection window. These are added to the change calendar when no changes should be deployed, or certain specific type of changes should not be deployed. When agents try to schedule a change within this window, the SCRUM system should prompt and will warn that about this and advise to raise this at an alternative time and date. This is to help provide service stability during a time where there may be limited resources or business critical periods.
If a change request needs to be raised during a service protection window, then this would need to follow the emergency change request process.
CHANGE TEMPLATE
New Standard Change templates can be requested via email to the IT Service Operations Manager. The request will be discussed and assessed for suitability to ensure it:
- Carries little or no risk
- Is a routine and well documented task
- Has a documented implementation and backout plan
- Has minimal or no PCI or information security risk
Once agreed it will be created in SCRUM by the requester. It will then be reviewed and checked in the CAB meeting. Approval will be required from each representative. This will then be communicated to the Technology Department.
RELEASE MANAGEMENT
When we are releasing a completely new service, releasing a large deployment or decommissioning a large-scale service we should use Release Management in conjunction with Change Management. It is important to make sure that all the aspects of the Change, technical and nontechnical, are considered before it is rolled out.
RELEASE ACTIVITIES
Logging a Release
All Releases must be logged in SCRUM as Release, and not undertaken until the Release is approved. A release can have multiple changes Associated to the Release and each change can move through the process independently. Every Change which is required to complete the Release should be associated to the Release.
The Release should be created and managed by Delivery Manager and/or the Change Manager
Assessing and Approving a Release
The release should be assessed 2/3 weeks prior to the expected Go Live, it should include a Go Live, Cut over plan with clear detail on all changes required and documented. The plan should be attached or referenced in the Release.
The Release should be reviewed at a Release Review meeting, managed by Delivery Manager and Change Manager. It should be attended by CAB members, any technical experts required and the delivery leads. It should act as a go/no go for the production of a service.
If applicable a Release Manager should help to navigate multiple releases if required, if there is no release manager the Change Manager must ensure that multiple releases are not impacted.
Implementing Release
Releases can only be implemented once all relevant changes have been approved and successfully implemented. The work that is carried out must follow the documented plan, including any pre and post Release checks.
Closing Release
Once a Release has been implemented, the outcome of the work must be recorded. The Release Outcome field must be completed with the following:
- Successful – The change completed as per the change plan and testing showed the aim of the change was achieved.
- Failed – The change was implemented but the aim of the change was not met.
- Rollback – The change was rolled back as per the rollback plan.
- Withdrawn – The change request was not carried out.
This document can also be found here