Skip to content

Change Management Process

The Change management process is designed to ensure that modifications to our environment are properly evaluated, approved, implemented, and documented. This process follows a structured process to ensure changes are effective, safe, and managed. Along with being best practice change management is required by certain accreditations such as ISO 20000/27001 and Cyber Essentials.

This document will lay out the steps in this process.

Summary

  • Change Request Creation: Create the change record in Zammad.
  • Peer Review (Optional): Ask a colleague to review your change request to confirm that the required information is accurate.
  • Approval: Obtain formal authorisation for the change.
  • Implementation: Implement the change as planned.
  • Review and Validation: Ensure the change is successful.
  • Closure: Update and close the change request.
  • Documentation Create documentation on the Isambard Admin Guide.

Change Request Creation

Change requests are to be raised in Zammad tagged with Change Management at least 3 days prior to the change taking place. The needed contents are documented in the Creating Change Requests. High quality changes are easier to manage and are much more likely to be approved.

Peer Review (Optional)

After or during change request creation consider asking a colleague to review your change request and document who did the review. This is particularly valuable for complex changes, changes which are going to cause significant disruption or have a higher risk of causing disruption.

Approval

Once your change request has been created you need to seek approval for your change. To do this please contact the Chair and/or Deputy of the Change Management Board. Changes which do not cause disruption or at a low risk of causing disruption can be approved without needing to wait for the next Change Management Board meeting.

Unless an exception is in place all changes which fall in to the following categories must be brought to the next Change Management Board meeting:

  • Changes which will or are highly likely to cause disruption to the user community.
  • Changes which are unlikely to cause disruption to the user community, but if they do could cause serious disruption beyond the end of the planned change window.
  • Changes which could cause disruption to the user community significantly beyond the end of the planned change window.
  • Changes where the impact is not well defined or unknown.
  • Changes with scheduled period longer than 8 hours.
  • Changes which occur outside of normal working hours.
  • Changes which must occur alone with no other changes implemented at the same time.
  • Changes which may cause damage to hardware.
  • Changes which may cause harm to people.

If you are unsure please ask the Chair or Deputy of the Change Management Board.

Implementation

Implement the change as described in the change request. Minor deviations from the implementation plan is acceptable. Read the Change Completion page for more details on what happens when there is a significant deviation.

Review and Validation

Ensure the change is successful using the test plan. Minor deviations from the test plan is acceptable. Read the Change Completion page for more details on what happens when there is a significant deviation.

Closure

Once a change is completed the change ticket should be tagged with Change Successful, Change Successful with Issues or Change Unsuccessful and the ticket closed in Zammad.

Follow the Change Completion process to record the completion of the change and any next steps that need to be performed.

Documentation

It is likely that your change will result in something which needs to be documented. Either for the user community or for other members of the team. Creating documentation on the process following will also help when raising future changes. Create documentation where it is appropriate. For the users it is on docs.isambard.ac.uk and for other members of the team it will be the Team Guide or, more likely, the Admin Guide.