IT Change Management Policy
Document Type
Policy
Document owner
Graeme Cappi, Director of IT Services
Approved by
Management Board
Approval date
13 January 2021
Review date
January 2022
Version
1.0
Amendments
-
Related Policies & Procedures
N/A
1. SCOPE
1.1 LSHTM wide. ALL changes, new services, enhancements or amendments to ANY system
or service which LSHTM manages, including cloud services must go through the Change
Procedure
2. PURPOSE AND OVERVIEW
2.1 In order to maintain integrity, security and availability of IT systems at LSHTM there needs
to be a robust and mandatory Change Management policy in place to control the required
amendments, enhancements and changes to existing systems and services, as well as the
introduction of new services
2.2 This policy sets out the process and procedure for this IT Service Change Management
requirement.
3. POLICY
3.1 Introduction
This policy aims to set out the way that LSHTM IT Services manages changes that occur on our
technology platforms, systems and services (in-house and off-site) in a way that is designed to
minimise the risk and impact to LSHTM, by ensuring that changes are reasonably controlled.
3.2 Definition of a Change
LSHTM IT Services defines a change as anything that alters, modifies or transforms the operating
environment or standard operating procedures of any systems or services that has the potential to
affect the stability and reliability of in infrastructure or disrupt the business of LSHTM.
Changes may be required for many reasons, including, but not limited to:
• User requests
• Vendor recommended/required changes
• Changes in regulations
• Hardware and/or software upgrades
• Hardware or software failures
• Changes or modifications to the infrastructure
• Environmental changes (electrical, air conditioning, data centre, etc)
• Unforeseen events
• Periodic Maintenance
3.3 Policy Definition
It is the responsibility of IT Services to manage the lifecycle of all systems supporting LSHTM’s
business and technical objectives.
There are two categories of changes that are permitted. They can either be Pre-approved or
Change Advisory Board (CAB) approved and of these categories, there are four types:
Minor/Routine, Major/Significant, Emergency/Unscheduled and New Development
NO CAB-approved change should be implemented without:
• A request for change (RFC) being raised via the ServiceDesk (Topdesk)
• Approval by the Change Advisory Board
• An approved, documented plan of the sequence or steps for implementing and releasing
the change into the live environment.
• Evidence demonstrating the fact that this change has been tested in a pre-live/staging
environment first
• A rollback/mitigation plan in case of failure.
• A post-change test being documented to check that the change has been successfully
applied.
3.4 LSHTM ITS Change Management process
• All Changes to live services will be carried out under the jurisdiction of Change Management
Process. This includes both Operational and Project (newly introduced Service) Changes.
• Change Advisory Board (CAB) will meet every Wednesday at 2pm to review Normal
Changes. If attendance by a CAB Member is not possible, they should either review and
feedback comments before the CAB or nominate someone to step in to represent the absent
member of the CAB. ALL roles listed in Organisation Roles and Responsibilities in the
document are expected to attend CAB, or send a deputy.
*CAB may be a virtual or physical meeting depending on the risk/ impact of the Change due for review and the
numbers and is up to the discretion of the Change Manager who will advise the CAB of it.
• If the Change Requestor is not present at CAB then the change will not be discussed and
will not be approved
• RFCs must be submitted latest by end of Business on Monday for consideration at the
following CAB on a Wednesday.
• All changes will be submitted using the “Request for Change” form located in Self Service
Portal for CAB Review.
• Once an RFC is submitted to the CAB for review, all preliminary checks (Change Evaluation)
will be carried out by the Change Manager. This is to ensure that the RFC is ready for CAB
review as best as possible, to minimise any rejections and to keep the CAB process as
efficient as possible.
• If the CAB does not have sufficient information with regards to a Change, then the change
cannot be fully impact assessed/authorised and might be deferred or get a conditional
approval. The Change Manager will ensure that all the conditions set out by the CAB are
completed before the RFC is implemented.
• The “Go Live” of all new and upgraded services will be carried out under Change
Management jurisdiction. Whilst majority of such changes will be from the PMO, other
sources will sometimes be necessary.
• Only authorised Changes to Live systems are permitted and there is zero tolerance for
unauthorised Changes.
• When a Change requires a planned outage to a service, the Change Requestor/ Implementer
will need to consider using the agreed monthly planned maintenance slot for the first
Wednesday of a month (from 6pm) as the implementation date.
• Unauthorised Changes will be assessed, logged and evaluated for continuous improvement
purposes.
• Changes will not be communicated or implemented until approved by the CAB (or Change
Manager in Emergencies). Once the RFC is approved by the CAB, the Change Manager will
notify Communications and Engagement for action of the need to send communications.
• Only Changes approved by the CAB will be listed in the Change Calendar (FSC) in TOPdesk.
*The Change Calendar on TOPdesk is the LSHTM ITS Forward Schedule of Change and is to be used by the
Desk for awareness of schedule of Changes and for the CAB and Change participants to impact assess/ schedule
Changes. Knowledge Item: KI 1295.
• Emergency Changes should NOT be used for late/poorly planned change requests and
should be only used to urgently fix or avoid a Major Incident.
• Emergency changes have the same authorisation procedure as Normal Changes with the
only difference being that the Change Manager (or approved surrogate Change Manager i.e.
Team Leader) will authorise the Change in the absence of having the permanent members
of CAB authorise the Change. The Change Manager/Team Leader should consult members
of CAB and members of ITS SMT to will obtain approval before making a decision, but it is
recognised that this might not always happen due to time constraints in needing to apply the
fix.
• Communication regarding Emergency Changes should still happen, (where applicable) so
that customer expectations can be managed effectively around any unexpected downtime
and to avoid calls to the Helpdesk.
• Change Manager will investigate the patterns regarding the nature of Emergency changes to
ensure compliance with the guidelines for when to submit changes.
• Post implementation Reviews (PIRs) will be raised by the Change Manager following failed
changes to ensure lessons are learnt as part of continuous improvement. This will be
documented and published as an Action within the RFC on TOPdesk.
• All Changes on TOPdesk should be set to completed once implemented by selecting the
most appropriate closure status on the TOPdesk Change Form (from the Operator Window).
This data will be used to measure the effectiveness of the Change Management Process
(KPIs)
3.5 Organisational Roles and Responsibilities
This process is dependant on a number of roles being performed and responsibilities being
fulfilled.
The main roles to be noted are:
Role
Responsibility
Change Advisory Board
Responsible for reviewing, assessing impact and approving
changes.
Participants - Heads of Teams viz; Networks, Security, Systems,
Web Team and the Change Manager will attend either virtually or
in person, or delegate where unavailable.
Change Manager
Responsible for the management of Normal Changes affecting
Live Services.
Change Requestor
Responsible for raising/ submitting the RFC, building and
implementing the authorised change.
Technical Service
Manager
The ITS member of staff responsible for the delivery of the service
to the Business and approving the RFC.
Service Owner
Outside ITS, the person or a delegated representative, with
ultimate accountability for the provision of a Service to the
organisation and approving the RFC.
Project Manager
Responsible for the management of projects and the raising
of project related RFCs for submission to the appropriate
CAB.
ITS Services Manager
Responsible for advising and guiding the Change
Requestor on the most appropriate communications
strategy to be used for communicating the proposed
changes and its impact.
PMO IT Business Partner
Point of contact for advising Faculties and Professional
Services departments of proposed changes affecting their
areas.
3.6 Critical Success Factors
Deliver a structured/ planned approach to the transition of services from the current state to
desired state with minimal disruption to the customer.
To control all known business driven changes into a single rolling Change Programme.
Embed, understand and appropriately utilise the Change Management Process.
Agreed process and tool used for Normal Changes – integrated into the LSHTM SM Tool
Management support for process compliance and appropriate measures for process deviations.
Good project management practises to allow sufficient planning for Changes.
Making quick and accurate changes based on business priorities.
Protection of services when implementing changes.
Comprehensive impact analysis of proposed change (*This is restricted to an extent by the lack of
no CMDB in LSHTM ITS and relies on the SME’s knowledge)
Fewer outages due to unauthorised changes.
Greater customer satisfaction.
3.7 Key Performance Indicators
Number of changes implemented in the reporting period broken down of changes by
system/service
Increase in the number of successful Changes
Reduction in the number of failed, backed out or cancelled Changes
Reduction in the number of Major Incidents (outages) resulting from Changes
Reduction in the number of incidents resulting from Changes
Reduction in the number of unauthorised Changes
Reduction in the number of unplanned Changes/ emergency Changes
Number of Changes rejected by the CAB
3.8 Change types
LSHTM ITS has 3 Request for Change (RFC) types
o Normal – Any high to medium risk/ impact changes requiring Change Advisory Board
(CAB) approval. Normal changes are often categorised according to risk and impact to the
organisation/business. For example, minor change – low risk and impact, significant
change – medium risk and impact and major change – high risk and impact. (LSHTM ITS
Change Management has not broken it down to impact/ risk and it will be part of the future
work as it matures the process).
By definition a normal change will proceed through all steps of the change management
process and those that are categorised as medium or high risk will be reviewed by the
Change Advisory Board (CAB).
o Standard – Lowest level pre-authorised changes of low risk that are frequently carried out
(i.e. repeatable in nature) and do not require CAB approval as there is an accepted/
established procedure to provide a specific change requirement .i.e. there is a high degree
of
o confidence in the success of the outcome. Standard Changes are normally pre-template
low risk/ low impact changes. Standard changes will have a defined trigger to initiate the
change.
o Emergency – Any change requiring instant implementation to address an issue that is
causing or likely to cause significant impact to the Business. Emergency changes are more
prone to disruption and failure and thus must be managed carefully and in some
unavoidable situations, it will result in a retrospective change.
3.9 RFC Criteria
A Normal RFC should be submitted if it is a:
• Major release or significant user impact at point of release
• New service introduction.
• Multiple users affected.
Examples
o Release of a business system upgrade (e.g. Agresso 5.7.5) = Submit Normal RFC as high
risk, low volume
o Point release of a business system upgrade (e.g. Agresso 5.7.6) = review release notes,
talk with manager, most likely outcome is to submit Standard RFC if low risk high volume.
o Regular scheduled security patches should go through as ‘standard’ changes so that there
o New major project release = Submit Normal RFC
o Release a fix to a P1 = Submit Emergency RFC
o Replace minor equipment (e.g NW switch) = No need to submit RFC although could submit
Standard
o Replace major equipment over a phase (e.g. MFD) = Submit Normal RFC at the start of the
implementation, followed by Standard RFC for each machine
o Decommission a service/server = Submit Normal RFC
o Urgent restoration of a service straight away = record as a retrospective Emergency if no
time to submit upfront
o Maintenance tasks should be recorded as Standard change if there is a likely risk to
service(s) and / or a communication is required
o A POC and pilot are generally considered outside of change control when they involve user
testing as they will bring to the surface many factors that may not have previously been
considered. If however the POC is ring-fenced and a straight promotion to live then an RFC
should be considered.
3.10 Change Advisory Board
CAB purpose
• To review and evaluate Changes for risks/ unintended consequences and to collectively
make an informed decision on Normal RFCs
• To schedule and prioritise changes by ensuring that the proposed implementation time is
appropriate and does not conflict with the business needs other change or operational
activities.
• Holistic view of all changes and to make recommendations to reduce risk, increase likely
success, and minimize business impact.
• Build awareness of upcoming Changes.
• Manage down unauthorised changes.
• Control changes through release process.
CAB rules
• Change Advisory Board (CAB) meet every Wednesday to review Request for Change
(RFC)
• Meeting may be virtual or face to face
• Virtual CAB may approve online sooner
• Changes will be listed on Forward Schedule of Change i.e. the Change Calendar on
TOPdesk.
• Raising RFCs at this point is for ITS use only and will include Business Owners at some
point of the future once the process is fully embedded and matured.
• Changes raised by PMO (for introduction of new services) should have the Service Support
Guide attached along with the *Acceptance into Services criteria ticked off before an RFC is
submitted for CAB Review.
*Acceptance into Service criteria could vary depending on the service being introduced but
general best practise rules apply.
• Project Managers may be invited to CAB to answer any queries to help avoid rejections.
• All Known Errors must be formally accepted by CAB before go-live.
• Evaluate proposed change for risks and mitigation.
• Ensure that business outcomes are documented and well understood.
• Schedule and prioritise Changes.
• Evaluate if the proposed Change will give the intended outcomes without adversely
impacting the business.
• Ensure the proposed time is appropriate (doesn’t conflict with business needs, other
change, or operational activities).
• Determine likelihood of unintended impact of the proposed Change.
• Make recommendations to reduce risk, increase likely success, and minimise business
impact.
• May request for a more in-depth, formal Change Evaluation for any given change. CAB
uses the findings of Change Evaluation to assess the Change.
3.11 High Level Normal Change Process
The high level activities are of the normal change process areas follows:
• Change Requester/ Implementer Creates/ Logs the Requests for Change.
• Preliminary Checks on the Change is carried by the Change Manager.
• CAB Reviews, Assesses and Evaluates the Change and inputs into Priorities, Change
planning and Scheduling where required.
• CAB Approves/ Authorises the Change.
• Change Implementer/ Manager Coordinates the change Implementation.
• Change Implementer/ Manager Reviews and Closes the Change record.
3.12 Change Management Process Flow Summary
LSHTM Change Management Process includes the following activities:
1) Create & Log the Request for Change (RFC)
A Request for Change is created by the Change Requester, (PMO or internal Technical SMEs)
requiring the Change. All Normal Changes will be raised via the Self Service Portal and submitted
to the CAB for Review.
2) Review Request for Change (RFC)
Each Request for Change should be reviewed and prioritised by the Change Manager. These
RFCs should be queried with the Change Requester esp. if it requires more detail/ clarity around
the implementation plan/ backout plan/ any process changes required/ additional documentation
around KIs/ SSGs etc. These changes will be monitored by the Change Manager and once
satisfactory responses have been received and input into the RFC for an audit trail, it will get
scheduled in for CAB Review.
3) Evaluate the Change (RFC)
Evaluating the change to assess the impact, risk and benefits to IT services is critical in order to
avoid unnecessary disruption to business operations at LSHTM. Impact assessment will consider
the
impact/ risk of the Change presented and reviewed by the CAB around the business,
infrastructure, customers, implementation resources and currently scheduled changes in the
change log. The CAB will consist of various ITS stakeholders at LSHTM such as the Head of
Systems, Head of Networks, Head of Security, Web Team Manager and the Helpdesk Manager
who will be responsible for evaluating the Change.
4) Approve/Authorise the Change (RFC)
Change requests commonly require authorisation prior to implementation (except in the case of
retrospective Emergency Changes) and each change requires authorisation from the CAB to
proceed. In the case of Emergency Changes which is logged for urgent approval, the Change
Implementer will notify the Change Manager/ Team Manager of the it. It will need atleast one
member of CAB to sign off an Emergency Change.
5) Coordinate Implementation
Once authorised, the Change is handed over to the release and deployment process for
coordination and collaboration with the appropriate technical and/or application management
teams for building, testing and deploying the change. Each change should have remediation plans
prepared in the case of an implementation failure. The Change Calendar will be kept up to date
with all upcoming changes that may impact them. The Change Calendar along with any expected
deviations in service availability will need to be taken into consideration when coordinating change
implementation.
6) Review and Close Change Request
Upon completion of the Change, a Post Implementation Review (PIR), which is a review of the
detail implementation results and lessons learnt, will need to take place if there were deviations to
the expected outcome of the Change.
