Service Release, Change and Retirement
Introduction
IT Services has an existing Change management process for considering non-standard changes,
authorised through a Change Advisory Board (CAB). This process has been operational for over
12 months and has been found to be useful for:




Increasing impact awareness;
Increasing risk awareness;
Avoiding scheduling conflicts;
Improving communication.
However experience of operating this process has identified aspects that could be clarified,
improved and enhanced including:




Awareness of forthcoming changes;
Consideration of service release and retirements;
Planning and visibility;
Documentation.
This document and associated checklists and flow chart increases the scope of the existing
change procedure to include service release and retirement and develops the procedure to
address the identified issues.
Change categorisation
For the purposes of this procedure changes should be categorised as one of the following.
1. Standard change
Standard Changes are those changes that follow a defined procedure, are regularly performed
and carry little or no risk. These are usually pre-authorised so they are just done, unless there is a
moratorium in effect.
An example being changing a student’s username is a Standard Change and would normally be
sent through to be done as soon as possible. However during the exam period it’s not sensible to
disrupt a student’s IT account so such changes usually wait until the end of the exam period when
any issues are not as disruptive.
2. Non-standard change
Non-Standard Changes are those which are not usual, regular or do not have a defined
procedure. They require much more thought about the solution, possibly development work and
co-ordination with various departments. These are not pre-authorised as the risks involved in
these require consideration. These changes may also involve system downtime and impact a
large number of users.
A non-standard change may be a system upgrade or hardware refresh/migration. Impact and
timing of the proposed change need to be considered and risk assessed.
3. New service or system launch
The launch of a new service or system is always considered a non-standard change and should
follow the non-standard change procedure set out below.
4. Service or system retirement
The decision to retire a service is not covered by this procedure. The non-standard change
procedure should be used when retiring a service or system. The relevant sections of checklists 1
and 2, particularly the required resources table, should be considered.
Control
The procedure uses control points to enable the timely review of changes to ensure that the
change is required and the right approach is being followed. Up to three control points are used
dependant on the scope and impact of the change.
Control point one (CP1)
This takes place after a requirement for a change has been identified. The purpose of this control
point is to determine whether the change appears to be needed and to take an initial view of its
viability. Once deemed viable and required, a decision is taken, based on scope and impact, to
either follow the standard change procedure, the non-standard change procedure or recommend
that the change go through the project sizing process. For low impact non-standard changes it
may not always be necessary to seek approval at CP2 and CP3, however, the change should still
be reviewed. These decisions will be made by a Team Leader.
Control point two (CP2)
This takes place once the high level planning for the change has been completed. The purpose of
the control point is to review the completed change plan (see Checklist 1) to determine whether
the high level planning needed to implement the change is appropriate and resources can be met.
The continued validity and viability of the change will also need to be reviewed. A decision will
then be made to continue with the change, refine or modify the plan, or stop the change. This
decision will normally be made at the weekly IT managers meeting and may involve input from the
service owner and other stakeholders.
Control point three (CP3)
This takes place once testing, documentation and planning has been successfully completed, the
schedule has been finalised, and the service owner or other responsible stakeholder has signed
off the proposal. The purpose of this control point is to ensure all the requirements needed to
release the change are in place (see Checklist 2). A decision will then be made to approve the
change, refine or modify the plans/documentation/schedule or stop the change. This decision will
be made at a Change Advisory Board (CAB) whose members will normally include IT Board
members, service owners and other relevant stakeholders.
Planning
Planning is essential for any change to services or systems. The type and level of detail required
will depend on the impact and scope of the proposed change. The following plans will normally be
necessary for any change or release and can be documented on the relevant template (see
Checklists 1 and 2):


Communication plan
Testing plan


