POL00337572
POL00337572
Post Office Limited - Document Classification: INTERNAL
1.T Change Management Process
Version — V3.1
Internal IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited - Document Classification: INTERNAL
Contents
1 Introduction
1.1 Purpose
1.2 Definitions
1.3. Scope...
1.3.1 Pre-Productio!
1.3.2 For Information Only
1.3.3 Out Of SCOPE... eeeeeeseeeeeteeeeees
1.4 Benefits and Value of Change Management
1.5 Triggers...
1.6 Process Outputs
1.7 Governance...
Change Procedure.
Change Process...
Change Request
aR WN
Change Type...
5.1. Change Impact...
5.2 Change Risk
5.3. Normal Change Type
5.4 Minor Change Sub-Type
5.5 — Significant Change Sub-Type
5.6 Major Change 12
5.7 Standard Change..... 13
5.7.1 Maintenance Windows and Standard change............ 13
5.8 Emergency Change
5.8.1 Major Incident...
5.8.2 Preventative (non-p1/p2
5.9 Out of Hours ..
5.10 Expedited Change
5.11. Unauthorised Change 18
5.12 Change Approval Matrix. 16
5.13 Change Closure... 16
6 Change Advisory Board (CAB)..... 18
Internal IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited - Document Classification: INTERNAL
6.1 CAB Standing Members.
6.2 CAB Agenda/Minutes..
7 Communications and Model Office testing .............
8 Change Reporting....
9 Policy / Process Reviews
10 Continual Service Improvement................
11 Appendix 1
12 Document Control
13 Company Details ...
Internal
IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited - Document Classification: INTERNAL
1 Introduction
11 Purpose
The purpose of this process is to ensure that any changes to Post Office Ltd IT Services are
managed in an established manner. The process aims to maximise the number of
successful changes by ensuring risks and impacts have been properly assessed, approved
and the forward schedule of change is managed effectively. This document provides an
overview of the Change Management process, which has been designed in accordance with
ITIL 4 best practice.
1.2 Definitions
Change Management - refers to the formal process for making changes to Post Office IT
services, within the production environment. It controls the life cycle of all changes, enabling
beneficial changes to be made across the internal and partner-delivered, maintained and
supported environments, with minimum disruption to the Post Office, its customers and end
users.
Change - is defined as the addition, modification or removal of anything that could have a
direct or indirect effect on services.
1.3 Scope
This process applies to all Post Office staff including contractors, as well as all partners
involved in activities that cause or require changes to IT Services within the Post Office
production environment. As defined by the ‘Change Management Tiers Matrix’.
1.3.1 Pre-Production
The change management process applies to all live production IT services and
infrastructure. Non-production environments are out of scope for this process.
However, pre-production, test or development environments that utilise production data or
infrastructure are in scope and should follow this agreed process. This applies to pre-
production systems using live data or environments where live and pre-production
infrastructure cannot be segregated.
Changes entirely within the pre-production environment and where appropriate segregation
is in place between pre-production and production environments are out of the scope of the
change management process and should be implemented in line with partner/internal team
pre-production processes.
1.3.2 For Information Only
Changes in 3 party environments or out of scope releases, not aligned to this process,
(e.g., Tier 5 partners and Data Services), should be logged for notification only using minor
or standard change types. These notification changes are logged in ServiceNow and appear
on the FSC, they do not include the full change plan requirements detailed below (Section
4).
See ‘Change Management Tiers Matrix’, for process by partner/service and tiers definitions.
1.3.3 Out of Scope
Service requests are an exception to this process and fall under the scope of service request
fulfilment, e.g.
Internal IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited - Document Classification: INTERNAL
Account administration
Password resets
Mailbox management - creation, deletion & permissions for shared mailboxes,
distribution lists etc
Other operational BAU activities fall outside of this process and should be tracked for audit
purposes. This includes updates to systems or databases which are configuration/formatting
only and where the impact/risk is negligible.
1.4 Benefits and Value of Change Management
Reliability and business continuity are essential for the success of the organization. Service
and infrastructure changes can have a negative impact on the business when risks are not
identified and changes not planned correctly.
Change management enables us to add value to the business by:
eee eens
Protecting the business and other services while making required changes
Implementing changes that meet Post Office requirements while optimising costs
Ensure adherence to governance, legal, contractual and regulatory requirements
Reducing failed changes, service disruptions, defects and rework
Improving service availability by improving the speed and success of corrective changes
Reducing the time and effort needed to manage changes
Aiding productivity of staff through minimising disruptions due to high levels of unplanned
or ‘emergency’ change and hence maximising service availability
Reducing the Mean Time to Restore Service (MTRS), via quicker and more successful
implementations of corrective changes
Liaising with the business change process to identify opportunities for business
improvement
1.5 Priorities
Maximise successful change: Deliver benefits to the business through successful
changes and protect live service from harmful changes
Minimise Disruption: Strive to minimize disruption to day-to-day operations and ensure
that changes are implemented in an efficient and effective manner with remediation
plans in place for roll-backs scenarios
Ensure Clear Communication: Ensure clear and consistent communication to
stakeholders, including communications in advance for planned downtime
Foster Engagement: Actively seek out stakeholder feedback to drive continual
improvement
Manage the change schedule: Effectively manage the forward schedule to help plan
changes, assist in communication and avoid conflicts
Monitor and Evaluate: Closely monitor the success of changes, and evaluate both
positive and negative impacts on the organisation
Increase flexibility: Create an environment that is supportive and enables change in an
agile environment, in line with the business's strategy and risk profile
1.6 Triggers
The triggers below result in the need for change and feed into the change management
process:
e Incident - An unplanned interruption or a reduction in the quality of an IT service
« Problem — A cause of one or more incidents
e Request — A request to carry out improvements or maintenance. This is usually for
minor changes that are low risk and do not require a project
Internal IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited - Document Classification: INTERNAL
e Project — Project delivery work, introduction of new services and development of
applications requires changes to be raised for implementation into the production
environment, this includes projects using both Waterfall and Agile methodologies
1.7. Process Outputs
Rejected changes
Approved changes
Change to the services or infrastructure resulting from approved changes
New, changed or disposed assets or configuration items, e.g., baseline, service
package, release
« Forward Schedule of Change / Change Calendar
*« Communication
+ Post Implementation Review
1.8 Governance
Changes will be audited on a periodic basis for policy compliance. Individuals who violate
the change management policy may be subject to disciplinary action. The change
management process is in line with ITIL 4 and interacts closely with all service management
practices and processes. Tier 1 partners/services are required to participate in a monthly
change service review meeting to assess monthly performance against KPls, discuss
continual service improvement initiatives and any other business.
2 Change Procedure
Change is identified
Change Request is submitted via integration to service management tool for Tier 1
partners and portal/email for other partners. Post Office and DXC changes are logged
directly into the service management tool
Change Management carry out initial assessment and technical review of change
Standard changes are pre-approved once Change management has agreed for the
addition to the Standard Change Catalog
Minor Changes are approved in-partner or by service management or peer for internal
POL managed changes
Significant and Major Changes are reviewed by CAB
CAB assess and evaluate the business justification, impact, cost, benefits and risk of
changes
CAB authorization/rejection
Emergency Changes are approved or rejected by ECAB/Service Management via Email
Change Calendar/Forward Schedule of Change updated
Post Implementation Review (Mandatory for Failed changes for Tier 1 suppliers)
Internal IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited - Document Classification: INTERNAL
3 Change Process
——
Change Request submitted in
service management tool
Rejected/Re-work
L
{( cieaateasn
Classification;
Change Type based on Risk and
Impact
E-Approv
Approved in-
supplier
Planning; Risk, Impact and
Resources
No
CAB Approved, I> _ Rejected/Re-work
——=
Implement
Back Out Plan
Failed (PIR)
Success/Failure
and Close
intemal IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited - Document Classification: INTERNAL
4 Change Request
The Change request form contains the following fields, which must be completed before
submission. Fields marked * are mandatory.
es allo sete ((Enaw: v
a None v
a
v Net a
1 lrpact, v
Change Management allo
Planning Schedule Confets Notes I Closurelnformation
Implementation lan
Rekandimpact analysis
Backout plan
Testpten [I
we ote
Pannedand date oa A tage
Intemal IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited - Document Classification: INTERNAL
5 Change Type
Change type and the authorisation level for a change request is established based on an
assessment of risk and impact using the below matrix as a guide.
Medium
High Impact ieee Low Impact
High
Risk Significant Significant
Mediu
m Risk Significan Significant Significant
Low
Risk Significan Significant
5.1. Change Impact
Impact is a measure of how the change will affect IT Service, business processes, users and
other partners. Changes that impact or require support from more than one partner must be
categorised Significant.
There are three impact categories:
Causes major impact to service, which may be during working hours
Affects Critical or Essential services, applications or infrastructure
Affects entire business or all branches
‘Another partner is impacted or required to support the change
‘Comms required
Causes impact to service outside working hours
Affects Critical or Essential services, applications or infrastructure
‘Affects whole departments or parts of the business
May impact another partner or require support
‘Comms may be required
Causes minimal or no impact to service
No impact or support required from another partner
No comms required or defined comms plan in place
Internal IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited - Document Classification: INTERNAL
5.2. Change Risk
Risk is a measure of how likely the change is to adversely impact the business, services and
associated processes.
Remediation plan unavailable, not fully tested or fix forward only
[Change validation dependant on user testing
IChange to business-critical services & Cl's or of high IT security relevance
Deemed to be very complex
[Change involves input from multiple support areas and/or partners
[Change not tested pre-deployment
First time of change type in live production environment, no previous experience
Remediation plan available
IChange can be validated immediately post implementation or may be dependent on user
testing
IChange to business-critical services & CT's or of medium IT security relevance
[Deemed to be of moderate complexity
Pre-deployment testing possible
[Successful implementation of pilot & subsequent phased rollout
Previous experience of change type, expertise moderate/high
Remediation plan known and tested
IChange can be validated immediately post implementation
[Change to a non-critical component
Non-complex change
IChange tested successfully in an environment that fully replicates the live environment
[Significant history of successful implementation
5.3. Normal Change Type
Anormal change is a modification to new or existing services, which is not classified as an
emergency or standard change.
Normal changes are divided into three sub-types depending on risk/impact, which require
different authorisation levels.
5.4 Minor Change Sub-Type
A Minor change is one which is low risk and low impact. Service blips or small outages to
colleague services outside of working hours are acceptable provided there is a proven history
of success and other partners are not impacted. Changes occurring during agreed
maintenance windows are also an exception to this.
The categorisation of Minor is derived using the Risk & Impact matrix as a guide. Any change
that is deemed to impact another partner, or where there is a requirement for cross partner
support, will be designated a Significant or Major change depending on the scale and duration
of impact.
Internal IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited - Document Classification: INTERNAL
Partner minor changes are approved in-partner, do not require additional Post Office approval
and will not be presented at the CAB for full review and authorisation however, these changes
will be present on the forward schedule of change and may still be subject to questioning by
the forum.
A Minor change must be submitted a minimum of 24 hours prior to implementation.
Minor changes for internal Post Office teams require service management or technical peer
approval prior to implementation see appendix 2.
5.5 Significant Change Sub-Type
A Significant change is one where the risk is deemed to be higher than that of a Minor
change and where there is greater degree of disruption or impact on the availability of
services. Any change deemed to carry a potential impact to service or requires support from
another partner, is automatically considered Significant as a minimum.
The categorisation of Significant is derived using the Risk & Impact matrix as a guide.
Significant changes will be presented in the CAB, chaired by Change Management and
attended by CAB standing members, affected business areas and technical representatives
presenting changes.
A Significant change must be submitted a minimum of 5 working days prior to
implementation and in line with CAB meetings for approval, therefore the cut off time for the
final approval in Business CAB is the previous Thursday at 6pm see Section 6. Any
change submitted after this time will be deferred for approval in the following week’s CAB or
if deemed critical must be submitted as an emergency change.
All Technical CAB approvals must be in place prior to the change being submitted for
approval at the Business CAB.
Only changes that meet the minimum data set by the cut off time will be considered for the
next CAB cycle. The ability for a change to be assessed will be impacted by any changes
with substantial information missing, lack of detail, change plans, minimum data set, etc
these changes will be deferred, please also refer to ‘CM-WI-MDS guide interna/external
users’.
5.6 Major Change
A Major change is one where the risk is deemed to be higher than that of a significant
change and where there is a higher degree of disruption, impact or cross partner
involvement.
The categorization of Major is derived using the Risk and Impact matrix as a guide. Any
change where there is a prolonged service outage, introduction or replacement of essential
services, or other high risk and high impact work, will be designated a Major change.
A Major change must be submitted a minimum of 5 working days prior to a Major CAB
meeting being arranged. A Major change must take place a minimum of 10 working days
prior to implementation and separate Major CAB meetings will be arranged adhoc for
approval. Preferred days to facilitate Major CAB are Monday and Wednesday and
arrangement is by prior engagement with the change team.
Major changes will be presented in the Major CAB, chaired by Change Management and
attended by CAB standing members, affected business areas and technical representatives
presenting changes.
Internal IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited - Document Classification: INTERNAL
5.7 Standard Change
A Standard change is pre-defined and pre-approved by Change Management following the
initial standard change approval process, where authorisation is provided via CAB and
changes added to the Standard Change Catalog.
Standard changes should be defined by the following criteria, however other regular
changes will be considered:
Predictable and successfully implemented a number of times previously
Repeatable with documented procedures
Known impact, accepted risk and agreed cross-departmental notifications
Typically triggered by scheduled or threshold event
No history of unplanned impact
Standard Changes will be reviewed on an annual basis to ensure the plan and other
supporting information is still valid.
If a standard change causes any unplanned impact or deviates from what has been agreed,
it may be revoked following a PIR.
Standard Changes must be logged prior to implementation, but there is no minimum
submission time.
5.7.1 Maintenance Windows and Standard change
Where a maintenance window has been agreed with the business, Standard Changes may
be used to enable the implementation of higher risk changes, where either no impact is
expected, or the business has agreed to business impact, within pre-approved slots.
Any failures will be reviewed, the maintenance window could be removed with changes
reverting to usual risk/impact matrix until success is proven.
Approved maintenance windows can be found in the service management tool here :
ServiceNow Maintenance Schedules
Also see CM-PRO-Standard Changes & Maintenance Windows.
During change freezes maintenance windows will be temporarily revoked for changes that
impact business services.
5.8 Emergency Change
5.8.1 Major Incident
An emergency change is identified when there is immediate action required to resolve a P1
or P2 high priority incident. Where a Major Incident Management bridge is ongoing, approval
to implement a change to resolve a Major Incident can be provided by the Major Incident
Bridge acting as an approval body. The change must be logged retrospectively with all
relevant technical detail within 24 hours. A change management representative will be
available as part of the MIM call if support is required from a change management
perspective.
It is the responsibility of the Major Incident Team to link Mls to change records in the service
management tool if:
Internal IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited - Document Classification: INTERNAL
e Ml caused by Change
« Change required to resolve MI
5.8.2 Preventative (non-p1/p2)
Where a change is required to prevent an MI, or in the absence of a MIM bridge, the
emergency RFC should be submitted to the Change Team for assessment, validation and
approval.
Each preventative emergency change is assessed should be approved via the Emergency
CAB (ECAB) or email as per the change approval matrix (section 5.12).
If work is required immediately to prevent a business-critical outage the Change
Management Team should be informed immediately, in order to facilitate retrospective
approvals.
Retrospective changes must be logged within 24 hours and success of the change
communicated in line with the change process.
5.9 Out of Hours
Out of hours the Major Incident Management Process is unchanged and emergency
changes should be approved as part of the Major Incident Bridge or by the Duty Major
Incident Manager (see Major Incident Process).
Proactive activities to prevent major incidents occurring and protect business critical services
may also be required out of hours. It is the responsibility of the change requestor to obtain
internal duty manager approval for the change to go ahead and an RFC must be raised
retrospectively.
The Change Team and Major Incident Manager should be informed retrospectively. If there
is an adverse impact or a P1/P2 arises, this should be raised as per the usual Out of Hours
Major Incident Process.
Retrospective changes must be logged within 24 hours and success of the change
communicated in line with the change process.
Internal IT Change Management Process V3.1
Post Office Limited - Document Classification: INTERNAL
5.10 Expedited Change
POL00337572
POL00337572
Lead times for different change types are in place to protect service and allow for proper assessment, planning, appropriate back out plans,
communication plans and for resources to be aligned. Any change that is submitted outside of lead times must be categorised as an
emergency change and follow the emergency change process, a minimum 5-hour lead time between submission and implementation is
required for emergency change that is not related to a P1 or P2 incident or the prevention of an MI.
These changes by their nature bypass the change management process and should only be submitted in business-critical
circumstances.
Head of IT Service pre-authorisation will be required prior to the change being accepted. This sign off will allow the change to enter the ECAB
approval process, this is not approval to proceed. Usual Emergency change approval will be required.
Any emergency changes not linked to major incidents will be monitored closely and individuals found to be not adhering to the change
management process will be penalised.
IT Service
Horizon
Device
Core Platforms and Products*
Management
Banking and Commercial
Head of IT Service
Martin Godbold
Matt Quincy
(Networks and Connectivity)
Darren Yarwood
Marie Jago (Colleague IT)
Praveen Pai
(Software and Robotics)
Chanchal Samaiya
(Back Office Platforms)
Greg Hunt
Senior/Service
Manager (Delegated
authority)
Lorna Owens
Matt Griffiths
(Horizon)
Ashley Humphries
(Networks and connectivity)
Nick Baker
(Bill
Payments/CDP/Identiy/PUDO)
Marie Jago
Luke Hoskins
(Colleague IT)
Chloe Allington
(Identity/PUDO)
Diane Gilmore
(Banking)
Internal
IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited - Document Classification: INTERNAL
John Aldridge
; Lee (Automation/SSk)
lan Humphries McCormack
(SSK/PED) Emma Hunter
(Payments)
*See Appendix 1
Internal IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited - Document Classification: INTERNAL
5.11. Change Approval Matrix
Sub-Type
Type Major Significant Minor
In-Partner/POL SM or
Normal Major CAB CAB Peer review
See appendix 2
Major Incident Bridge
Emergency (P1/P2)
Head of IT Service pre-
approval Head of IT Service pre- I Head of IT Service pre-
e Emergency (non approval approval
P1/P2) ,
* Expedited Major ECAB or Email ECAB or Email Approval I In-Partner/POL SM or
Approval - Change
Manager and Senior
Service Manager
e Preventative - Change Manager and Peer review
Senior Service Manager I See appendix 2
5.12 Unauthorised Change
All unauthorised changes are subject to a formal Post Implementation Review (PIR) having
not met the requirements of the Change Management Process. They have been
implemented:
e Without being fully approved and scheduled via the Change Management Process
e As part of an incident resolution, but have not been approved via the Major Incident call or
retrospective change request submitted
e Without following the agreed and approved process, plans, procedures, or actions
e Before the agreed start time
e After the agreed end time
5.13 Change Closure
The outcome of change requests should be communicated post implementation by email to
Change Management and all relevant stakeholders within 24 hours. For partners with
integrated service management tool functionality these updates should be made in the
change record.
Closure code must be selected, these are subject to change, but are also used for reporting
and assessment of change KPIs:
Successful - completed successfully as per plan with no issues encountered
Internal IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited - Document Classification: INTERNAL
Successful with issues - the change partially completed but wasn’t rolled back, e.g.,
configuration work or upgrade work on several servers and not all servers were completed
This category is also used for unsuccessful non-POL approved (tier 4&5, 3” party,
notification only) changes outside of our control
Unsuccessful - Change did not meet desired outcome. Change may have been rolled back
or fixed forward. It may have caused an incident or unplanned impact to service
Aborted -no change made - the change didn’t start, and no changes were made
Unauthorised — was not approved in line with the change process
Cancelled — MDS not provided — Minimum data set not provided following 2 attempts for
further information
3” Party Unmanaged — Unsuccessful — 3" party standard change for notification only has
not been successful
Closure notes are also mandatory for each change and should describe the completion of
each change with any additional details provided.
Post Implementation Review is mandatory for all Unsuccessful changes for Tier 1 Partners.
Please see related document ‘IT Change Management PIR Process’.
Internal IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited -
Document
6 Ghange’Advisory Board (CAB)
The CABis a ody that exists to support the authorisation of changes and to assist change
management in the assessment and prioritisation of changes. As and when a CAB/ECAB is
convened, members should be chosen who are capable of ensuring that the change is
adequately assessed from both a business and a technical viewpoint as well as potential
impact to the IT controls framework.
Change Management will chair the CAB, and members include:
Partners
Service Management representatives
Business Users
Project managers
Heads of IT
Senior Service Managers
Internal Communications
Applications developers/maintainers
Specialists/technical consultants
IT Services and operations staff, e.g., service desk, service transition, incident
management, capacity, SACM
Facilities/office services staff
Branch Network
Test Team
Architecture
Solutions Delivery Specialist
Change request technical representatives
IT Security Architecture
Cyber Security Compliance
Technical CAB is held on Tuesday at 11:30am to 1pm. This forum is focused on the
technical aspects of the change. What IT changes are being made and what is the impact of
these changes on other POL services? A deep dive into implementation plans and other
questions can be expected.
The Business CAB is held on Thursday at 12pm to 1pm. This forum has the addition of
business product owners and service managers, as well as branch engagement and
communications teams, who review the changes from a business perspective. The focus in
this forum is impact to POL services, Postmasters and communications plans.
The forum is chaired by Change Management via a virtual conference facility (Teams).
The technical resource implementing the change, a partner Change Manager or a
nominated delegate must represent proposed changes at the CAB.
Non-attendance without prior agreement may result in the change being rejected.
The purpose of this forum is to:
Assess the technical feasibility of proposed changes
Assess impact & risk of the change on the business
Assess impact on other services that run on the same infrastructure
Identify changes that are not in line with the Post Office strategic roadmap
Ask questions and share knowledge
Internal IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited -
Document
If the-discussiog Jeaves significant doubt about a proposed change, Change Management
will defer thechange until clarification can be provided and all parties are agreed.
Partners and standing members are required to contribute to ensure changes are accurately
assessed to avoid cross supplier impact and any unexpected impact to Post Office services.
The meeting may be recorded for training and quality purposes.
CAB weekly timeline:
Post Office
12—Ipm 11.30am - Ipm
Business CAB Technical CAB
Technical CAB Agenda Business CAB Agenda
Sent Sent
RFCs for next CAB
Cut Off 6pm
6.1 CAB Rejected Changes
For changes rejected by CAB members or Change Management a risk acceptance form
must be completed by the business for the change to go ahead. In the submission of this
form the appropriate business representative/s accepts responsibility for the risks associated
with the change against the advice of the CAB.
6.2 CAB Standing Members
The CAB Standing Members are the regular assessors of change. They provide technical
assessment and input when a change is being presented. Change requestors will also
attend. Additionally, POL business colleagues, product owners and service managers will
attend the Business CAB each Thursday.
6.3. CAB Agenda/Minutes
The CAB Agenda is sent the day before the CAB is scheduled to all standing members and
change representatives. CAB minutes are a required output of every CAB meeting. They are
sent after every CAB meeting to the CAB attendee’s and standing members.
Internal IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited -
Document
Communications and Model Office testing
If colfimunltations are required to POL stakeholders to inform of an outage or change
related information, the change requestor must contact the POL comms team for this to be
arranged. The organising of comms is out of the scope of the change process, however
approval of a change can have a dependency on appropriate comms being in place prior to
implementation.
Additionally, for changes where comms are required to branches to inform of downtime, the
change should be approved a week in advance to allow for the 7-day lead time for branch
notifications, as required by the POL comms team.
If Model Office testing is required the change requestor or associated partner/POL project
manager must arrange this with the Model Office directly. The organising of this testing is out
of the scope of the change process, however approval of a change can have a dependency
on appropriate testing being arranged prior to implementation.
8 Change Reporting
Forward Schedule of Change is sent to CAB members and key stakeholders on a daily basis
at 6pm.
Weekly change management report for changes the week ahead is sent each Friday to key
Post Office stakeholders and uploaded to Teams site.
Dynamic Change Management data is available on the IT Change Management ServiceNow
dashboard.
Monthly change management reporting is produced on the 5" day of the month and includes
performance against the following key performance indicators:
KPI Description KPI
Successful Changes - the percentage of successful changes, versus the total number of 295%
change requests °
Unsuccessful Changes - the percentage of unsuccessful changes, versus the total number 25%
of change requests °
Unauthorized - the percentage of unauthorised changes, versus the total number of Subcategory
of the above
change requests .
Unsuccessful
Standard Changes- the percentage of standard changes, versus the total number of 230%
change requests °
Emergency Change- the percentage of emergency change requests, versus the total 25%
number of change requests °
Total Volume of Change — The total amount of change requests with planned end date in .
the month
Internal IT Change Management Process V3.1
Post Office Limited -
Document
POL00337572
POL00337572
Volume. of 2O1;,4nanaged changes that caused major incidents - The number of POL
managed changes that caused Major incidents
Volume of 3rd party changes that caused major incidents - The number of 3 party
changes that caused Major incidents
% POL managed change that caused major incidents - The percentage of POL managed
changes that caused Major incidents
22%
Other reports are available on an adhoc basis.
9 Policy / Process Reviews
The effectiveness and efficiency of the change management process is reviewed
continuously as such the process may change at any time.
10 Continual Service Improvement
The continual service improvement process for change management is owned by the IT
Service Delivery Manager. It is their responsibility to capture information that feeds into the
continual service improvement plan for IT change management. Post-implementation
reviews are mandatory for failed changes for Tier 1 partners, where the end-to-end process
for that change is reviewed. Lessons learnt & actions are outcomes of this meeting. These
improvements feed into continual service improvement.
Internal IT Change Management Process V3.1
Post Office Limited -
Document
11 Appendix 1 Systems
INTERNAL
Internal
Networks
Swindon applications
Matt Quincey — Head of Networks and
Connectivity
RPA
Praveen Pai — Head of Software and RPA
IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited -
Document
12 Appendix 2 Post Office internal approver matrix
INTERNAL
POL Team
Peer Approver/Service Manager
Network and Connectivity*
Matt Quincy
Ash Humphries
Colleague IT*
Darren Yarwood
Luke Hoskin
Mike Cowing
Software and Robotics*
Praveen Pai
Back Office Platforms*
Chanchal Samaiya
Horizon*
Lorna Owens
Marie Jago
lan Humphries
Banking and Commercial *
Nick Baker (Bill Payments/CDP/Identiy/PUDO)
Diane Gilmore (Banking)
John Aldridge (Automation/SSK)
Emma Hunter (Payments)
Cloud Centre of Excellence (AWS,
Azure)
Craig Bibby
Ben Owens
John E Lane
Luke Harrison
Integration Engineering (AppMod)
James High
Graham Bevan
IT Security Ross Welton
Faisal Ali
NBIT Clare Mapes
Mike Braithwaite
Kathryn Wearne
Branch Hub Di Walker
Andy Greening
Internal IT Change Management Process V3.1
POL00337572
POL00337572
POL00337572
POL00337572
Post Office Limited -
Document
ServiceNow, Support Min Dulai
INTERNAL Chris Hardy
Digital Workplace Darren Yarwood
Mike Cowing
CDE (Awaiting service transition)
John Nelis
Natalie Kaye
Alex Wood
*Where submitted by Tier 1 suppliers, no POL approval required
Internal IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited -
Document
13 Document Control
INTERNAL
Date Version Updated by Change Details
10/02/19 04 Cherise Osei Draft Version
104/19 1.0 Cherise Osei ‘Approved Version
6/08/19 14 Cherise Osei ‘Added KPIs, change service review and PIRs
20/08/19 12 Cherise Osei ‘Approval matrix added
13/01/20 13 Cherise Osei KPI adjustment
49/02/20 14 Cherise Osei PIR Process Doc addition
06/03/20 15 Cherise Osei MO and Comms out of scope statement refined
02/04/20 16 Cherise Osei Updated CAB timeline graphic
07/04/20 17 Cherise Osei Update to Emergency change/Ml process
29/06/20 18 Cherise Osei ‘Amend minor change lead time
27/07/20 19 Cherise Osei ‘Amend minor change lead time
21/08/20 2.0 Cherise Osei Updates to Standard and Emergency change
sections
27/11/20 24 Cherise Osei Update to CAB to include IT Control Framework
21/01/21 22 Cherise Osei Changes to new CAB times/preapproval role and
authorisation matrix
16/03/21 23 Cherise Osei Update to include Back Office changes and FS&T
24/05/21 24 Cherise Osei Changes to new CAB times
17/05/21 25 Cherise Osei Update to out-of-scope statement and exemption for
Data Services changes
2107/21 26 Cherise Osei Link added for approved ServiceNow Maintenance
Schedules
17/11/21 27 Cherise Osei Update to CAB section, various updates and C&D
Head of Service
11104122 28 Cherise Osei Updates to approvers
20/10/22 29 Cherise Osei Various updates in line with current ways of working
29/03/23 3.0 Cherise Osei Updates to minor change approvers, expedited
approvers, lead times and some terms to ITIL4
24/07/23 34 Cherise Osei Update to section 5.11, 5.12, Appendix 1 & 2
Update to registered address
Update to KPIs
Update to font in line with POL standard
Internal IT Change Management Process V3.1
POL00337572
POL00337572
Post Office Limited -
Document .
14 Company Details
Post Office Limited and Post Office Management Services Limited are registered in England
and Wales. Registered numbers 2154540 and 08459718 respectively. Registered Office:
100 Wood Street, London, EC2V 7ER.
Post Office Management Services Limited is authorised and regulated by the Financial
Conduct Authority (FCA), FRN 630318. Its Information Commissioners Office registration
number is ZA090585.
Post Office Limited is authorised and regulated by Her Majesty’s Revenue and Customs
(HMRC), REF 12137104. Its Information Commissioners Office registration number is
24866081.
Internal IT Change Management Process V3.1