Pos
Offi
ce
Lim
ited -
Doc
um
ent
Cla
ssifi
cati
on:
INT
ER
NAL
Post Office Horizon IT
Defects Management Process
POL00337596
POL00337596
Pos
Offi
ce
Lim
ited -
Doc
um
ent
Cla
ssifi
cati
on:
INT
ER
NAL
POL00337596
POL00337596
0.1 Document Ownership
Document Owner Martin Godbold (Post Office Ltd)
Head of Horizon Live Service
Paul Smith (Post Office) Branch
(eecaerinalTi/ AGATE Technology Defects Lead
Reaeneeaaea, Simon Oldnall (Post Office)
Horizon IT Director
Document Version V1.1
Last Updated 31/08/2022
0.2 Document Control
Version Author Changes Made Date Completed
Number
Draft V0.1 Paul Smith (Post Office) Initial Draft Completed 5th April 2022
Branch Technology Defects
Lead
Draft V0.2 Paul Smith (Post Office) Updated post comments 7th April 2022
Branch Technology Defects I from Head of Live Service
Lead
Draft V0.2 Paul Smith (Post Office) Updated post comments 14" April 2022
Branch Technology Defects I from Senior Service
Lead Managers
V1.0 Paul Smith (Post Office) Updated post comments 31st August 2022
Branch Technology Defects I from Horizon IT Director
Lead
V1.4 Paul Smith (Post Office) Update of Criticality 8" December 2022
Branch Technology Defects I scoring post review
Lead
0.3 Document Purpose
The purpose of this document is to describe the process for managing defects internally, and with
suppliers to Post Office Ltd., describing how the process assists in controlling the impact of defects
on branches.
The document aims to provide understanding of the individual steps undertaken in the Defects
Management Process and articulate ownership at each level of the Defects Management lifecycle.
Defects Management Process V1.01.0Page 1 of 231‘ August 2022
POL00337596
POL00337596
Pos
t
Offi
ce
Lim 0.4 Glossary of Terms and Abbreviations
ited -
Doc
um Term Definition
ent Branch The physical Post Office premises/equipment
ce Horizon Point of sale system utilised in branch supported/developed in part by Fujitsu
oii Postmaster The manager/owner of the branch, and responsible for branch accounting
on: Supplier The organisation responsible for providing services to Post Office Ltd
INT A defect is an issue live in a branch that is inconsistent with the agreed design
ER Defect or service specification and affects, or has the Potential to affect, branch or
NAL customer financial outcomes or has the potential to affect the way a
Postmaster is required to use the system.
A problem is a cause, or potential cause, of one or more incidents. Problems can
Problem be raised in response to a single significant incident or multiple similar incidents
based on trend analysis
ServiceNow Service Management system tooling used for recording incidents, changes and
(SNow) problems.
Electronic documentation within the Post Office toolset used to document
KnowledgerArticle support notes workarounds and provide advice and guidance to Helpdesk
(4) Advisors.
Release Notes Documentation provided as part of a packaged/release detailing the content of
the release.
Information Technology Infrastructure Library — A methodology used for
me managing an IT service through a defined service management structure.
HU Horizon Issues Judgement
ITsM Information Technology Service Management — The principles used to manage
an IT service including Incident, Problem and Change Management.
Continuous Service Improvement — Activities undertaken based on defect and
csi/cIM problem findings that improve the service to Postmasters. Continuous
Improvement Module — The area within ServiceNow where CSI activities are
logged
Sent fees jhe underiving issue that once resolved will prevent recurrence of a specific
Horizon Defects Review Forum — A multi-party meeting held weekly where new
defects are discussed, in flight defects are provided updates and challenges can
HDRF/HDR be made to and from suppliers involved in the resolution of any defects. This is
not to be confused with he Horizon Design Review Forum where the design of
products and services on Horizon are reviewed and remediated.
A matrix of activities that make up the flow of a process which indicates which
parties are Responsible, Accountable, Consulted and Informed at each stage.
Key Performance Indicator — A measure of success and performance of an
element or whole of a process.
Root Cause Analysis. The analysis and documentation of the underlying defect
RCA providing details around why failures have been caused. Provided by the
supplier of the service.
RACI
KPI
Defects Management Process V1.01.0Page 2 of 231% August 2022
POL00337596
POL00337596
Pos
t
Offi
ce
Lim Table of Contents
ited - 0.1 Document Ownership.
Pac 0.2 Document Control.
um
ant 0.3 Document Purpose.
Cla 0.4 Glossary of Terms and Abbreviations.
ssifi 1.0 Defects Management Process Overview.
cati
pas 1.1 What is Defects Management?..
INT 1.2 The Defect Lifecycle through ServiceNow..
ER 1.2.1 In Progre:
NAL
1.2.2 Known Error.
1.2.3 Pending Change.
1.2.4 Pending Closure Acceptance.
1.2.5 Closed Resolved.
2.0 Post Office Defects Management Process Diagram...
3.0 RACI for the Defects Management Process..
4.0 Defects Management Process Elements...
4.1 Identification of a Defect.
Task Purpose.
Contributors...
4.2 Verification of a Defect.
Task Purpose.
Contributors...
4.3 Inclusion of the Defect in the Horizon Defects Review Forum (HDRF) Documentatio!
Task Purpose..
Contributors...
4.4 Socialisation of the Defect in the HDRF/Extraordinary Meeting..
Task Purpose..
Contributors...
4.5 Defect Logged in ServiceNow.
Task Purpose..
Contributor:
4.6 Branch Notification.
Task Purpose.
Contributors...
4.7 Knowledge Article Creation.
Task Purpose..
4.8 Investigation/Analysi
Task Purpose.
Contributors...
4.9 Notification of a Defect to Post Office Legal Team.
Task Purpose..
Contributors.
4.10 Criticality Scoring of the Defect...
Defects Management Process V1.01.0Page 3 of 231% August 2022
Pos
Offi
ce
Lim
ited -
Doc
um
ent
Cla
ssifi
cati
on:
INT
ER
NAL
POL00337596
POL00337596
Task Purpose.
Contributors...
4.11 Impact Statement Created.
Task Purpose..
Contributors...
4.12 Host of Bridge calls and Workshop:
Task Purpose.
4.13 Horizon Defect review Forum (HORF)...
Task Purpose..
Contributors.
4.14 Weekly Supplier Updates (Formal Notification).
Task Purpose..
Contributors...
4.15 Root Cause Analysis.
Task Purpose.
Contributors...
4.16 Workaround Creation.
Task Purpose.
Contributors...
4.17 Development of Fixes..
Task Purpose..
Contributors...
4.18 Testing.
Task Purpose..
Contributors...
4.19 Release Management - Scheduling and Deployment...
Task Purpose.
Contributor:
4.20 Fix Deployment.
Task Purpose.
Contributors...
4.21 Closure Agreement.
Task Purpose.
Contributors...
4.22 Escalation.
Task Purpose..
Contributors...
Appendix A — KPls for Defects Management.
Appendix B — Criticality Scoring Questions, Weighting and Owners
Defects Management Process V1.01.0Page 4 of 231° August 2022
Pos
Offi
ce
Lim
ited -
Doc
um
ent
Cla
ssifi
cati
on:
INT
ER
NAL
POL00337596
POL00337596
1.0 Defects Management Process Overview
1.1 What is Defects Management?
The defects management process was introduced to mitigate the findings and failings highlighted in
the GLO Horizon Trial that generated specific issues as part of the HIJ (Horizon Issues Judgement).
Some of these findings related directly to the lack of clarity, communication and controlled
management of defects in the Horizon system and branch equipment that could potentially impact
ona branches accounts or ways of working.
Defects Management is an extension of the Problem Management process created to give greater
governance and focus on those issues affecting branches from either a financial or poor experience
impact caused by a defect in the delivery and build of a Horizon or branch technology service.
Defects are managed through a set lifecycle which mirrors the ITIL Problem Management
methodology, but introduces further tasks and controls specifically designed to mitigate a number of
concerns and failings as indicated in the Horizon Issues Judgement (HIJ) for immediate rectification.
The Problem Management process has been mirrored as the process flow meets the requirements of
the Defects Management Process and looks to prevent Incidents from happening again through
effective Root Cause Analysis.
All Defects are logged in a service management toolset. For Post Office Ltd, the toolset used is the
Service Now ITSM module for Problem Management where progress and activity can be tracked and
governed, with a complete audit trail. Effective use of a CMDB with clear Business Services,
Configuration Items and categories aids in ensuring that effective analysis of existing Incidents to
assist in proactive trending, and linking Incidents raised and Defects in flight will help indicate full
impact and drive prioritisation.
Each Defect will have a differing impact on different areas across the business. It is important that
these impacts are understood and taken into account. A matrix for scoring is sent out to key
individuals in impacted areas to understand scoring against set questions. The questions are
weighted in favour of the impact felt directly on branches. Where the impact potentially affects
financial balancing, the scoring is weighted 300% to ensure this is give a higher focus.
1.2 The Defect Lifecycle through ServiceNow
The Defect Management Process follows the lifecycle as prescribed by ITIL V3, driven by the Service
Management toolset. The steps provide the structure and governance for managing Defects and the
activities required to effectively manage Root Cause and prevent Impact on branches.
1.2.1 In Progress
When a Defect is categorised as “In Progress”, it means the Defect Management Process is within its
earliest stages of understanding and no root cause has not been identified Whilst in this stage the
scope and reach of the Defect is defined. Stakeholders are invited to an extraordinary meeting of
the Defects Forum to socialise the issue and Suppliers are actively pursuing diagnosis and Root Cause
Analysis. The standard actions required for each defect raised to the forum will be raised as Tasks
(notification to legal for financial impact, Branch Impact Statement created, Knowledge Articles to be
completed for helpdesks, communication to branches drafted and delivered, criticality scoring to be
completed, and testing and release documentation to be collated) with clear ownership and
Defects Management Process V1.01.0Page 5 of 231% August 2022
Pos
Offi
ce
Lim
ited -
Doc
um
ent
Cla
ssifi
cati
on:
INT
ER
NAL
POL00337596
POL00337596
deliverables. Risks and\or Service Improvement initiatives (CSI/CIM) should be considered and
raised with the appropriate teams for consideration.
1.2.2 Known Error
When a Defect is in “Known Error” state, the Root Cause is known and understood. This will trigger
activities around updating the required information to Helpdesks and service users via KAs
(Knowledge Articles) where appropriate.
If a workaround is available, this should be developed and communicated if required to affected
branches and recorded in Service Now and as a Knowledge Article for use by the helpdesks.
1.2.3 Pending Change
At this stage, the investigation and Root Cause identification of the Defects process have been
completed. The Change and Release processes have been engaged and change references/release
schedules and dates should be available or planned.
All testing should be completed and observations signed off by the Test Analyst. All documentation
should be collated and reviewed by the Problem Manager or Branch Technology Defects Lead and
attached to the Problem record.
At this stage in the process all tasks should be given final review to ensure traction and completion.
All references from CIM and Risk Activity are recorded.
1.2.4 Pending Closure Acceptance
At this stage of the Defect lifecycle, the associated Change or Release has been delivered and the fix
is live with service users. Monitoring is undertaken to ensure that the fix has been successful and
the symptoms seen are no longer prevalent and associated Incidents are no longer raised or are
reduced in line with expected results.
1.2.5 Closed Resolved
Following a period of monitoring, if the Defect is resolved and all tasks closed, the Defect Closure
Process can be instigated to get agreement for closure from key Post Office Stakeholders involved in
the defect. Once agreement is received from each party, the form is attached to the Defects
Management record and the Problem or Defect formally closed down on the Service Management
toolset.
Defects Management Process V1.01.0Page 6 of 231% August 2022
Pos
Offi
ce
Lim
ited -
Doc
um
ent
Cla
ssifi
cati
on:
INT
ER
NAL
2.0 Post Office Defects Management Process Diagram
Defects Management Process V1.01.0Page 0 of 231% August 2022
POL00337596
POL00337596
3.0 RACI for the Defects Management Process
[Responsible for delivery
POL00337596
POL00337596
[Accountable for delivery
Consulted
-IoI>I2
informed
Pos
Offi
ce
Lim
ited -
Doc
um
ent
Cla
ssifi
cati
on:
INT
ER
NAL
POL00337596
POL00337596
4.0 Defects Management Process Elements
4.1 Identification of a Defect
Task Purpose
The identification of a defect usually occurs as part of trending, testing and development or the
investigation and resolution of an incident/multiple incidents where an impact has been
experienced. Suppliers are expected to bring to the process any branch affecting defects that have
potential to impact multiple branches (single instance or branch would indicate an incident) and are
suspected to be caused by a defect in the delivery and build of a Horizon or branch technology
service.
Internally, Post Office Helplines could identify trends or incidents of concern that they may wish to
raise through the Defects process to allow investigation by the relevant supplier
Contributors
Both the IT Digital Service Desk/Branch Support Centre and internal and external suppliers are
responsible for the identification of any defects found as part of day to day activity in either the
incident or problem management processes. The Branch Technology Defects Lead is accountable for
ensuring that this is being performed and informed of any issues while they are under investigation.
4.2 Verification of a Defect
Task Purpose
The verification of a defect is completed by any relevant supplier as part of the ongoing investigation
into an incident or issue raised. Verification will likely include understanding the current operation
of a transaction or service and comparing to the documented specification and expected outcomes
of a transaction. Should this fall outside of the expected result, and the operation of the transaction
or service falls outside of the expected design, then this issue is deemed as an implementation
defect and should then be included in the HDR Process.
Contributors
The supplier responsible for the provision of the service and the investigation into the testing defect
and or incident is are responsible for verification of the defect and raising to the Branch Technology
Defects Lead who is Accountable for ensuring that this happens when informed of the confirmed
defect status.
4.3 Inclusion of the Defect in the Horizon Defects Review Forum (HDRF)
Documentation
Task Purpose
The Defect should be included in the weekly defects HDRF documentation provided each Friday to
allow discussion in the following Monday’s Horizon Defects Management Forum (HDRF) as described
in 4.13. Each Defect should be provided with a summary document indicating the cause and effect
of the defect and where applicable, root cause, workaround and fix. This is a living document where
information is constantly updated until such time as the Defect is either awaiting release or fixed.
Where the defect is found internally or via a different supplier, the details are passed via the Service
Defects Management Process V1.01.0Page 0 of 231% August 2022
Pos
Offi
ce
Lim
ited -
Doc
um
ent
Cla
ssifi
cati
on:
INT
ER
NAL
POL00337596
POL00337596
Manager and an extraordinary meeting is held to understand and socialise the defect with members
of the Defects Management Forum.
Contributors
It is the Accountability of the verifying party/supplier to provide the details of any defect found to
the Branch Technology Defects Lead who is responsible for its inclusion in the meeting, to allow
initial engagement with the appropriate Service Manager, Release Manager and Branch Resilience
Manager before convening an extra ordinary HDRF.
4.4 Socialisation of the Defect in the HDRF/Extraordinary Meeting
Task Purpose
Each defect raised is discussed with the members of the Defects Management Forum (HDRF) as
described in 4.13. This allows the opportunity for questions and clarification to be gained to ensure
that tasks performed post meeting can be completed, i.e. Branch Impact Statements, Branch
Communications, Knowledge Base Article creation and notification to the legal teams. All defects
that are raised to Post Office as confirmed issues, must be socialised with the HDRF within 2 days of
notification. Where Fujitsu raise the defect, there are a number of internal forums that ratify the
defect before alerting Post Office, the final forum and documentation process completes each Friday
allowing for discussion in the main HDRF on the following Monday to meet the KPI. (KPIs shown in
Appendix A)
Contributors
It is the Accountability of the Branch Technology Defects Lead to ensure that the HDRF and any
extraordinary meetings are held to socialise any new defects. The Service Managers, Release
Manager, Branch Resilience Manager, Operational Teams, Test Team, Architecture Team and Head
of Live Service are all Informed and Consulted on the Defect to ensure that the right activities,
communications and questioning are all completed to deadline with a full understanding of the
issue.
4.5 Defect Logged in ServiceNow
Task Purpose
All Defects must be raised ServiceNow (SNow). Raising of the Defect in SNow gives visibility of
updates and tasks to all involved and provides an audit trail of activity and progress towards closure
including the Root Cause. Any new Incidents raised between Defect identification and resolution can
be linked to the Problem record. Each Defect must be raised within 2 days of the defect being
formally raised to meet KPI. This work is completed by the Branch Technology Defects Lead. Each
Defect Problem record will have a task raised that ties directly to each KPI lead activity to ensure
these are completed, tracked and measured.
Contributors
The Branch Technology Defects Lead is accountable for the creation of the initial Defect Problem
ticket and maintaining any Defect Problem record.
4.6 Branch Notification
Task Purpose
To ensure that branches are aware of all known defects that could affect them either financially or
cause a detrimental impact on how they work, an article is placed on Branch Hub for all branches to
see within 2 days of the defect being formally raised to meet KPI. This work is completed by the
Branch Resilience Manager within the operational teams.
Defects Management Process V1.01.0Page 1 of 231% August 2022
Pos
Offi
ce
Lim
ited -
Doc
um
ent
Cla
ssifi
cati
on:
INT
ER
NAL
POL00337596
POL00337596
Contributors
It is the Responsibility of the Branch Resilience Manager to take the outputs of the HDRF and create
a branch focussed communication to be published on Branch Hub. The Communications Team are
consulted to ensure that the message is worded in the correct manner for branches and meets all
organisation criteria. Once agreed, it is the responsibility of the Knowledge Management Team to
ensure that this is published on branch hub in time to meet the KPI deadline and inform the Branch
Technology Defects Lead of its implementation.
4.7 Knowledge Article Creation
Task Purpose
To allow branches to receive the right support when a defect is experienced, the Branch Resilience
Manager will work with the Knowledge Management team to create and publish information and
guides made available to the helpdesks. This ensures that the impact of the issue can be reduced
where possible through use of a workaround, or provides assurance that we are aware of the issue
and are working to resolve. Where the issue is financially impacting this can also include escalation
to the relevant teams. This is to be completed within 2 days of the defect being formally raised to
meet KPI. (KPIs shown in Appendix A)
Contributors
It is the Responsibility of the Branch Resilience Manager to take the outputs of the HDRF and create
a suitable Knowledge article to be published for both the ITDSD and BSC. Once drafted, it is the
responsibility of the Knowledge Management Team to ensure that this is published on the
knowledge bases in time to meet the KP! deadline and inform the Branch Technology Defects Lead
that this has been done.
4.8 Investigation/Analysis
Task Purpose
Investigation and analysis into the Incident or testing defect underpinning the Defect is undertaken
to understand the Root Cause. This may involve engagement of branches or other suppliers to
understand the end to end process affected by the Defect.
Contributors
Internal and external suppliers are both responsible for investigation and analysis of the Defect.
Operations contacts within Post Office may also be consulted to understand any secondary impacts
and the range and scope of these as a result of the Defect.
4.9 Notification of a Defect to Post Office Legal Team
Task Purpose
For each defect that is acknowledged as having the potential to financially impact a branch,
notification MUST be made to our legal team to ensure that the HIJ team are fully aware of any
defects that have the potential to have a financial impact on our branches. This activity is
undertaken using a formal disclosure form indicating the scope and impact of the issue and which
branches are affected if known. This disclosure must be made within 5 days of the socialisation of
the defect to meet the KPI target. (KPIs shown in Appendix A)
Contributors
The Branch Resilience Manager is both responsible and accountable for completing and submitting
the legal disclosure form Informing both the legal team (Stuart Lill) and the Branch Technology
Defects Lead of the submission.
Defects Management Process V1.01.0Page 2 of 231% August 2022
Pos
Offi
ce
Lim
ited -
Doc
um
ent
Cla
ssifi
cati
on:
INT
ER
NAL
POL00337596
POL00337596
4.10 Criticality Scoring of the Defect
Task Purpose
Each Defect will have a differing impact on different areas across the business. It is important that
these impacts are understood and taken into account. A matrix for scoring is sent out to key
individuals in impacted areas to understand scoring against set questions. These questions are held
in Appendix B.
The questions are weighted in favour of the impact felt directly on branches. Where the impact
potentially affects financial balancing, the scoring is weighted 300% to ensure this is give a higher
focus.
Each defect record is also prioritised based on its Impact and Urgency to fix giving an overall priority
score using the matrix below.
Contributors
The below are responsible for the provision of criticality scoring:
e Branch Reconciliation Team : Financial impact on back and front office accounting
e Branch Resilience : Impact on branch and customer experience.
* Comms : Understand if there is any potential for poor press coverage or impact on social
media
e Branch Technology Defects Lead : Was this a contributing factor to a Major Incident or will
this impact on other business priorities if not fixed immediately.
¢ Horizon Architecture Team : To assess if the issue could also affect any other products or
components, including new deliverables in flight
e ITSecurity : Does the Defect represent a security risk to data or access
¢ _NFSP : To assess the impact on the membership and federation of the defect manifesting in
branch.
4.11 Impact Statement Created
Task Purpose
Most defects raised are of a technical nature and the description, root cause and information
provided by suppliers does not reflect the impact actually seen or felt by branch. A statement is
drafted by the Branch Technology Defects Lead to indicate the impact on a branch to allow non-
technical audience to understand what a branch would see or feel to help with prioritisation based
on branch impact. This is completed within 5 days of the defect being formally raised to meet KPI.
(KPIs shown in Appendix A)
Contributors
The Branch Technology Defects Lead is Responsible for the creation of the impact statement. This is
usually understood during the initial HDRF meeting where the issue is socialised where input is taken
(consulted) from The supplier, Service Manager, Branch Resilience Manager, operational teams,
testing, legal and architecture teams to ensure that we fully understand the impact on our branches.
Defects Management Process V1.01.0Page 3 of 231% August 2022
Pos
Offi
ce
Lim
ited -
Doc
um
ent
Cla
ssifi
cati
on:
INT
ER
NAL
POL00337596
POL00337596
4.12 Host of Bridge calls and Workshops
Task Purpose
Some Defects will require more than one supplier to be engaged to diagnose, understand and fix an
issue. The Branch Technology Defects Lead is responsible for chairing and documenting any bridge
calls to allow multiple suppliers to work together and share information, allowing real time decision
making and brain storming of issues.
Contributors
The Branch Technology Defects Lead and Service Managers are both responsible for ensuring that
any bridge calls are arranged, hosted and chaired by Post Office Ltd. Suppliers, operational contacts
and other interested are expected to attend as contributors to the process.
4.13 Horizon Defect review Forum (HDRF)
Task Purpose
The Horizon Defects Review is a weekly forum attended by Post Office and Suppliers to govern the
process of defect management. This includes reviewing any potential new Defect and managing all
open Defects to resolution.
The meeting is held as two distinct parts, the first will focus on the Defects within the Fujitsu scope of
responsibility. Fujitsu’s attendance is mandatory for this part of the meeting. The meeting will then
continue to discuss other non-Fujitsu Defects and Fujitsu will not be expected to attend this part of
the meeting unless a defect is managed collaboratively by both Fujitsu and another supplier.
Meetings are led using Microsoft Teams with Post Office ServiceNow as the central record of each
Defect. Each action is held as an auditable record and updated after each meeting by the Horizon
Defects Review Chair.
The minutes of the meeting are recorded for dissemination to the attendees of the meeting. These
notes will be held centrally on the Post Office Teams Site
Contributors
The Branch Technology Defects Lead is responsible for chairing and documenting the meeting.
Fujitsu and other suppliers are responsible for attending the meeting to socialise and discuss defects
within their scope of responsibility with multiple areas of the Post Office invited and consulted
during the meeting. Key roles expected to attend as documented in the HDRF terms of reference
are:
Role Organisation
Branch Resilience Manager Post Office Ltd
Head of Horizon Live Services Post Office Ltd
Senior Service Manager IT Retail Post Office Ltd
Branch Technology Defects Lead Post Office Ltd
BRT Operations Manager Branch Reconciliation Team Post Office Ltd
Head of Branch Operations Engagement Team Post Office Ltd
Defect & Quality Manager Fujitsu
Service/Technical Management All SuppliersI
Defects Management Process V1.01.0Page 4 of 231° August 2022
POL00337596
POL00337596
4.14 Weekly Supplier Updates (Formal Notification)
Task Purpose
All internal and external suppliers are expected to provide a weekly update on any defects within their scope of responsibility. Internally these updates are likely to be
provided via email or verbally during meetings held to discuss progress. External suppliers are expected to provide a written update, with Fujitsu providing a weekly formal
update with each defect documented as part of a Peak Extract as per below. Each update is recorded within the weekly minutes and where progressing is indicated, this is
updated in the ServiceNow record.
Horizon Defects Review - Fujitsu update report - 01/04/2022 }
Bh catecorf Reference BB Fite Tite Be ocice B woctaoulE Vast [- ea - Pere I
I PREoos0829 ICounters unable to log in following exte riod switche C ] ~-eee aet Yes Yes change since I Targeted at I HNG-x 21.67.01
cures unabie tol infollowingenerdespericdsuinnesot I expen i no cnenge since ovenraea2 [raretes om sen
Icosm deposit and other buttons can be pressed while Help is loading lcosn deposit and other buttons canbe pressed while Help is losing «
rnaoosarse I nt Senos and omer taperence I peozsraus [26m deposi ond one ves No Irocnange since 6/21 frergeea se I HNGx7210 I opeepentsrianem II saemumtrcrsrite
ceeei006: 489539 - Unable to Print Orop & Go Receipt rom a specific wp I!NCBAI008: 489559 -Unable to Print Drop & Go Receipt roma specific] yg, ie scrcece a es
PRC I sorese npeiene I 0296979 Iasoress cee ae HOR Export PERSS7BHAM!
Contributors
Formal updates are the accountability and responsibility of any supplier working to resolve the root cause. The Branch Technology Defects Lead will be consulted where
required to ensure the right level of detail is being provided, with the Branch resilience Manager, Release manager and Service Manager informed throughout.
Pos
Offi
ce
Lim
ited -
Doc
um
ent
Cla
ssifi
cati
on:
INT
ER
NAL
POL00337596
POL00337596
4.15 Root Cause Analysis
Task Purpose
Gold suppliers to Post Office Ltd (Fujitsu, Verizon, DXC and Accenture) provide formal Root Cause
Analysis (RCA) documentation/statements and investigation in the event of a Defect being raised.
The RCA should describe in detail the exact cause of the issue where known. This information should
then feed into the resolution activities and tasks within the Defect Problem record.
Contributors
While the Branch Technology Defects Lead and Service Managers are responsible for the receipt and
recording of the RCA, it is the internal/external suppliers are accountable for performing analysis to
fully understand and document the Root Cause, and understand and document any resolution
activities required to resolve the issue. Upon receipt and review it is the responsibility of the Service
Manager or Branch Technology Defects Lead to agree and accept the RCA.
4.16 Workaround Creation
Task Purpose
To minimise impact on branches a workaround is developed where available to minimise impact
while the Root cause is sought and remedial action taken. This will be recorded in the SNow
Problem record with an associated Knowledge Article created to allow support for users if required.
Contributors
The Branch Technology Defects Lead is accountable for ensuring that all efforts are made to find and
document a workaround by suppliers or internal resolvers. The supplier is responsible for the
creation of any workaround. Once devised and understood, this information is made available to
branches and included in helpdesk scripts drafted by the Branch Resilience Manager and
implemented by the Knowledge Management Team.
4.17 Development of Fixes
Task Purpose
Once the root cause has been ascertained of a defect, where the defect is caused by a technical
defect that requires remediation internal and external suppliers work to resolve the issue through
provision of a fix to the underlying infrastructure or code to prevent recurring issues and incidents
for branches including provision of workarounds where available.
Contributors
Internal and external suppliers are responsible for the provision of technical fixes to defects. The
supplier should consult with the respective architects in their own organisation and within Post
Office to ensure that any proposed fix meets any specific guidelines and does not impact any other
services. The Branch Technology Defects Lead is informed of any progress and route to fix via the
weekly defects update or earlier if required.
4.18 Testing
Task Purpose
Any development of new, or change to existing code must be thoroughly and exhaustively tested to
ensure that the code is fit for purpose, delivers the expected results and does not cause any adverse
effects to other products or services. This testing should be completed before deployment of any fix
and should provide clear and detailed testing documentation including a test exit report. This will be
Pos
Offi
ce
Lim
ited -
Doc
um
ent
Cla
ssifi
cati
on:
INT
ER
NAL
POL00337596
POL00337596
obtained and held on the ServiceNow problem record under a task specifically for collation of Test
and Release documentation for audit.
Contributors
The testing team Managers of both the supplier and Post Office Ltd are Accountable and the teams
themselves Responsible for the thorough testing of any changes and provision of test exit reporting
indicating any test defects and observations relevant to the test that may impact on the delivery of
the fix. Where there are defects and observations these should be indicated to the supplier for
rectification. The Branch Technology Defects Lead will be informed of the status of testing and
provided with test exit reports for inclusion in the Defect Problem Record.
4.19 Release Management — Scheduling and Deployment
Task Purpose
Any fix implemented will require change authorisation via the relevant release/change board, and
where the fix is to be included in a data centre/counter/scheduled release will need to be reviewed
and allocated to a release by the Release Managers of the supplier and Post Office Ltd. Where a
supplier is not part of the IT Change Management process or is a 3 party supplier, best endeavours
to maintain links and understand the changes proposed and to be implemented should be made by
the Service/Release Manager.
Contributors
The Supplier and Release Manager are both responsible for ensuring that the right change
governance and release scheduling is completed effectively. The Change Management team are
consulted to ensure all change tasks are completed and changes ago through relevant forums, and
the Branch Technology Defects Lead, Operational teams and Branch Resilience Manager are all
informed of release schedule for each defect.
4.20 Fix Deployment
Task Purpose
The deployment of the fix developed, tested and scheduled to resolve the root cause of the Defect.
Contributors
The supplier and the release managers are responsible for the successful release of the fix in
consultation with the Change Management team to ensure that the fix is deployed using the right
governance and without impact to other in flight change. The Branch Technology Defects Lead will
be informed of the data of deployment and the success of the deployment into the live environment
for monitoring and review.
4.21 Closure Agreement
Task Purpose
Once a Defect has met either of the following criteria :
1. The Root Cause has been resolved and any secondary issues resolved
2. The Root Cause has been identified and it has been agreed that a fix WILL NOT be
implemented (Current process is to fix all @ April 2022)
3. Root Cause cannot be ascertained and no further instance has been seen (Inconclusive)
Agreement should be sought to close the Defect through completion of the Defects Closure
documentation and circulation to all key stakeholders involved in the defect. Each stakeholder is
Defects Management Process V1.01.0Page 1 of 231% August 2022
POL00337596
POL00337596
Pos
t
Offi
ce expected to read the documentation and respond to the request for closure with their agreement to
Lim close or specify which activities require completion before closure can be agreed. Once agreement
ited - to close is received from all consulted parties, the form is attached to the ServiceNow Problem
Doc record and the defect is moved to Closed Resolved status. A copy of which is attached here
um
ent Wy
Cla HM%20Assurance%
ssifi 20Template.docx
cati
on: Contributors
INT The Branch Technology Defects Lead is responsible for ensuring that the right individuals are
ER consulted to gain agreement for closure of the Defect and Problem record, and to ensure that any
NAL
additional tasks requested at the end of the Problem lifecycle are appropriate to an issue that is
fixed.
4.22 Escalation
Task Purpose
Where traction has not been gained or there is reluctance to engage in the Defects Management
process, escalation to senior leadership should be considered. Initial escalation should be
considered to the Horizon IT Head of Live Service, with further escalation to the Horizon IT Director
should it be required.
Contributors
The Branch Technology Defects Lead is responsible for ensuring that the all avenues are explored
before escalating the issue to senior leadership, including providing an understanding of supplier
priorities. Upon escalation and handover, the senior leadership member become accountable for
ensuring the right focus is maintained by suppliers and stakeholders.
Defects Management Process V1.01.0Page 2 of 231% August 2022
POL00337596
POL00337596
Pos
t
Offi
ce
Lim
ited - Appendix A — KPIs for Defects Management
Doc
um
ent All KPIs are expected to be met at 100%
Cla =
ssifi Activity Target
cati Notification to branches 2 days
on: Knowledge Base Articles completed 2 days
INT Notification to legal team 2 days
ER Criticality scoring completed 5 days
NAL SNow record completed 2 days
Impact statement completed 5 days
Meeting to be held with HDR members I 2 days
recs exmnng Prammracuerats we Lace mary tances oe [aw canon tracaty [nn aac cag mpc on [inatont ot me ste canny ranma mace acne an nme voere ct Looe me stan cones) Dve me ctecttave acs [na ac ve ct ant
Pan in oy Incomattyateesr — [igamatyawenne? [nent lems occa [orerseoresnaincinie [eumontionneamety Ie races say [osnare/ be co pate =
Lowe vont [ran neste cams eee lnnsmpecsn eu einc Ioommemanncnese [frente nent et tre eng enon mo lose execs peat aw [ten machin ov atc tem
Jomo a a ty ro a monenmearats,, [taxwoces NESPRUF ase i Inrones pans so Js panes cng fou Jisetngearwisecsioce — Imoucrsnyewmarces soy
fscawsccot [eomoea sen 3 LF oar = apy
\spebbataial secon net [mn wt mtn
imanes feanes mens sen pmo fens peeeacemaeannnt fies — acon 3 fens
z z re ree pes peso re z a z
Defects Management Process V1.01.0Page 0 of 231 August 2022