Deployment plan
Back-out plan
Communication Plan
This details what needs to be said, when it needs to be said and to whom. Normally, ICT Service
Desk and ICT support will need to be informed of the change schedule along with any associated
known issues, workarounds and escalation procedures. Customer Services may need to be
informed to publicise any scheduled downtime, update service status information and update
online resources. Service owners will need to be informed of the proposed change at an early
stage and may be involved in the planning process; they will also highlight any additional
communication requirements.
Testing plan
This details what testing should be undertaken, the pass/fail criteria and who will perform the tests.
Where possible a change should be thoroughly tested before implementation. If this is not
possible testing must be completed before releasing to live and the back-out plan implemented if
testing fails. Functionality testing should be undertaken by the service owner or expert user who
has detailed knowledge of the service or system. If any pilots are required they should be detailed
here. The back-out plan must be tested.
Deployment plan
This details the steps required to carry out the change and release to live, who will carry out the
various activities and when they should take place. The plan should include the technical steps
needed and an assessment of the required service downtime. Any high risk activities should be
highlighted along with proposed steps to mitigate the risk. For particularly risky activities it may be
appropriate to include a number of options for the CAB to consider.
Back-out plan
This details the steps required to return the system or service to its original configuration (i.e.
before any steps in the deployment plan have been undertaken). The plan should include who will
carry out the steps and an assessment of how long they will take. It will be necessary to
implement this plan if any of the steps detailed in the deployment plan fail or if testing following
implementation does not meet the pass criteria. It may be appropriate to include a number of
options to address differing failure scenarios.
Documentation requirements
Most changes will require some form of documentation. The type and detail of the documentation
will depend on the scope and impact of the change. Changes to existing services or systems may
require the updating of existing documentation. The following types of documentation will need to
be considered:




User guides
Service Catalogue entries
Operations manuals
 Start / stop information
 Log file location
 Entry points (including ports)
Service desk guides
Changes will not be signed off for implementation until all the documentation requirements have
been met.
Procedure
The procedure should be followed with reference to the flowchart and checklists 1 and 2.
1. A need to change a service or system is identified.

An RMS job may already exist. If not, one should be created.
2. If the change can be easily categorised as a standard change then the usual procedure for
enacting that change should be followed. If the decision is not obvious then the relevant
Team Leader should be consulted (see CP1).
3. Team Leader should choose between one of the following routes based on the scope and
impact of the proposed change:




Standard change procedure followed.
Non-standard change procedure followed with light touch authorisation. The procedure
and checklists to be tailored by the Team Leader according to need.
Full non-standard change procedure followed.
Change to enter the project sizing process.
The following steps assume the full non-standard change procedure is being followed. This can
only be modified by a Team Leader for use with low impact non-standard changes.
4. The planning requirements of the change should be undertaken, documentation
requirements should be assessed and checklist 1 should be completed for submission to
CP2. Items to consider include:










The scope and content of the change should be documented.
Risk assessment for the change should be completed.
Impact assessment should be completed.
The stakeholders affected by the change should be identified, in particular the service
owner.
Outline communication plan should be completed.
The roles and responsibilities of the staff or externals who will be responsible for the key
activities should be identified.
The resources needed to implement the change should be identified.
 Clarify any licensing information.
 Assess documentation requirements.
 service catalogue changes.
 Assess any training requirements.
 Assess any hardware requirements.
 Assess any desktop application deployment requirements.
The deployment or retirement strategy should be determined (e.g. big bang, phased,
pull, automated, manual etc).
The build and test plan should be completed.
An estimated timeline should be determined.
5. The completed checklist 1 should be considered at CP2 which is likely to be the weekly
managers meeting.
6. The build and test plans should be enacted and the results of testing noted
7. The various activities required to test and prepare the change for release should be
undertaken and checklist 2 should be completed for review at CP3. Activities to include:

Build test environment.







Complete testing as per test plan and document results.
Complete documentation.
Prepare deployment plan.
 Determine any additional resource requirements.
 Assess early life support requirements.
Prepare back-out plan.
Agree final release schedule.
Obtain signoff from service owner and relevant stakeholders.
Finalise communication plan.
8. Completed checklist 2 should be considered by the CAB (CP3) which is likely to be the IT
Board.
9. Communication and deployment plans should be enacted.
10. Testing of the implemented service or system should be undertaken, and the back-out plan
enacted if testing fails to meet the pass criteria.
Obvious
standard
change
Change identified
CP1
Standard
Change type.
NOT REQUIRED
change
Required and
OR NOT VIABLE
Project
sizing
viable?
NO
STOP
Complete
Checklist 1.
Write Plans
CP2
Plans
OK?
NOT REQUIRED
OR NOT VIABLE
STOP
NO
YES
Prepare for change and
complete testing
Complete
Checklist 2
CAB
FURTHER WORK
Testing
NOT REQUIRED
completed
OR NOT VIABLE
successfully
STOP
CHANGE APPROVED
Implement change