FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Changes in v1.2
Changed the word ‘ticket’ to a correct defined term where unclear
Updated the CBIF selection criteria to include BIF explicitly tagged Peaks and moved the
content to Appendix E as a set of work instructions
Added references to using the BIFApproved and BiFRejected Collections
Applied emphasis that defect Peaks can only be closed when the fix is released to live
Updated Appendix A to add steps to challenge “Re-target” and force to PTF
Inserted Appendix B to add anomaly checks for TfSNow
Renumbered Appendix B to Appendix C and updated it to use Live Defect and correct some
grammar errors
8. Response Category value “30 -- Pending -- TL confirmed” will cease to be used
9. Target Release — the values of “Requested For” and “Released at” will cease to.be uSed
10. Removed references to Simon Wilson as the team work for Steve Evans
11. Watermark changed to “POA INTERNAL”
12. Consolidated Peak document update list action into Live Defect Section (moved Root Cause
list to this action)
13. Improved wording to clarify that a Live Defect is one that is present on the LIVE system and
something likely to need a fix (it can also be present.on a test system but if it is not present
on the live system then it is not a Live Defect)
14. Added definition for KBA
15. Updated screenshots to be more specific on the screen item they applied to
16. Updated the descriptive text for the ##LiveAffectingDefect Collection in Peak
17. Removed Root Cause values as reasons to treat as)No Fault Found as too inconsistent at
this time
18. Adding cloning instruction screenshots
19. Added new Response Category “120.-- Final -- Cloned to create Defect Peak” to be used
when cloning an investigation Peak to create a defect Peak
20. Clarified technique for Peaks declared as on “monitor”
21. Added reference to Release Peaks and Peaks that have been Baselined
22. Clarified that only one HDR-* Cl of Collection should be set and if both could apply then use
HDR-Fin
23. Clarified that when Release Management set the Planned Out Live date they use the date
the first time the fix was deployed to the live environment (irrespective of rollout schedules
that may decide on the rollout to the whole live environment)
24. Added.recommendation that Peaks that are resolved but not ready to be closed as the
resolution actionsis to be ‘monitored’ can remain in a non-closed state but must have a
Forecast Date added to the Response so that this warns the support specialist and team
leader that the review date has arrived and the Peak should be reviewed for closure
25. Added statement that Release Management processes will apply to 3 party deployments
that are within the Fujitsu scope of responsibilities. For example, Ingenico fixes will be
deployed under releases and Peaks will be Targeted At, Proposed for, and Reported In
release numbers identified for Ingenico fixes — currently 90.xx
26. Corrected the incorrect references to RAM/RAB
27. Added new step that on a release, SSC will ensure relevant KBA updates are checked and
completed
28. Added new approach for progressing fixes through the release process faster — with
consideration for a hot-fix
29. Added a screenshot for the Release Management “Reset Dates” feature
30. Added screenshots to explain the difference between an internal Fujitsu Progress update and
a replicated Response update
No
IO nb wo
Page I 1
Version & Last updated: See file n
Document owner Steve Bre
31.
32.
33.
34.
35.
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Enhanced the description of the HDR report generation process and moved to Appendix D as
a work instruction
Revised the description stating deferred Peak as always Live Defects — some are not if they
relate to test environments
Added process for Live Defects where no fix action is proposed
Numerous updates to Appendices to make them actionable Work Instructions
Updated Actions, removing ones completed
Changes in v1.1
1.
Split Streams 5-7 to a new document
2. Added What’s New to provide a pseudo Executive Summary for new read@s before they
delve into the detail
3. Added screenshots and diagrams to aid understanding
4. Removed requirement for Development (ManDays) to be entered on hy Peale gnd also
removed Development (ManDays) as a criteria for submission fCBIF
5. Refined criteria to be reviewed at BIF to guide what is takepsto CBIR,
6. Added additional references for Response Category and ROat CatiSe-field values
7. Added additional clarification that deferred Peaks thatystilirequie investigation are assigned
Call Type “L” not “#”
8. Added guidelines for use of the “Additional comments@ustomer visible)” field in TfSNow
9. Added criteria currently being used to derive e@ntent for @BIF and HDR
10. Added Appendix A to show some data valigatiOf@ehecks that certain teams are advised to
build in to and expand upon within theig@wn local progésses
41. Added Appendix B to show draft criteffa fof Mot acting on defects — the potential policy we will
write to remove any subjectivity frormdecisionspto close defect Peaks or not open Peaks from
Jiras
12. Updated Actions
Page I 2
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Contents
Introduction...
Terms and Terminolog)
New terms..
Terminology — Overview...
Systems and Teams..
Managing Incidents....
Managing Problems......
Actions..
System Changes..
New Ways of Working.
Managing Peaks.
Release Management...
Actions
System Change:
New Ways of Working
Live Defect Management — Live Defect Definition......»
Live Defect Management — Goals...
Live Defect Management — Key Fields in Peak..
Live Defect Management Reporting..
Actions.
System Changes.
One-Time Actions.
New Ways of Working.
BIF..
CBIF....
PTF.
HDR...
KB — Info only...
Release Mgt tab — for BIF, CBIF and PTF..
CBIF / HDR Diagram...
Actions.......
System Changes.
Page I 3
Version & Last updated See file n
Document owner Steve Bre
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
One-Time Actions....
Appendix A — Peak data anomaly checks...
Appendix A — Peaks closed that POL should consider following up on.
Appendix A — Release Management checklist. .49
51
. 52
Appendix B — TfSNow data anomaly checks
Appendix C — draft criteria for closing Defect Peaks with NO action
Appendix D - HDR Report Creation Work Instructions.
Appendix E - CBIF Submission Extract Work Instructions.
Page I 4
Steve B
ed: See file name
FU,
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Introduction
This document describes a number of improvements to the Post Office Account ways of working to
enhance the end-to-end process of Live Defect Management. It describes how the systems should be
used and how various teams will need to interact to ensure an effective end-to-end process is
followed and can be tracked and reported on.
A PPT has been created for a quick overview.
Our interactions need to be system and process driven, not people and experience — and that will
create a clear audit trail too.
We need to limit the dependency on meeting-specific reports or embedded tables in minutes ‘to show
progress on important matters.
Transparency is key — to the fullest sensible extent, POL need to see everything = and they need to
be able to see it in their systems or from consistent reports from our.systems. That way, POL are
informed and able to make decisions for us or with us.
Terms and Terminology
New terms
Throughout this document, there are new terms and phrases that will need to be understood so we
increasingly use a common language. A diagram is provided below this list. The main ones are:
e Live Defect — is a logged Incident that is present on the Live system that is within Fujitsu’s
scope of obligations and is, or appears to be, inconsistent with the agreed design or service
specification. It is, therefore, a fault thatis likely to need fixing
e HDR Defect - Live Defects that affect, or have the potential to affect, branch operations
(financial, experience, or end customer)
e Horizon Defect Review (HDR) — aweekly meeting with POL to review HDR Defects. POL
need to know the HDR Defects and their status. They share this with postmasters. This is a
very important meeting that Sees Fujitsu and POL aligned on the HDR Defects
e Investigation Peak — is an Incident that is being investigated where the cause and required
action are not yet confirmed. A linked TfSNow Incident may well exist - and MUST exist if
POL need to be aware. The Peak Call Type should be “L” if this is a Live Defect
¢ Defect Peak =is.a Peak that is not linked to a TfSNow Incident and that describes the
confirmed Live Defect that will be progressed through the SDLC (BIF, PTF, Dev, Test,
Release) to live deployment
« Investigation Incident (TfSNow) - is an Incident that is being investigated where the cause
and required action are not yet confirmed. The Incident MUST be bonded if POL need to be
aware
« Defect Incident (TfSNow) — is a TfSNow Incident that describes the confirmed Live Defect
that will be progressed by a Resolver Group that does not use Peak (e.g. Networks, Security,
Unix)
e Potential Live Defect (Peak) — is a Live Defect that we are still looking into. There will likely
be an investigation Peak open and probably a TfSNow Investigation Incident too. The Peak
Call Type should be “L”
« Confirmed Live Defect (Peak) — is a Live Defect where the cause and required action to fix
are known. The investigation has concluded. A defect Peak will exist with Call Type “#"
Page I5
Version & Last updated See file n
Document owner Steve Bre
FUJ00232758
1J00232758
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e Potential Live Defect (TfSNow) - is a Live Defect that we are still looking into that is logged
as a TfSNow Investigation Incident. The State will be “Acknowledged, Work in Progress, or
Researching”
e Confirmed Live Defect (TfSNow) — is a Live Defect where the cause and required action to
fix are known. The investigation has concluded. A TfSNow Defect Incident will exist with the
State field set to “Fix in Progress”
e KBA- Knowledge Base Article. The term KEL is no longer to be used
Terminology — Overview
We need to be clearer and consistent about what we mean by, and how we use, various tools and
processes within POA. The following entries are intended as an initial simple summary. They will be
expanded on as the workstreams progress and sub elements will also be reviewed too: They cover
Incidents, Problems, Peak, Release, Live Defects, Live Defect Management, BIF, CBIF, HDR and
the KB.
Incidents
o All Incidents which POL should be aware of must be created and:managed in TfSNow and be
bonded so that they replicate to POL ServiceNow. Although actions and progress may
happen in other tools, systems and processes, the primary source)of all relevant content
MUST be TfSNow.
lems
o All Problems must be raised in TfSNow and be reviewed on an agreed schedule with POL.
As Problems cannot be bonded, additional work will be needed to manually share updates
and hold mutual reference numbers.
o Peaks can be used for many,purposes. Where Peaks relate to Incidents initiated from
TfSNow, the relevant Investigation Peak updates MUST be synchronised with TfSNow.
Peaks raised outside of an Incident MUST also be raised as TfSNow Incidents if they require
the awareness or involvement of POL.
Peak is the only system used.to record and manage Live Defects.
o Peaks do notyneed to be shared with POL. If the awareness or involvement of POL is
applicable then there will be a TfSNow bonded Incident and this will contain all relevant parts
of any Peak so that the Incident that POL see is a suitable complete reference. Progress
updates for POL on HDR Defects will take latest extracts from the Peak system and provide
the update in a report.
°
o Release Notes must state all Peaks that are being closed when the Release goes live. This
must be included in the related Change ticket
co There must be a report showing the Peaks and any associated POL HDR Defect references
so that POL are able to keep their tracking in sync
o Release dates must be held in Peak so that Peaks can be tracked to deployment
o ALive Defect is defined as an issue that:
e Is present on a LIVE system
e Is within Fujitsu's scope of obligations
e Is, of appears to be, inconsistent with the agreed design or service specification
e Is, therefore, a fault that is likely to need fixing
Page I6
Version & Last updated See file n
Document owner Steve Bre
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
« The Horizon Defects Review (HDR) scope will be those Live Defects that also have
at least 1 of the following attributes (HDR Defects):
= Affects, or has the potential to affect, branch financial outcomes (add the
“HDR-Fin” Collection)
= Affects, or has the potential to affect, the way a postmaster is required to use
the system (User Interface, Report, Function) (add the “HDR-Exp”
Collection)
= Affects, or has the potential to affect, the experience of a Post Office
customer or client (add the “HDR-Exp” Collection)
Note: Only one HDR-* Collection needs to be set and if both could apply then HDR-Fin should
be chosen
[Add Incident to Collection
HOR-Exp -- Horizon Defect Review - SPM Experience [Public] I Ad
cs
jorizon Defect Review - SPM Experience [Public]
jorizon Defect Review - Financial Impact [Public]
HOR-Exp ~
Hl
e There may be a workaround, but the underlying ‘issue still meets the criteria above
e The HDR Defect may be under investigation and is not confirmed to meet the criteria
above but has attributes that meet the criteria above (a’potential HDR Defect)
o When the HDR Defect is being investigated there will be a TfSNow Incident open and
bonded. POL may track status using their ServiceNow Incident reference or may create a
ServiceNow Problem record and manage it with that reference. All progress during
investigation is to be added to the TfSNow Incident so that it is visible to POL in their
corresponding Incident. It is POL's responsibility,to keep their Problem record up to date if
they have opened one.
e Note: If the Incident has been escalated to a Problem in TfSNow then updates on the
investigation work willbe provided within the weekly status update report which
shows confirmed Live Defect
o When a HDR Defect.is confirmed then a specific defect Peak reference will be added to the
closing comments in the’ TfSNow Incident. Fujitsu will then manage the HDR Defect in Peak
and will provide status update reports — from Peak — to POL at their weekly HDR Forum.
o Non-HDR Defects will be managed internally by Fujitsu using Peak. Reports will be available
for POL to show overall progress but it is not intended that every non-HDR Defect will be
discussed.
Live DefecRManggeme!
o All Live Defects must be rigorously managed until resolved.
co The status of all Live Defects must be known at all times and they must be shared with POL:
the more branch impacting ones at POL’s Horizon Defects Review Forum; and the rest by a
separate report. Fujitsu must assure POL that Live Defects are well managed and must keep
POL aware of progress.
o All confirmed Live Defects must go through the Business Impact Forum (BIF) and must have
all the required meta data and tags added/checked.
co The dates of BIF meetings, the outcome, and the reasons for CBIF submission must be
recorded in the Peak.
CBIF
o CBIF submissions will be based on criteria held in Peak.
Page I7
1 & Last updated: See file n:
vent owner Steve Bre
KB
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
The criteria are shown later in this document and that criteria will be agreed with POL.
CBIF will become part of the POL HDR weekly meeting.
The Horizon Defects Review (HDR) Forum is the new name for what was the Known Error
Review Forum (KERF).
This is a critical meeting which sees POL and Fujitsu having mutual awareness of the main
Live Defects and the progress being made on them.
It is a joint weekly forum to manage HDR Defects that meet the stated definition.
POL will maintain a list of all HDR Defects and their progress. Fujitsu will provide updates to
the HDR Defects being tracked.
There must be a POL Problem reference and a corresponding Fujitsu Incident; Peak,or
Problem reference.
The updates to the Fujitsu tracked Incidents, Peaks and Problems will be shared at the HDR
Forum.
The Fujitsu KB is an information repository used for support purposes.
Any observed defects will be recorded as a Knowledge Base Article (KBA) but the progress
to investigate and address them will be done via Peak(s) and/or Incident(s).
KBAs do not need to be shared with POL as the tracking needs to be on the Peak and/or
Incident.
If the awareness or involvement of POL’ is,applicable then there will be a TfSNow bonded
Incident and this will contain all relevant parts.of any KBA so that the Incident that POL see
is a suitable complete reference.
Page I 8
1 & Last updated: See file ni
ent owner Steve Bre
FU,
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Systems and Teams
Managing Incidents
°
An Incident is defined in the HNG-X contract as “any perceived abnormal or undesirable
occurrence relating to the Services”
Incidents for the Live environment that POL need to be notified of and be aware of must be
logged in the Fujitsu service management toolsets, TfSNow, and bonded so it is visible in the
POL service management toolset, ServiceNow
Fujitsu must ensure TfSNow Incidents are raised and bonded where POL notification is
required (e.g. when relevant KBAs are created, or faults are identified whilstdoing other work
such as testing or problem determination)
Service Operations should only use TfSNow for communicating Incidentsbetween Fujitsu
and POL
Incidents cannot be raised by email by POL or Fujitsu. Incidents must be raised in TfSNow
by Fujitsu or in ServiceNow by POL
The Summary field should be understandable by most readets.as this feeds Peak and also
shows on reports
e For system monitoring this is set by SMC, bonded Incidents it comes from POL,
otherwise it’s Fujitsu staff (MAC & Security) that choose its content
The Incident should be a complete and comprehensive self-contained reference to the status
of an Incident
Incident progress MUST be shown on.the Incident in, TfSNow and cannot be managed via
separate emails. Emails must be added to the Incident in TfSNow if relevant to
demonstrating progress or status
The Incident should appear to be integral = the fact that 3° and 4" line use a different toolset
should not be apparent
There should be no references visibleto POL (going forward) to toolsets used by Fujitsu that
are not accessible to POL such as)Peak or KBA for status information (as these are Fujitsu
internal) — a Peak reference is acceptable for a reference to a defect Peak that is being
progressed. References for Fujitsu use only must be maintained
Incidents mustibe updated to contain relevant updates from systems such as Peak (but not
private updates) and relevant parts of KBAs (not the internal instructions)
Incidents raised as Fujitsu internal that do not need to be notified to POL may contain
internal system references
Incident updates should contain meaningful and appropriately detailed technical content
Incident updates, and in particular updates summarising the current status, should be written
in plain English to be understandable to most readers
A clear statement of the latest status and the next action should be obvious within the
Incident. This needs to be the last, or very recent, update
« The “Additional comments (Customer visible)” field must provide a latest status view
— at least periodically and for POL bonded Incidents mainly — so it can be easily
understood by any reader. Peak uses a dedicated field for this and uses the following
format:
= Business impact: [description of the business impact, succinct]
= Status update: [description of current status — succinct]
= Next action: [next action to be taken and expected date for next update]
For bonded Incidents we need to use the agreed set of categories, sub-categories and Cls so
that the replication interface retains the settings. The original setting will stand throughout the
Page I 9
Version & Last updated: See file n
Document owner Steve Bro
FUJ00232758
1J00232758
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
life of the Incident. You cannot change the Category/Sub-Category or it breaks the replication
link. You can change the Cl but it will be retained Fujitsu side but will not replicate
o We need to use the designated open and close categories to better monitor Incident
categories
e® Open category — TfSNow has Configuration Items that should be used
Closure code — TfSNow has these and they should be used
co The Peak closure codes must map to TfSNow Incident closure codes. As at the date of this
document the mappings are as follows:
Peak Closure Code
Fujitsu
Advice after Investigation
POA-Advice & Guidance
Avoidance Action Supplied
POA-Fujitsu Operational
‘Administrative Response
POA-Administration
Advice and guidance given
POA-Advice & Guidance
No fault in product POA-No Fault Found/No Action.
Taken
Duplicate Call Cancelled
Solicited Known Error POA-Advice & Guidance
Insufficient evidence Unidentified Root Cause
Fix Released to Call Logger POA-Peak Fault Found
User error POA-User Error
Unspecified Insufficient evidence I Unidentified Root Cause
Call withdrawn by user Cancelled
Fixed at Future:Release POA-Peak Fault Found
Enhancement Request POA-POL domain
Suspected hardware fault Unidentified Root Cause
o Incidents outside of the Fujitsu domain that are identified by Fujitsu are passed to POL
ITDSD. If there are no consequential implications for Fujitsu then the TfSNow Incident will be
set to Suspended to await feedback to help us advance our KB (perhaps for the agreed
Suspend period and then we close). If there are implications then we leave the Incident open
as we need to know the outcome
o Only the originating organisation can close an Incident
e Incidents we have marked as requiring a fix should be closed in TfSNow with the
defect Peak reference added as that is what will be tracked and managed to
conclusion
e For Incidents closed that relate to process or user issues then we should propose
system improvements — and this should be done in conjunction with an equivalent
process for Peaks closed with the same reasons
o Fujitsu will set an Incident to Suspended in TfSNow until POL close their original Incident
* Note: Resolved in TfSNow only means that the last assigned Resolver Group has completed
their action — but it may require other actions by other Resolver Groups. Therefore, Resolved
Page I 10
See file name
Steve Browell
Version & Last ups
Document owner
dated
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
is not replicated to ServiceNow or POL will wrongly assume it is Resolved and will likely close
their Incident. When all possible actions are complete and MAC believe it is truly Resolved
then they will request POL to close it.
¢ When POL close an Incident it notifies MAC and MAC can then close the TfSNow
Incident
e Incidents in a Suspended state are reviewed weekly between the MAC and POL
teams and it is included in the monthly SMR pack
= Where the Incident is Suspended as no further action by Fujitsu is possible
then after 10 days the Incident will be closed. When the Incident is set to
Suspended the following text will be added as the final update “Please be
aware that the incident will automatically be closed after 10 days if no
response is received from you.”
o Fujitsu must tag Incidents that POL are tracking (mostly for HDR) so, itis aware of Incidents
where POL have an interest so that it can review content and status frequently. Adding any
relevant POL references, such as the POL Problem reference, should be considered
o ALive Defect is defined as an issue that:
e Is present on a LIVE system
e Is within Fujitsu’s scope of obligations
e Is, or appears to be, inconsistent with the agreed design or service specification
e Is, therefore, a fault that is likely to needsfixing
e Incidents that meet the definition of a‘Live Defectmust have the
“LiveAffectingDefect” Cl added in TfSNow
« The State field values must be used
State Work in Progress v
= Acknowledged = Fujitsu is aware of the Incident but is not yet working on it
= Work In Progress/Researching — Fujitsu is investigating the issue described
in the'Incident
« Fix In Progress — Fujitsu has confirmed that the Incident requires an action to
fix it — most likely linked to a Change ticket
= Suspend — action is complete by Fujitsu or is required from another entity
e AnJncident that has the LiveAffectingDefect Cl and State of Acknowledged/Work In
Progress/Researching is a potential Live Defect. Suspend will also be classed as a
potential Live Defect too for simplicity
« » An Incident that has the LiveAffectingDefect Cl and State of Fix In Progress is a
confirmed Live Defect
o The POL Horizon Defects Review scope will be those Live Defects that also have at least 1
of the following attributes (HDR Defects):
Page I 11
Version & Last updated: See file n
Document owner Steve Bre
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
= Configuration items Search Name
1 to200f1,235 >
F Ail>Name>=HoR
QS Name a Sssettag —-Seriatnumber = Company = Managed by
Search Search Search Search Search
@ = HOR-ExP POA (empty
@ REN BOA fomety
e Affects, or has the potential to affect, branch financial outcomes (add the “HDR-Fin”
Cl)
« Affects, or has the potential to affect, the way a postmaster is required to use the
system (User Interface, Report, Function) (add the “HDR-Exp” Cl)
e Affects, or has the potential to affect, the experience’of,a Post Office customer or
client (add the “HDR-Exp” Cl)
Note: Only one HDR-* Ci needs to be set and if both could apply then HDR-Fin should be chosen
o When the HDR* Cl is applied to an Incident, Fujitsu MACG.will also email the Fujitsu Duty
Manager email alias and a POL designated,alias to provide an email early warning that a
new HDR Incident has been raised
o Incidents carrying a HDR* Cl will have the POL Problem references added to the Incident to
enable cross-checking
o Incidents carrying a HDR* Cl will still be.classified as potential or confirmed Live Defects
using the classifications mentioned above
o Peaks that are cloned that have a ServiceNow reference cannot be closed by EDSC until the
cloned Peak that was created isjalso closed or has its Call Type changed to “#”. The original
Peak must be kept open until the cloned Peak is closed and updates must be applied to the
original Peak so that the,related TfSNow and ServiceNow Incidents continue to receive
updates. For Peaks cloned for.GDC for GDPR obfuscation reasons this will only apply up to
April 2020 as*from that date the original Peak was obfuscated and a clone was not created
o Peaks that are closed that have a ServiceNow reference with the reason being that a cloned
Peak is now to be tracked will be sent back to Peak by MAC to reopen the Peak as this must
be maintained,to ensure the continued automatic flow of updates to the originator
o Recurring Incidents and Incidents with follow up actions require a Problem record to be
created. The Incidents are linked to the Problem
o To ensure we avoid updates being overtly associated with an individual, meetings, updates,
and reports relating to Incidents must be system driven from the relevant toolset — not
separate emails or meeting comments
o Weneed management reports for Incidents to see trends. This needs to be part of the
monthly SMR and/or internal Service Operations meetings:
e® Open, Active and Closed Incidents
e Live Defect Incidents — potential and confirmed
e HDR Defects — potential and confirmed
« For each, show views based on:
= Open category & Close codes
= Cl associations
« — Internal response times by type/priority
Page I 12
Version & Last updated See file n
Document owner Steve Bre
°
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
= Branch Code - an Incident may relate to one FAD (Branch Code will be set to
the nnnnnn FAD by either Fujitsu or POL) but it may relate to many FADs
(Branch Code set to POA SMC by Fujitsu or MAC by POL)
Service requests should not be accepted as Incidents, but whilst they are very few (those that
relate to investigations are now re-directed through other channels) this will be accepted and
reviewed periodically
Managing Problems
Problems must be logged in the Fujitsu service management toolset, TfSNow
Problems cannot be bonded, like Incidents, to cause mutual replication between the Fujitsu
and POL service management toolsets so each organisation needs to maintain its own
records independently
POL need to provide their Problem reference for Fujitsu to record and link to its own Problem
& POL also may need to provide status updates back to Fujitsu —- we need to escalate POL
inefficiencies at SMR as well as at the inter-company Problem Review Meeting
Fujitsu internal Problems are managed entirely in TfSNow.
If a Problem is tracking a Live Defect then the Problem needs, to hold the Peak reference as
that is where progress will be actively updated and reported
Peaks related to Fujitsu Problems will need to have the Fujitsu Problem reference added so
the association is clear when checked from either system.
Note: Fujitsu use Problem tasks and manage the updates to those
Major Incidents will lead to Problems being raised to close out on all findings
Fujitsu MAC will notify Problem of underlying issues identified from Incidents -these tend to
relate to Unix, NT etc (TfSNow Resolver Groups) and no Peaks (Peak has its own processes)
Problems also use the State field - Acknowledged, Work In Progress, Researching, Fix In
Progress, Suspend — to record’and'track status
The Problem should have the applicable Configuration Item assigned (HDR Defects):
°
°
°
°°
°
°
o
v
Configuration Items
Search Name
1 to 200f1.235 >
All> Name >= HOR
4 Name a S Asset tag = company = Managed by
Search Search earch Search Search
@ ioR-exP POA (emnpty)
@ HORAN POA (empty)
Affects, or has the potential to affect, branch financial outcomes (add the “HDR-Fin”
cl)
Affects, or has the potential to affect, the way a postmaster is required to use the
system (User Interface, Report, Function) (add the “HDR-Exp” Cl)
Affects, or has the potential to affect, the experience of a Post Office customer or
client (add the “HDR-Exp” Cl)
Note: Only one HDR-* Cl needs to be set and if both could apply then HDR-Fin should be chosen
Problem reporting should have HDR tagged Problems
Incidents where the resolution is a fix to address a Live Defect may be both a Peak anda
Problem (the former for management, the latter for joint process validation)
Page I 13
See file n:
Steve Bre
Version & Last updated:
Document owner
Actions
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
System Changes
¢ Added Cls for HDR-Exp, HDR-Fin, LiveAffectingDefect
New Ways of Working
1. Sandie - We need to regularly check
that any Incident that POL need to be notified of or be aware of has been logged in
TfSNow and bonded
that we do not reference KBAs, Peaks or include internal content in TfSNow bonded
Incidents and that the TfSNow Incident contain all relevant contentand be a
comprehensive self-contained reference to the status of an Incident. The only Peak
reference that should be added is for defect Peaks (if applicable).
Incidents are being updated and that we are not using separate emails.to share
progress that is not embedded into the Incident updates
Incident updates are well worded and use language. that is understandable to most
readers — challenging and coaching where needed
the current status and the next action on an Incident is clearly stated so any reader is
in no doubt that the Incident is under full control — challenging and coaching where
needed
the Summary field is well worded and‘understandable by most readers
the relevant open and close categories are being used when handling Incidents —
applying additional caution withybonded Incidents to use the mutually agreed settings
the LiveAffectingDefect Cl is being set for Live Defects
the HDR* Cls are being set by,Fujitsu management where applicable (and that the
POL Problem References also added to the Incident)
when an Incident is,placed,into Suspend as no further Fujitsu action is applicable
then the text of “Please be aware that the incident will automatically be closed after
10 days if no response isyreceived from you.” has added. After 10 days, these
Incidents should be closed
2. Sandie/Steve Ba — create.a process/report to share Incidents and Peaks closed due to
process or user issues with POL monthly to encourage POL to consider system
enhancements that could avoid the occurrence of the issue
Page I 14
Version & Last updated: See file n
Document owner Steve Bre
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Managing Peaks
co The use of Peak and the updates to Peaks must be consistent and documented. That takes
the onus off the people and it enables anomaly reporting and management oversight
o If the awareness or involvement of POL is applicable then there will be a TfSNow bonded
Incident and this will contain all relevant parts of any Peak so that the Incident that POL see
is a suitable complete reference
co If any 3LS, 4LS or Architect creates a Peak in the course of their normal duties that matches
the definition of Live Defect:
« Is present on a LIVE system
e Is within Fujitsu’s scope of obligations
e Is, or appears to be, inconsistent with the agreed design or service specification
e Is, therefore, a fault that is likely to need fixing
...then it must be given the ##LiveAffectingDefect Collection and an Incident must be raised
in TfSNow if one is not already open.
co Ifa Peak has had the ##LiveAffectingDefect Collection added, and it also has at least 1 of
the following attributes (Horizon Defect Review)?
e Affects, or has the potential to affect, branch financial outcomes (add the “HDR-Fin”
Collection)
¢ Affects, or has the potential to.affect, the way a postmaster is required to use the
system (User Interface, Report, Function) (add the “HDR-Exp” Collection)
e Affects, or has the potential to affect, the experience of a Post Office customer or
client (add the “HDR-Exp” Collection)
Note: Only one HDR-* Collection heeds to be set and if both could apply then HDR-Fin should be
chosen
IAdd Incident to Collection
HDR-Exp — Horizon Defect Re
[Add to Collection I
2w-SPM Experience [Public] I
7
jorizon Defect Review - SPM Experience [Public]
jorizon Defect Review - Financial Impact [Public]
o If a Peak raised independent of TfSNow is subsequently qualified as being an Incident that
POL should be aware of, then Fujitsu MAC need to be contacted. Fujitsu MAC will create a
new TfSNow Incident which will be bonded and then assigned to 3LS. This will create a new
Peak. The content of the original Peak must be copied to the new Peak so that updates can
automatically flow back to TfSNow. The original Peak should be closed citing that it has been
superseded by a Peak linked to TfSNow
o When the investigation into an issue defined in a Peak originating from TfSNow is concluded,
the ‘investigation’ Peak can be closed
e If the investigation Peak is an existing clone then the Peak can have its Call Type
changed to “#” (for GDC obfuscated Peaks this will apply to any cloned Peaks
created prior to April 2020)
e The investigation Peak has not been cloned then it needs to be cloned to create a
defect Peak (for GDC obfuscated Peaks this will apply to any Peaks obfuscated
since April 2020)
Page I 15
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
« The defect Peak reference should be added to the investigation Peak as part of its
closure activity. The defect Peak reference will then be mentioned in the TfSNow
Incident so that it replicates to POL ServiceNow
co The interface between TfSNow and Peak (OTI) must protect the internal system references
to Peaks or KBAs and updates should appear to all be generated in TfSNow — except for a
reference to a defect Peak that is shared for future tracking purposes
o The Summary field needs to be written so as to be understandable to most readers as it will
be used in internal management and external POL reports
o New fields are being introduced to help Live Defect Management tracking and reporting and
these will need to be completed by various parties as the Peak progresses
e See section Live Defect Management — Key Fields in Peak
o Cloning processes and rules need to be applied consistently:
* Cloning carries forward all Collections, References and Key Fields.and it must show
cloned from and cloned to support chain of events tracking
* Cloning should be for specific purposes and the reason will appear as a prompt when
cloning is initiated:
= Assignment to GDC (so we can redact/obfuscate)
* Note: Since April 2020 UK Bridgé do\not clone Peaks but instead they
obfuscate the original so it can be widely sharéd and updated whilst
maintaining any links to TfSNow Incidents. Peaks cloned prior to this date
that remain open will have broken the auto links to any TfSNow Incidents
« — Splitting into multiple threads linked to a single origin (e.g. Data Centre &
Counter, phased fix — urgent perhaps by script/refdata and follow-on for
code)
= Disassociating from the TfSNow incident (e.g. documentation, follow-on to
an initial response to an)incident)
= Creating the defect Peak to progress the Live Defect to resolution
= Creating Test,Only Peaks where the test in a particular environment can’t
mirror the entirety of the issue described e.g. 3° party connections are not
available. This is rare. Testing is then done on the clone in that environment.
The master defect Peak is still open as it may be used for the full testing in
LST. The Test Only Peak will be closed once testing is completed
successfully
* Note: ifa Peak has been assigned to a Baseline then cloning should be done
with caution and include consultation with the Baseline owner in advance
* When,the{Clone] button is clicked, the following menu is displayed:
Select Clone Reason:
ISplit into multiple streams
\Disassociate from TfsNow ticket
\Test rig reasons
IOther
Enter new clone Summary
Page I 16
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
« The user selects from the list (“Create a Defect Peak” is the default option), amends
the Summary to give the clone a different and helpful title, and clicks confirm. The
reason is captured in the clone Peak:
Date:11-Aug-2021 99:00:38 User: John Simpkins
CALL _PCO25@898 opened
Details entered are:-
Isummary:test mb problem
call Type:#
call Priority:D
Target Release:HNG-X 12.11
Routed to:EDSC - John Simpkins
Date:11-Aug-2021 09:00:38 User: John Simpkins
Clone Reason: Create a Defect Peak
Date:14-Dec-2015 15:52:55 User:_Customer Call_
CALL PC0244669 opened
Details entered are:-
iSummary:test mb problem
e If the Defect reason is selected, the clone will be created with Call Type ‘#’.
o Peaks raised in Test or Dev that also relate to the Live environmentwill not have Call Type
‘cL.
¢ Test will raise a new Peak within the release being tested for unexpected Live
Defects and then assign it to the Developers. It has a Call Type “P” by default
« The Developers & Architects decide if it relates to Live and must set the relevant
Live Defect meta data as described above
o Peaks that are cloned that have a ServiceNow reference cannot be closed by EDSC until the
cloned Peak that was created is also. closed or has its Call Type changed to “#”. The original
Peak must be kept open until the cloned Peak is,closed and updates must be applied to the
original Peak by EDSC so thatthe related, TfSNow and ServiceNow Incidents continue to
receive updates. For Peaks,cloned for GDC for GDPR obfuscation reasons this will only
apply up to April 2020 as from that date the original Peak was obfuscated and a clone was
not created
o Peaks that have been held by EDSC due to having been cloned and having a ServiceNow
reference must be periodically reviewed to ensure updates from the cloned Peak are applied
o Peaks that are closed that have a ServiceNow reference with the reason being that a cloned
Peak is now to be tracked will be sent back to Peak by MAC to reopen the Peak as this must
be maintained to ensure the continued automatic flow of updates to the originator
o Rules,on use of Call Type need restating so we ensure greater consistency
o All Peaks must be owned by a team whose manager will check that progress is being made
We need regular management quality checks — use of fields, age of Peaks, progress being
made —and this needs to be summarised and reported upwards to ensure executive visibility
and confidence
e The report created by Fujitsu MAC is useful but does not appear to cause action to
be taken
co The origin of a Peak - SPM, POL, SMC, Fujitsu — is identifiable by scraping the Contact
Name: field — but this cannot be done using standard Peak reporting and requires a custom
script to be run. This has been created to help the POA Defect Manager report on this
content
©. ‘Private’ Peak updates can be added to the Progress field. They stay in Peak and are not
replicated across the OT!
Page I 17
1 & Last updated: See file ni
rent owner Steve Bre
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Just for info based upon this meeting. When adding progress to a bonded’ Peak the default
response option is '-- Progress Only’ this does NOT flow back to Peak.
Prope Tepines
‘Nowe Thus m an OT1 Provider lacie
= Promtens Oat opts wl ot be tothe Comme
1 eng Respoces wil be set tthe Conse
{Fal Responses lpn the meses ck te Commer
(doe be Poa
En fou
Deseipeet eB) ibe
ine eee] ssee
Edited
Note the Text on the right-hand side of the progress entry box for further guidence.
Ifyou select a response category then the text above the Progress changes to reflect this:
(C Respnee Tet yun pit ii be sso OTF Commer
—
epdter wl wtb wet the Cooner
1 PeadieRespnne lest tote Conan
aspan Coe 7 ie oa)
a
Fercon Doe Devcon May) Fret De
ae
No references will be sent across to TFSNow (or beyond) so all Documents, Baselines, KBs, Peak etc
can be added as references
Updates added the Response’field are replicated across the OT!
o The References field is manually maintained so can miss Incident or KBA references. SMC
may add KBA into reference text instead of into the References field which limits query-
ability
o Peaks closures;
«, Ancident related Peaks are closed when the investigation phase has concluded and
no further action is needed, when further info required (as it passes back to TfSNow),
or when the next action needs to be assigned to another TfSNow Resolver Group
(the Peak is no longer needed)
e Incident related Peaks are closed when the investigation phase has concluded and
we have a confirmed Live Defect. This would see a cloned Peak raised as Call Type
“#". If the Peak is not linked to a TfSNow Incident bonded to POL then the Peak can
just be reassigned to Call Type “#”
« Defect Peaks are closed when the Release they are targeted at is deployed —
ideally by automating the process — this will probably be Peaks at Status “F”
e All other Peaks are closed based on team/process specific rules — as per current
processes
o Peaks closed as user/process error should be considered along with TfSNow Incidents closed
for the same reasons to provide a monthly report to POL to recommend enhancements that
°
Page I 18
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
could avoid the occurrence of the issue. A likely source of these could be Peaks closed with
the following Root Cause values:
e “39 General — User Knowledge” — caused by lack of knowledge with the user
e “40 General — User” - caused by an action performed by the user which was
outside expected use
e “41 General — in Procedure” — caused by not following defined procedure
Peaks/Incidents closed as “66 — Final - Enhancement Request” should also be reported on
monthly to POL to recommend enhancements are submitted to Fujitsu. KBAs also needs to
be updated to show the outcome was that POL need to raise an enhancement request
Peaks that are resolved but not ready to be closed as the resolution action is to be
‘monitored’ can remain in a non-closed state but must have a Forecast Date.added to the
Response so that this warns the support specialist and team leader that the review date has
arrived and the Peak should be reviewed for closure
The Peak closure codes must map to TfSNow Incident closure codes. As at the.date of this
document the mappings are as follows:
Peak Closure Code Fujitsu
‘Advice after Investigation
POA-Advice& Guidance:
Avoidance Action Supplied
POA-Fujitsu Operational
‘Administrative Response
POA-Administration:
Advice and guidance given
POA-Advice & Guidance
No fault in product
POA=No Fault Found/No Action
Taken
Duplicate Call Cancelled
Solicited Known Error POA-Advice & Guidance
Insufficient evidence Unidentified Root Cause
Fix Released to Call Logger POA-Peak Fault Found
User error POA-User Error
Unspecified Insufficient evidence I Unidentified Root Cause
Call withdrawn by user Cancelled
Fixed at Future Release POA-Peak Fault Found
Enhancement Request POA-POL domain
Suspected hardware fault Unidentified Root Cause
o An Incident may relate to one FAD but it may relate to many FADs - this is recorded in the
Business Impact text showing the number of branches affected
o To ensure we avoid updates being overtly associated with an individual the updates should
be system driven — not separate emails or meeting comments
o For the occasions where Fujitsu is required to share actual Peaks, it will need to define a
Peak extract process that will brand, classify and version control content. The process must
also redact/obfuscate to remove Pll and remove internal only Progress updates. This extract
process is not under consideration as at the date of this report
Page I 19
dated: See file name
Steve Browell
Version & Last ups
Document owner
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Release Management
o Deferred Peaks should be recognisable against the release they were deferred from and the
release to which they are subsequently targeted
o Only Peaks can be deferred — POA Jira’s or other things stored outside of Peak CANNOT be
deferred
o Deferred Peaks (that do not relate to test environment findings) become Live Defects. When
a Peak is deferred, the Fujitsu party obtaining the agreement must ensure:
e the ##LiveAffectingDefect Collection is set where applicable
[Add Incident to Collection
system that ¥ II Add to Collection
e the “Deferral Agreed” Collection set
«The Call Type set to “#” if the Live Defect is confirmed and a fix.can be progressed,
or the Call Type set to “L” if the Live Defect still needs further investigation
« Target Release Type changed to “Proposed for” for subseéquent update via BIF/PTF
e If the deferred Peak has at least 1 of the following. attributes (Horizon Defect
Review):
= Affects, or has the potential to affect, branch financial outcomes (add the
“HDR-Fin” Collection)
= Affects, or has the potential to affect, the way a postmaster is required to use
the system (User Interface, Report)Function) (add the “HDR-Exp”
Collection)
« Affects, or has the potential to affect, the experience of a Post Office
customer or client. (add the “HDR-Exp” Collection)
Note: Only one HDR-* Collection needs to be set and if both could apply then HDR-Fin
should be chosen
IAdd Incident to Collection
HOR-Exp — Horizon Defect Review - SPM Experience [Public]
7s
~ Horizon Defect Review - SPM Experience [Public]
Horizon Defect Review - Financial Impact [Public]
o Release Notes must list all Peaks that are fixed and being deployed. The extract/report must
also show the, POLPRB- reference for HDR Defects and the Fujitsu Problem references if
they. have been tagged to be tracked by the Problem manager(s). This is achieved by
clicking the button to the right of the listed Peaks in the Release Note which creates an Excel
spreadsheet that can attached to the TfSNow Change ticket (format similar to below):
PC029S403 LST: 20.94: Too many D records in LREC fle
PCO29S711 PBS Pilot INC8349716 : Amex bass not settled as expected when reconciling DRS2 reports
BC0295725 PBS: INC8354763 (IFSNow) : INCO388718 Lloyds £300 withirawal [MCSUK-16376]
o Release Notes will not list:
« the Peaks that are being deferred (as they are not fixed yet)
* any clone Peaks raised by Test for Test Only actions (as these are not additional
Live Defects but are just a tracking mechanism for the Test team)
Page I 20
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
o The action of deploying the Release should cause the relevant Peaks on the Release Note to
be closed. As a minimum it should ensure all are set to Status “F” and alert the originator that
the fix is deployed and they are asked to close the Peak -
© The action of deploying the Release should notify SSC so that any related KBAs can be
correctly actioned
o “Release Peaks” are administrative reference Peaks for Release Management. They do not
act as master Peaks so the defect Peaks must be kept updated independent of the Release
Peak settings and dates
co Ifa Peak has been assigned to a Baseline then cloning should be done with caution and
include consultation with the Baseline owner in advance
o Release Management processes will apply to 3° party deployments that are.within the Fujitsu
scope of responsibilities. For example, Ingenico fixes will be deployed under releases and
Peaks will be Targeted At, Proposed for, and Reported In release numbers identified for
Ingenico fixes — currently 90.xx
o Hotfixes are a mini release and will use the new 3-node release Numbering xx.yy.zz where
the primary 2 nodes are the release that they relate to and.the. third node is the hotfix
number.
o If a release has gone Live, then any Peaks which require a hotfix.should NOT be Targeted At
the master release, but at a hotfix release. For example:
« PBS - the master releases was 20.94. “Any hot fixes have their own release
20.94.01, 20.94.02 ... 20.94.11 and soon
e 71.10 -the master release was 71.10, already released from FJ to CC for packaging.
Any hot fixes for this would be.71.10.01, followed by 71.10.02 and so on
o If a hotfix is needed, Release Management will create the hotfix release in Peak with its own
set of dates, so that it can be properly tracked
co Any peaks that are not urgent, ‘anditherefore not a hotfix, should go to BIF/PTF for release
via the Maintenance Release. process
o Release Management will maintain the Target Release date table:
« All past Releases must state the actual release date for deployment (if phased, this
should be the Pilot release date when at least 1 live branch saw new code installed)
e All future Releases must show the latest anticipated release date for deployment —
irrespective of who will be leading the deployment
e The Release date should be the first time that the deployment was made to any live
environment (Model Office or agreed pilot rollout sites). The date will therefore show
‘the first time the fix was deployed to a live counter/branch eventhough a phased
rollout may mean other counters/branches did not receive the fix until a later agreed
date
« The Target Release screen should be used to make universal changes to Peaks
when release information changes — especially the Planned Dates for the whole
Release. The dates can be changed and then the “Reset Date” button is used to
apply the new date to all Peaks Targeted At the updated release (see below):
Peak Tn
Rs —s ‘ave Soa 6
it Management System
Page I 21
Version & Last updated See file n
Document owner Steve Bre
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Da ene Uo
Peak Incident Management
I Show rie
« These date changes then propagate to the Release Mgt tab for each Peak and
update the dates shown below enabling the progress of each Peak to be tracked:
Planned Dates DDMMAYYY) ‘Actual Dates DDMMYTYY)
Out Development J I
‘Out Integration ere I
Toto LST i
‘OurLST ] J]
Into Production ] ] }
¢ Hotfix releases must also be included in the date table
* Targeted Releases with no stated deployment date must be reported on and
validated to ensure progress — or the intentional lack of it— is defined by process and
cannot go unnoticed
e We all know that the goal is to progress from logging a perceived fault to fixing it
(unless it isn’t really a fault) as quickly as we can. The added objective here is to
ensure POA management and POL management are aware of the packages of work
we have and are fully engaged in determining priorities and dates. The only thing
stopping us making an immediate fix should be a POL supported decision to not take
immediate action. We should never determine what we fix or don’t by ourselves
(unless Fujitsu is the only beneficiary of the fix). So, here are some actions I feel
move us Closer to that goal:
Actions
System Changes
« Create a button alongside the listed Peaks on the Release Note that gather the content for
into an Excel sheet for easy upload into the TfSNow Change ticket, updated the cloning
process to ask for a reason and then record it in the new cloned Peak, updated the cloning
process to take more fields across to the clone
« Tocreate menuilist for reason for creating a clone and also to enable the Summary field to
be changed to a more appropriate text string
New Ways of Working
1. Managers will need to conduct spot checks on Peak data entry quality and encourage new
habits — fields filled in, fields read well, clones created for correct situations - See Appendix
A
2. Adam/Steve Ba/Sandie - Peaks closed as user/process error should be considered along
with TfSNow Incidents closed for the same reasons to send a monthly report to POL to
recommend enhancements that could avoid the occurrence of the issue
3. Adam/Steve Ba/Sandie — Peaks/Incidents closed as “66 — Final - Enhancement Request”
should also be reported on monthly to POL to recommend enhancements are submitted to
Fujitsu. KBAs also needs to be updated to show the outcome was that POL need to raise an
enhancement request
Page I 22
Version & Last updated See file n
Document owner Steve Bre
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
4. Matt S - Targeted Releases with no stated deployment date must be reported on and
validated to ensure progress — or the intentional lack of it - is defined by process and cannot
go unnoticed
5. PMs/QFP - Deferred Peaks will need to be updated. The party obtaining agreement to defer
will need I
°
°
°
Page I 23
snsure:
the ##LiveAffectingDefect Collection is set (if applicable)
the “Deferral Agreed” Collection set
The Call Type set to “#” if the Live Defect is confirmed and a fix can be progressed,
or the Call Type set to “L” if the Live Defect still needs further investigation
Target Release Type changed to “Proposed for” for subsequent update via BIF/PTF
If the deferred Peak has at least 1 of the following attributes (Horizon Defect
Review):
= Affects, or has the potential to affect, branch financial outcomes (add the
“HDR-Fin” Collection)
= Affects, or has the potential to affect, the way a postmaster is required to use
the system (User Interface, Report, Function).(add the “HDR-Exp”
Collection)
= Affects, or has the potential to affect, theexperience of a Post Office
customer or client (add the “HDR-Exp” Collection)
See file name
Steve Browell
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Live Defect Management — Live Defect Definition
co All Live Defects are managed in Peak only
o Some classifications of Live Defects are managed in a joint weekly Horizon Defect Review
Forum chaired by POL. These are known as HDR Defects
o ALive Defect is defined as an issue that:
e Is present on a LIVE system
e Is within Fujitsu's scope of obligations
« Is, or appears to be, inconsistent with the agreed design or service specification
e Is, therefore, a fault that is likely to need fixing
e The Horizon Defects Review (HDR) scope will be those Live Defects that also have
at least 1 of the following attributes (HDR Defects):
= Affects, or has the potential to affect, branch financial’outcomes\(add the
“HDR-Fin” Collection)
= Affects, or has the potential to affect, the way a postmaster is required to use
the system (User Interface, Report, Function) (add the “HDR-Exp”
Collection)
« Affects, or has the potential to affect, the.experience of a Post Office
customer or client (add the “HDR-Exp” Collection)
[Add Incident to Collection
I HDR-Exp -- Horizon Defect Review -
3
jorizon Defect Review - SPM Experience [Public]
Horizon Defect Review - Financial Impact [Public]
HOR-Exp ~
HOR Fit
« There may be a workaround, but the underlying issue still meets the criteria above
e An Incident may be undefinvestigation that is not confirmed to meet the criteria
above but has attributes that meet the criteria above (a potential Live Defect/HDR
Defect)
o Note 1: Only one HDR-* Collection needs to be set and if both could apply then HDR-Fin should be
chosen
© Note 2: Defects identified and.managed throughout the Development and Test stages are not under
this Live Defect Management process as they do not relate to the Live system. Hence there are 3
types of defect:
e Live HDR Defects
«__ Live (Non-HDR) Defects
“WNon-Live Defects (test/dev etc) — not tracked by Live Defect Management
co Note3: KBAs can be raised to describe Live Defects but the management of the Live Defect is done
by the Peak and this Live Defect Management process
Live Defect Management — Goals
A banner will appear on the Peak login screen to remind support staff of the changes that are
described below. This will most likely be removed when new habits are successfully formed and
the reminder is no longer needed:
Page I 24
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
\Defect Management Changes
There have been some changes to the Defect Management process to enable more accurate reporting. Please consider the following when reviewing a potential defect Peak:
1 Live Defect? Ifs0, add the #/LiveAfectingDefect Collection.
Chi ive Incident or # -- Defect Identified as applicable
tions? If so, add either the HDR-Fin (Financial) or HDR-Exp (Experience) Collection
the Workaround Reference field and set st 10 Yes
Impact update” There isa new template to guide adding an impact.
the Priority correct” The default priority from TESNow is often too low
Product & Product Group be added if required
Response Category) cof ty i the defect process,
Peak Incident Management System - RMG Account
Phi Ffeaout 1) [eoltections!
o Live Defect Management must have a designated owner on POA to manage and evolve the
processes and systems used ’
o Staff will need training and guidance on how POA wants Live,Defects to be managed and
how the systems need to be kept up to date
o Live Defects must be recorded as Peaks and managed using the. Peak system
e Fujitsu may have Problems open for Live Defects but the Problem record needs to
hold the relevant Peak reference as this will be where progress updates will be
derived
o We must know how many Live Defects there are’at any point in time — and importantly, we
must know which ones are part of the HDR\Defect tracking led by POL and we must store the
POL tracking reference on our defect Peak
o Weneed to be able to differentiate between Live Defects that are still being investigated and
are not confirmed, and Live Defects:that have been confirmed and require action to resolve
o We need to know the statusjof all Live Defects and whether there are any issues needing
attention
co We need to be able to review trends and attributes of Live Defects to identify patterns — for
example, we need new.reports to show trends, volumes, efficient areas, inefficient areas,
process stalled, aging entries, mix by priority, targeted at, time by stage, defects by system
area
Live Defects must be clearly titled so that they can be understood by the majority of readers
Live Defect status must be clearly stated and be current and not require the reader to read
content and come.to a summarised view themselves
All Live Defects must have a clear next action stated that can be tracked
All Live Defects must be owned by a team at all times whose manager will ensure the right
actions are being taken (this can be a different team throughout the lifetime of the Live
Defect)
o Managers must ensure that Live Defects within their areas are reviewed regularly and action
taken to ensure processes are being followed — this may require manual reviews
o When a HDR Defect is being investigated there will be a TfSNow Incident open and bonded.
POL will track status by referring to their ServiceNow Incident. All progress on the
investigation is to be added to the TfSNow Incident so that it is visible to POL in their
corresponding ServiceNow Incident
e Itis POL’s responsibility to keep their Problem record up to date if they have opened
one
o If Fujitsu completes its investigation and confirms there is no HDR Defect then the
investigation Peak and Incident will be closed with no further actions required. The Peak will
be closed with Response Category “95 -- Final — Advice after Investigation” [or “66 — Final —
Page I 25
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Enhancement Request’] which will see it excluded from Live Defect counts in the future. The
HDR-* Collection should remain so we know it was considered within the HDR Forum
When a HDR Defect is confirmed as a Fujitsu owned Live Defect, then a new defect Peak
will be created that summarises the fault and the required fix and carries all the required
meta data tags. The defect Peak reference will be added to the investigation Peak which will
then replicate to the TfSNow Incident. The investigation Peak will be closed along with the
TfSNow Incident. Fujitsu will then manage the Live Defect in Peak and will provide status
update reports from Peak that will be shared with POL for POL to use as part of the weekly
HDR Forum
Live Defects that are not classified as HDR Defects are managed internally by Fujitsu using
Peak. Reports will be available for POL to show overall progress but it is not intended that
every non-HDR Defect will be discussed
There are a number of new and updated fields that comprise the key meta data used to
manage defect Peaks. These fields must be kept up to date by Fujitsu staff and.checked and
amended by team managers regularly
Deferred Peaks (that do not relate to test environment findings) become Live Defects. When
a Peak is deferred, the Fujitsu party obtaining the agreement.must'ensure:
e the ##LiveAffectingDefect Collection is set wheré,applicable
e the “Deferral Agreed” Collection is set
e The Call Type is set to “#” if the Live Defect is confirmed and a fix can be
progressed, or the Call Type set to “L” if the Live Defect still needs further
investigation
a eC CC
Peak Inciden
I pererevces I mrooucts EVIDENCE nect ( ¢
[Call Reference [PC0294913
[Release [Targeted At - HNG-X 21.52
[Call Type [Live Incidents v
Ic '# — Defect Identified
Administrative use ns
toned call
nhancement Request
Jocument Review/Design Walkthrough Es
~ GDC Testing incidents/Defects I cy
Internal Development Incidents/Defects
wary: TNC8092248
‘all Type:t 'M-~ Problem Management
~ Operational (SSC)
Product Incidents/Defects
Release Notice Forum
‘System Testing Incidents/Defects
Technical query
Security Testing Incidents/Defects
“ Bvar BAL/HBS
INCIDENT MANAGEMENT
JjDate/Time Raised: 3)
Priority: 0 Vulnerability
‘ontact Name: POA sI W ~- Reference Data Service
jontact Phone: —_I X-— System Management Testing Incidents/Defects
riginator: 200000 ive (Non-RefData) Data Updates ws:
rSginator's refereheer aNCHUyEZE seeaaeacies
Page I 26
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
« Target Release Type changed to “Proposed for” for subsequent update via BIF/PTF
e If the deferred Peak has at least 1 of the following attributes (Horizon Defect
Review):
« Affects, or has the potential to affect, branch financial outcomes (add the
“HDR-Fin” Collection)
= Affects, or has the potential to affect, the way a postmaster is required to use
the system (User Interface, Report, Function) (add the “HDR-Exp”
Collection)
« Affects, or has the potential to affect, the experience of a Post Office
customer or client (add the “HDR-Exp” Collection)
Note: Only one HDR-* Collection needs to be set and if both could apply, then HDR-Fin
should be chosen
[Add Incident to Collection
I HDR-Exp -- Horizon Defect Review - SPM Experience [Public] : ___ II Add to Collection I
“57
HDR-Exp — Horizon Defect Review - SPM Experience [Public]
HDR -Fin — Horizon Defect Review - Financial Impact [Public]
o We need a documented process that reviews any Fujitsu internal Jiras and ensures they are
monitored and raised as Peaks when needed so.they follow the»processes. Jiras meeting the
criteria stated in Appendix C require no action’as Appendix C is a POA policy
o We need to hold dates when Releases went liveand when future Releases are proposed for
so we have an outcome for any defect Peak
o We need to provide a full list of ALL Live Defects closed in a Release with their associated
POL Problem references so that POL are also able to manage their HDR process
o Reports are needed for management to show the overall status, trends, and patterns related
to all current Live Defects and historical Live Defects
co CBIF rejections will get a POLreference that we will add to the Peak References field and
also to the KBA so we know this was a POL decision not to take further action. The Peak will
be closed with Response “63 -- Final -- Programme approved - No fix required”
o CBIF submissions will bedocumented in a file that will be attached to Peak. The file will use
the File Type “CBIF Proposal” so it can be readily identified. This will be sent to HDR so that
the meeting has the information in advance
o The outcome of BIF/CBIF/PTF meetings will be held in concise notes in the relevant text
boxes.on the Release Mgt tab. No need for separate minutes
o Peaks that havesbeen tested successfully and are still to be deployed must not be closed and
must/be routed to RM-x and assigned to “Release to Live” so it is clear that the Live Defect is
still present in the system but that its fix has been tested and is awaiting release
o “Release Peaks” are administrative reference Peaks for Release Management. They do not
act as master Peaks so the defect Peaks must be kept updated independent of the Release
Peak settings and dates
° We need a1 method to track when a ee — and ther the delay was islated to waiting
hence a fix could have been deployed nearer to that time that the release date
eventually used
* We need to message this correctly to POL and POA management
Page I 27
1 & Last updated: See file n:
vent owner Steve Bre
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
+ We need to challenge ourselves on our processes and the batching of items for a
\ jot do more releases, why do we not put more in a release
. We need to nsure that POL and. thas are in olved in the defect
backlog decision I é
+ Demand Plannin
prioritised along with the other project work - sp or not — but by explicit decision making
o The following Response Category field values are considered No Fault Found:
Response Category — 62 -- Final — No fault in product
“Response Category — 63 -- Final -- Programme Approved — No Fix Required
Response Category — 66 -- Final -- Enhancement Request
Response Category — 68 -- Final -- Administrative Response
Response Category - 72 -- Final -- Duplicate Call
Response Category — 94 -- Final -- Advice and guidance given
Response Category — 95 -- Final -- Advice after Investigation
Response Category — 96 -- Final -- Insufficient evidence
Response Category — 97 -- Final -- Unspecified insufficient evidence
Response Category — 98 -- Final -- User error
Response Category — 100 -- Final — Route call to TIS.
Response Category — 120 -- Final — Cloned to create Defect Peak
Response Category — 200 -- Final — Call withdrawn by user
o We should ensure that any Live Defect is promptly investigated until we confirm no fault is
found or that a fix is needed and change the status to Defect Identified. Anyone owning a
stack with Peaks classéd.as ##LiveAffectingDefect that is open and still being investigated
should ensure progress is made optimally
o If we have a’LiveDefect that is Defect Identified and it has either of the HDR-* Collections,
or is Priority A or B we should:
a. \Explore every option we can to find a workaround — and implement it
b. Get.it' Targeted At a release as fast as possible (immediate BIF and PTF)
¢. Geta strong proposed date for these Releases (so we have a go live date in
mind) — this may require more input from POL
d» Propose a hot-fix is considered and invite POA management and POL
management to decide if they want to or not (forget the constraints — this is a
management call)
e. Stack owners and Release Management must ensure this is done
co If we have a Live Defect that is Defect Identified and is Priority C/D/Z we should:
a. Get it Targeted At a maintenance release as fast as possible
b. Normal BIF and PTF scheduled meetings can continue
c. Demand more maintenance releases with confirmed dates
d. Stack owners and Release Management must ensure this is done
e. We should expect to put Live Defects that are Defect Identified into the next
month's maintenance release ‘at the latest’
o ifwe termine that progressing a Live Defect is not th - best option (for example the feature
is being migrated and any fix would serve little purpose) then we should act as follows:
Page I 28
Version & Last updated See file n
Document owner Steve Bre
°
Live Defect Management — Key Fields in Peak 4 -
The following are the key fields needed for Live Defect Management:
°
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL —
INTERNAL USE ONLY (POA ONLY)
Take ALL numbered and dated Releases to Demand Planning so they. can be! prioritised
alongside other work by POA and by POL and POL know the implica ty pot allowing us to
progress them
Call Type — must be set to “#” Defect Identified when a Live Deféct is confirmed. Prior to this
Live Defects ought to be Call Type “L” Live Incident but ean ‘have other Call Types provided
they carry the ##LiveAffectingDefect Collection. The Collection descriptive text is “Fault that
is present on the Live system that is inconsistent) with the agreed design and/or service
specification” $
Peak In
IMPACT
{ DETAILS
[GallReference
[Release
I REFERENCES I
{PC0295241
[Reported In -- HNG-X Rel. Ind.
O -- Operational (SSC v.
‘A-Administrative use
[Impact } C Cloned call
a E ~ Enhancement Request
Sia F -- Document Review/Design Walkthrough
jate: 16-Jun-2021 10 G - GDC Testing Incidents/Defects <
LL PC0295241 oper I ~Intemal Development Incidents/Defects .
etails entered areI K - Primark K
vumnary : testing L-- Live Incidents
M-~ Problem Management
syg-I O~ Operational (SSC)
P -- Product Incidents/Defects
R = Release Notice Forum
ate: 16-Jun-2021 10)
[start of Response]I S~ System Testing Incidents/Defects
eeting dev #0 T ~ Technical query
[End of Response] I U ~- Security Testing Incidents/Defects
jesponse code to cal V - Vulnerability
ate: 16-Jun-2021 10 W -- Reference Data Service
11 record hasI X-- System Management Testing Incidents/Defects — fps_
ate: 16-Jun-2021 10IY -- Live (Non-RefData) Data Updates aa
velopment Cost updated? view cost is"2" (Man Days)
[Start of Response]
est 1
[End of Response}
sponse code to call type L as Category 4@ -- Pending -- Incident Under Investigation
ate: 16-Jun-2021 10:51:08 User: John Simpkins
PRODUCTS EVIDENCE I
© hnginot yet defined/TBA] St
lem Identified(38) _
Page I 29
Version & Last updated:
Document owner:
See file name
Steve Browell
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
o Summary - must be written so as to be understandable by most readers. This will need more
thought when Peaks are raised. Management should amend this during weekly clean-ups
(careful to preserve links where raised in another system)
co Impact -— tab and free form field to articulate impact, status and next steps so it is easy to
understand for anyone. This will be maintained for HDR Peaks weekly. For other Peaks it can
be as needed
« Business impact: [as used currently, mention how many branches are affected if
helpful]
e Status update: [description of current status — succinct]
e Next action: [next action to be taken and expected date for next update]
o Collection ##LiveAffectingDefect (formerly ##LiveAffectingSoftwareFault), This Collection
must be set when the Peak meets the criteria for a Live Defect at the earliest possible
opportunity. It is likely that Call Type “L” will frequently carry this ##tag but. it will not always
be the case so needs selectively applying. The Collection descriptive text is “Fault that is
present on the Live system that is inconsistent with the agreed design and/or service
specification”
[Add incident to Collection
stingDefect — Fault that is present on the Li
o Collections of “HDR-Fin” or “HDR-Exp” for HDR Defects
Note: Only one HDR-* Collection needs to,be set and if both could apply then HDR-Fin should be
chosen
IAdd Incident to Collection
I HOR-Exp -- Horizon Defect Review - SPM yerience [Public] _
[ Add to Collection I
HDR-Exp Horizon Defect Review - SPM Experience [Public]
HOR-Fi izon Defect Review - Financial Impact [Public]
o Collections - when a Collection is added or removed the history is held on the Release Mgt
tab in the RMF area as shown’ below:
Release Management Forum (RMF)
3/11/2021 Added to Collection ##LiveaffectingDefect by John Simpkins.
03/11/2021 Collection ##LiveaffectingDefect removed by John Simpkins.
93/11/2021 Added to Collection HDR-Exp by John Simpkins.
3/11/2021 Collection HOR-Exp removed by John Simpkins.
03/11/2021 Added to Collection HOR-Fin by John Simpkins.
03/11/2021 Collection HOR-Fin removed by John Simpkins.I
o Priority — which must be validated at all times so it is accurately shown as this will affect
reporting and decision making
o POL Problem reference — using the prefix “POLPRB-“ so it is obvious and also searchable
e POL Problem Reference is a Reference field and the following screenshots shows
how to add the field:
Page I 30
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Peak cident Manage
peosszut
o Fujitsu Problem reference — using the prefix “FJPRB-" so it is obvious and also searchable
e Fujitsu Problem Reference is a Reference field and the followiga's Screenshots shows
how to add the field:
Fea nia Stang Sin PCT
o Workaround - to state “Yes/No” stateiif @workaround has been implemented. If the field is
blank or contains “No” then no,workaround has been identified. If it is “Yes” then an accepted
workaround is in place
e Workaround.is a Reference field and the following 2 screenshots show how to add
the field and sétiits value:
Yeak incident Management System - 2C0295241
eT
fear ai
ico
[calteeence
(Galeton
(Galea
Page I 31
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Peak Incident Management System - PCO
Taped Forman
‘Tf adding mutnigle references these must be commun separated and be of the sani! 7
o Release Mgt tab — Initial and Completed dates and text box - We need to know the stage
we are at in the fixing process, the date it initially entered the stage and when, the stage was
completed and the notes from the meetings at which it was discussed.
o Assigned Team — must show which team is currently responsible for taking.the next action
or ensuring action is taken
o Product Group and Product - We need to know the part of the system that the Live Defect
relates to for reporting and quality purposes
o Root Cause - we need to know what type of fix was needed, which when matched to the
part of the system affected, gives us further quality data
o Response Category - specific values have been identified to,enable clarity and to spot
exclusions:
e “63 -- Final -- Programme approved - No fix required” — for Peaks rejected at CBIF
e “66 -- Final -- Enhancement Request” — for. Peaks tagged with the HDR Collection
that were subsequently qualified as not being HDR Defects but enhancement
requests
e “95 -- Final — Advice after Investigation” — for Peaks tagged with the HDR Collection
that were subsequently qualified.as,not being HDR Defects
«The value “30 -- Pending -- TL confirmed” will cease to be used
Target Release — the values of “Requested For” and “Released at” will cease to be used
Management governance and checking is needed to ensure this is how the system is being
used — correcting at leastweekly
o Areminder will pop up on certain changes of Peak status to remind support staff to consider
the key fields:
« Events triggering presentation of the pop-up:
= The Peak Routing is changed
= “»The Call Type is changed
= The Response Category is changed
= The ##LiveAffectingDefect Collection is added
= The HDR-Fin or HDR-Exp Collections are added
e Pop-up wording:
= Is this a Live Defect? — if so, add the ##LiveAffectingDefect Collection
= — Is the Call Type correct (Live Incident or Defect Identified if applicable)?
= Does/could this affect branch operations? — if so, add the HDR-Fin or HDR-
Exp Collection
= Is there a Workaround? — if so, add the Workaround References field and
set it to Yes
= Does your last update read well to users not involved in the Peak progress?
= Have you added a helpful Impact update?
= — Is the Priority correct?
= Are the Product & Product Group fields correct?
« Is the Status (Response Category) correct?
Page I 32
Version & Last updated See file n
Document owner Steve Bre
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Live Defect Management — Reporting
From 2 queries/datasets it should be possible to create views of potential Live Defects,
confirmed Live Defects, deferred Live Defects, and Peaks needing customer input
The 2 reports are:
1. Report to extract all ##LiveAffectingDefect tagged Peaks and show the columns as
below
2. Report to extract all Open Peaks and show the columns as below
e The output fields for both queries are to be (at least):
Call Reference, Summary, Date Opened, Product, Product Group, CallType, Priority,
Assigned Team, Status, Root Cause, Collections, References, TfSNow Incident, POL
SNOW Incident, Contact Name, Workaround, Business Impact, Target Release, Target
Release Type, Response Category, BIF Initial Date, BIF Completed Date)BIF Text,
CBIF Initial Date, CBIF Completed Date, CBIF Text, CBIF Proposal (exists or doesn’t for
now), PTF Initial Date, PTF Completed Date, PTF Text, Development (Man Days),
Cloned from, Cloned to, Date Time Last Updated, Planned Out)Live, Call Logger,
Actioned Team, Date Last Closed, Call Loggers Team, BIFyTicked_Questions,
HDR_User, HDR_Date, BIF_User, BIF_Date, TFSBonded (1/0), Assignee, Time to
Target (Days)
Actions
System Changes
Rename ##LiveAffectingSoftwareFault to ##LiveAffectingDefect and apply to all currently
tagged Peaks
Rename Call Type "L" to remove “/Defects” from label
New Workaround field with optional text values Yes/No
New Call Type value of "#" for Defectdentified
New HDR Collections of “HDR-Fin’ and “HDR-Exp”
Updated Release Mgtitab to add BIF, CBIF and PTF fields above current list (to hold dates of
meetings and outcome summaries)
Amended default, guidance text for the Impact text box
New Reference type of POL Problem Reference and enforce POLPRB- prefix
New File Type of “CBIF Proposal”
Removed “30,-- Pending -TL confirmed” Response Category
Amended the descriptive text for ##LiveAffectingDefect to “Fault that is present on the Live
system that is inconsistent with the agreed design and/or service specification”
Added new Response Category “Cloned to create Defect Peak”
Added text box to ask user why they are cloning, writing the response into the start of the
clone
Added capability to setup email alerts if specific Collections are added or removed
Added temporary reminder pop-up until the new fields and values become more embedded
Remove the values of “Requested For” and “Released at” from list of Target Release field
values
One-Time Actions
1.
i. Root Cause values need explaining and adding to the Application Support
Strategy document
Page I 33
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
1 Architecture
6 Design - Platform Design
7 Design - High Level Design
8 Design - System Outline
13 Development - Build Scripts
14 Development - Code
15 Development - Low Level Design
16 Development - Reference Data
21 Requirements
24 Cfg Mgt - Config Data Error
26 Integration - Build
31 Test - Test interpretation
Test - Script
33 Test - Data
34 Test - Environment
37 General - Network Change
38 General - Hardware Fault
39 General - User Knowledge
40 General - User
41 General - in Procedure.
42 Gen - Outside’Program Control
43 General - OperationahChange
96 Gen - Investigation On-Going
97 General = 3rd Party, issue
99 General - Unknown
Steve Br/Steve Ba/Tariq/Adam/Graham -— when the final list of Live Defects is visible,
identify policy statements and decision criteria that can be defined that sees defect Peaks
either closed or actioned where currently they seem to have stagnated
oe eee eee ee eee ee ere eee reese e
ray
S
Steve Br - Agree a process for CBIF Proposal creation
on
Steve Br — Investigate implications of Post Office Cloud on ways of working. Check how Live
Defects are being recorded in AWS JIRA and be sure it is aligned to this Live Defect
Management process or that an agreed alternative way of working is defined and agreed at
DE/VP level
New Ways of Working
The identified fields necessary for Live Defect Management must be kept up to date.
1. Adam - Mandate weekly refreshes of Impact field for all HDR- tagged Peaks (and ideally all
##LiveAffectingDefect tagged Peaks)
Page I 34
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
2. Steve Br/Adam - Implement a management process to check the new fields and ensure they
are correctly used for the next few weeks until habits form — see Appendix A for checks
Page I 35
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
BIF
o BIF is a Fujitsu internal meeting
o When a Developer is ready for BIF to consider their proposal then they must
e Set BIF Action flag on the relevant Peak
¢ = If the Peak:
= Is present on a LIVE system
* — Is within Fujitsu’s scope of obligations
= Is, or appears to be, inconsistent with the agreed design or service
specification
« Is, therefore, a fault that is likely to need fixing
* Then
= Add the ##LiveAffectingDefect Collection
[Add Incident to Collection
I #LiveAffectingDefect
90
‘ult that is present on the Live system that is inconsisten [Public]
= — If the cause and required action to remedy ares
« — Still being investigated — then set the CallhType to "L"
e Are confirmed — set the Call Type to “#” and also update:
o Root Cause field is up todate
Peak Im
(betas nererexces I! pRovticts BUDENCE DapAct
[Calf Reference _ JPCO295241
[Release [Reported In HNG-X Rel Ind
[Call Type ‘0 = Operational (SSC) 7
’A~ Administrative use a
lismpact C~Cioned call Piiootyaraetine
I PE
a F ~ Document ReviewDesign Walkthrough I
if
fe! 46-Jun-2021 10] G ~ GDC Testing Incidents/Defects
ALL PC0295241_ opet I intemal Development incidents/Defecis
Joctails entered ere/K~ Primark
Summary: testing IL Live incdents
“ell Type: M~ Problem Management
ee Parke aya] O~ Operational (SSC)
farget Reles30:¥¥5-1 5 — product Incidents/Delects
See eee ia) R ~ Release Notice Forum
paket ot necpanseyI 5 ~ System Testing incdents/Delects
esting dev ho IT~ Techical query
feed of Response] _IU~ Secuy Testing ncidents/Defects
Response code to ca) V—Voinerabliy hen tdentitied(36)
Pe: 16-Jun-2021 10] W ~ Reference Data Service i
Hthe Cell record has! X- System Management Testing Incidens/Defects pis
joste:16-30n-2021 10 on-RefData) Data Updates =
evelopment Cost updated? new core Tz 7 (lan bays)
[Stare of Responses
est 1
I[End of Response]
iesponse code t0 cell type L ss Category 40 -- Pending -- Incident Under Invertigetion
Hosee:46-30n-2028 10:51:08 User: ohn Sinokins
= Ensure Workaround field is up to date
= Ensure Product Group field is up to date
= Ensure Product field is up to date
= Ensure Priority field is up to date
= Ensure Impact field is up to date
o All Peaks with the BIF Action flag set will be reviewed at BIF.
e This will include all defects Peaks with the ##LiveAffectingDefect tag
e It will also include other Peaks that may relate to other topics such as environments
or Peaks that the Developers wish to discuss at the forum
Page I 36
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
oO. Ifa Peak had previously been rejected - as more information was required - then it will have
the BIF Action flag set again when the Developer is ready to re-present their proposal
oO. BIF must consider the proposal (as it does currently) and also validate the following data
values for defect Peaks:
¢ If the Peak:
Page I 37
Is present on a LIVE system
Is within Fujitsu’s scope of obligations
Is, or appears to be, inconsistent with the agreed design or service
specification
Is, therefore, a fault that is likely to need fixing
Ensure the ##LiveAffectingDefect Collection is set
If the cause and required action to remedy are:
* — Still being investigated — then’Setithe Call Type to "L"
« Are confirmed — set the Call Type to.“#” and also update:
o Root Cause field is up to date ©
Peak In
PRODUCTS EVIDENCE IMPACT
[Pco295241_
[Reported In -- HNG-X Rel. Ind.
© — Operatonal SSC) =
= Admiisrave use
~ Cloned call
~ Enhancement Request
Document Review'Design Walkthrough
GDC Testing Incidents/Defects
Intemal Development Incidents/Defects
Primark
Live Incidents
Problem Management
Operational (SSC)
Roveed tarEose yu] P~ Product Incidents/Defects
te :16-Jun.2021 26 ® ~ Release Notice Forum
start of Response] S~ System Testing Incidents/Defects
testing dev mp I T~ Technical query
[End of Response] Security Testing incidents/Defects
IResponse code to ca] V—Vuinerabilty jen Ident ified(38)
2 £16-Jun-2021 10 W~ Reference Data Service
ALL PCO295241 oper
jet ails entered ar
Isunmary: testing
‘all Type:
‘all Priorit
he Call record hasI X-—- System Management Testing Incidents/Defects ps
jate: 16-Jun-2621 16] Y ~- Live (Non-ReflJata) Data Updates *
Pniew Cost IS 2" (Man Days) ae
jevelopment Cost updal
[Start of Response]
test 1
[End of Response]
ee ee
yate:16-Jun-2021 10:51:08 User: John Simokins
Ensure Workaround field is up to date
Ensure Product Group field is up to date
Ensure Product field is up to date
Ensure Priority field is up to date
Ensure Impact field is up to date
Check if the new HDR Collections of “HDR-Fin” or “HDR-Exp” should apply.
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
If it needs applying then the chair must alert Steve Bansal, Adam Woodley
and Sandie Bothick. If the issue in the Peak:
e Affects, or has the potential to affect, branch financial outcomes, add
the HDR-Fin Collection
e Affects, or has the potential to affect, the way a postmaster is
required to use the system (User Interface, Report, Function), add
the HDR-Exp Collection
e Affects, or has the potential to affect, the experience of a Post Office
customer or client, add the HDR-Exp Collection
Note: Only one HDR-* Collection needs to be set and if both could apply then HDR-
Fin should be chosen
[Add Tacident to Collection
[ HOR-Exp — Horizon Defect Review - SPM Experience [Public] [Add to Collection
on
HOR-Exp ~ Horizon Defect Review - SPM Experience [Public]
HOR-Fin — Horizon Defect Review - Financial Impact [Public]
= Check if there are conditions that would mean,the Peak needs POL input and
hence must go to CBIF. The questions are on the Release Mgt tab under the
BIF section
* — The fix cambe.done in more than one way and POL would need to
guide Fujitsu on choosing the preferred option.
* — The fixymay change the functionality of the system and consequently
POL will be required to provide appropriate communication, and
potentially training, to the subpostmasters.
* Thefix may need to be done in conjunction with changes performed
by some of POL's other suppliers and POL will need to manage and
synchronise that activity.
* The fix may need to be done concurrently with a separate future
planned change, due to the two fixes being logically related, and
POL would need to confirm their willingness to accept any potential
delays in deploying the fix.
* — The fix may relate to active discussions between Fujitsu and POL on
a specific and separate topic and hence should be discussed within
that context (Fujitsu management discretion).
* — Fujitsu does not believe a fix is a sensible option and seeks POL’s
agreement to record the circumstances in a KBA only.
= Note: The forecast Development (ManDays) will no longer be a deciding
factor for submission to CBIF
©. The BIF chair must record, in Peak on the Release Mgt tab, what decisions are made:
Page I 38
Version & Last updated: See file ni
Document owner Steve Bre
Page I 39
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e The new BIF date fields (Initial and Completed) willneed tobe completed during, or
after, the BIF meeting (not before or it will affect status reporting)
= Initial date - will hold the date of the firstBIF the Peak was first presented at
— this value should not change
= Completed date - will hold the last BIF meeting'the Peak was discussed at —
this value will change if the Peak is iteratively presented for review and it will
allow reporting on what was reviewed at the last BIF meeting
¢ The outcome of BIF discussions should be added to the BIF text box on the Release
Mgt tab. A concise note is all that is needed. No need for separate BIF minutes
e If the Peak is approved at BIF then the BIFApproved Collection must be added (also
for BIFRejected)
[Add incident to Collection
[EiPApproved Approved fo fx by the Business Inpact Forum [Team] SJ] Add to Colecion.
e If the Peak is to go\to CBIF this will be determined by the field values and the BIF
chair.should not set the PTF Action flag
e If the Peak does not need to go to CBIF then the PTF Action flag will be set
The definition of BIF in the contract ASM schedule needs to be updated
CBIF isa joint meeting with POL
CBIF wilhcontinue to exist and it will be merged with the
HDR Forum
CBIF will evolve to being more system driven (more
explanation below)
Items to be discussed at CBIF must have a “CBIF
Proposal” that has been created in advance using the
agreed template (see right) and approval process so it
is clear that this is what the decision needs to be made
on (not additional dialogue during a meeting)
Peaks to be discussed at CBIF are determined by Peak
data items so it is system driven. See CBIF Submission
Extract Criteria below for the system value that will
determine CBIF applicability
vi
Document owner Steve Browell
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
o Peaks required to go to CBIF will be identifiable via system query and report and will be
shared in advance with POL so that the meeting can focus on the decision not the
familiarisation
e If we need to invite an SME to elaborate (only for exceptional submissions) then the
SME will be invited. If the submission text is well worded then SME attendance
should not be required — as is currently the case when CWOs are approved
©. The CBIF representative must record, in Peak on the Release Mgt tab (but not in the
presence of POL), what decisions are made:
« The new CBIF date fields (Initial and Completed) will need to be completed during,
or after, the BIF meeting (not,before or it will affect status reporting)
= — Initial date - will hold the date of'the first CBIF the Peak was first presented
at — this value’should,not change
= Completed ‘date - will hold the last CBIF meeting the Peak was discussed at
— this value will, change if the Peak is iteratively presented for review and it
will allow reporting.on what was reviewed at the last CBIF meeting
¢ The outcometof CBIF discussions should be added to the CBIF text box on the
Release Mgt tab. Aiconcise note is all that is needed. No need for separate in CBIF
minutes,
e Ifthe Peak needs to go back to the Developer then it should be assigned to the
Developer team
@” ‘if the. Peak can proceed as discussed then the PTF Action flag will be set
« If the Peak is to be discussed next time (as POL wish to seek wider feedback within
their own organisation) then the PTF Action flag will not be set and this will cause the
Peak to reappear on the weekly report
e CBIF rejections must get a POL reference which we add to the Peak and also to the
KBA so we know this was a POL decision. The Peak is then closed with Response
Category “63 -- Final -- Programme approved - No fix required”
co There will need to be a weekly report seen by management of what is to be presented at
CBIF, and what the status is of open CBIF items and POL decisions
co There is no definition of CBIF in the contract — it says BIF — this needs to be addressed
Refer to Appendix E for instructions on how to determine if there are any CBIF candidates to report to
POL.
PTF
o PTF is a Fujitsu internal meeting
Page I 40
Version & Last updated See file n
Document owner Steve Bre
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
co All Peaks with the PTF Action flag set will be reviewed at BIF
e This will include all defect Peaks with the ##LiveAffectingDefect tag
e It will also include other Peaks that may relate to other topics such as environments
or Peaks that the Developers wish to discuss at the forum
If a Peak needs to be re-presented at PTF then it will have the PTF Action flag set again
o PTF must consider the proposal (as it does currently) and additionally be mindful that any
that carry a HDR Collection or that have been presented at CBIF must get additional scrutiny
— and potentially prioritisation — as progress will be reported to POL weekly
© The PTF chair must record, in Peak on the Release Mgt tab, what decisions are made:
« The new PTF date fields,(Initial and Completed) will need to be completed during, or
after, the PTF meeting (not before or it will affect status reporting)
= — Initial date - will hold.the date of the first PTF the Peak was first presented at
— this value should not change
= Completed date - will hold the last PTF meeting the Peak was discussed at —
this value.will change if the Peak is iteratively presented for review and it will
allow reporting on what was reviewed at the last PTF meeting
* The outcome of PTF discussions should be added to the PTF text box on the
Release Mgt tab. A concise note is all that is needed. No need for separate in PTF
minutes
HDR
o There is an updated Terms of Reference (currently v2.2) but it has yet to be presented for
sign off. CBIF will need adding at some stage once Fujitsu are ready with the internal CBIF
processes
o Overview of the process:
e Fujitsu takes new items as Incidents to HDR not KBAs or Peaks
e Fujitsu must ask POL for their Problem reference so it can be added to the Fujitsu
Incident (and any related Peaks) so we have the POL reference
e Fujitsu embeds any relevant KBA or Peak content into the Incident it shares
« Fujitsu tags its Incidents and Peaks with the applicable HDR-* Cl or Collection tags
e Fujitsu does not reference its KBAs (and does not share them with POL in their
native form)
e The only Peak reference is the defect Peak reference Fujitsu raises when the cause
is known and a fix is to be taken through the fixing process. Fujitsu will close the
Page I 41
Version & Last updated: See file n
Document owner Steve Bre
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
investigation Peak and the linked Incident as the confirmed defect Peak reference
will be the one that will be managed from this point
¢ Ifa KBA, or internal Peak, is created that identifies a condition that meets the
definition of HDR Defect then Fujitsu raises an Incident by contacting Fujitsu MAC
with the relevant KBA content in it and Fujitsu MAC bonds the Incident and alerts
POL
e Updates on potential Live Defects is provided via bonded Incident updates
e Updates on confirmed Live Defects is provided by defect Peak weekly reports
« The above ensure POL has visibility at all times either from their ServiceNow
Incident or by maintaining their ServiceNow Problem record (POL will need to
transpose data from the weekly Fujitsu reports into its Problem records)
e As this is an early warning forum too, we will also issue an email alertto the Fujitsu
Duty Manager distribution list and a POL distribution list to alertinterested parties
o Summary
e Potential HDR Defects will be reported automatically to POL via'the service
management toolset replication driven by Fujitsu updates tothe TfSNow Incident
e Actual HDR Defects (including any deferred) will be shared with POL weekly by an
extract report from Peak that will be sent to POL in advance of the meeting showing
the latest update
¢ New CBIF content will be shared with POL ona weekly report from Peak that will
include the proposal and will be sent to. POLvin advance of the meeting
e Updates to CBIF content will be shared with POL weekly by a extract report from
Peak that will be sent to POL in advance of the meeting showing the latest update
co The Incident will be worked by Fujitsu if it is within the Fujitsu scope of obligations —
otherwise it will be passed to POL ITDSD to assign to the relevant POL third party
o POL will probably convert the SetviceNow. Incident to a ServiceNow Problem — but that is
their choice
o If Fujitsu completes its investigation and confirms there is no HDR Defect then the
investigation Peak and Incident will be closed with no further actions required. The defect
Peak will be closed with Response Category “95 -- Final — Advice after Investigation” to say
the HDR Defect was not confirmed
co For the purposes of Live Defect Management, Fujitsu will use Peak references not TfSNow
Problem references,
o Fujitsu will provide its view of status — from its systems — and manage any difference of
opinionwith POL
co Fujitsu will provide weekly updates prior to the meeting
«Potential HDR Defects — no action required as the updates will already be in POL
ServiceNow
« Confirmed and deferred HDR Defects — by sharing the latest update on the defect
Peak we are managing our side in the form of a report.
« CBIF new Live Defects — for decision by sharing the pro-forma proposal in a report
and inviting a decision
* — Note: Any reports will be checked and sent in advance of the HDR Forum so POL can add it
to their Problem record and ensure they are ready to provide a decision to the CBIF new Live
Defects
o The HDR Forum needs to evolve away from a “talking shop” to one of quick facts that
demonstrate systematic control and confidence. Fujitsu should reduce the number of
attendees
Page I 42
Version & Last updated See file n
Document owner Steve Bre
°
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
If POL need more information, the Fujitsu Incident, Peak or Problem owner is tasked to get it
and add it to our system — or we get the CBIF proposal updated for resubmission. The new
information must be added to the system
POL need to hold the Fujitsu Incident or defect Peak reference in their Problem record so
they know what to ask us for an update on — and what to apply our report updates to in their
system
The HDR minutes need an overhaul for Fujitsu. This is the Fujitsu specific meeting and yet it
lists numerous Live Defects that are not related to Fujitsu and the minutes are sprawling and
hard to follow. POL will be advised that:
«They need to make it clear which HDR Defects are within Fujitsu’s scope of
obligations
« They need to show the Fujitsu Live Defect reference (ServiceNow/TfSNow Incident
or defect Peak)
e They need to show Fujitsu's latest update
« Asummary view at the top is needed - New, Open, Closed, by Severity, by area
affected, and trend
Any ad-hoc calls should only be required when the next scheduled meeting is too far away.
Updates from Fujitsu must come from the Incident update,or defect Peak report with any
additional comments made during the meeting being added,to the Incident or defect Peak
There is no definition of HDR in the contract — this needs to be addressed
Refer to Appendix D for instructions on how to create the weekly HDR Report for POL.
KB — Info only
°
°
The Fujitsu KB is an information repository used, for support purposes
Any observed Live Defects willbe recorded as a KBA but the progress to investigate and
address them will be done via Peak(s) and Incident(s)
KBAs do not need to be shared with POL as the tracking needs to be on the Peak and
Incident raised to progress them
If the awareness or involvement of POL is applicable then there will be a TfSNow bonded
Incident and this will contain.all relevant parts of any KBA so that the Incident that POL see
is a suitable complete reference
If POL accept a Live Defect - namely decide that no action is required — then the KBA will be
updated accordingly and will have the POL applicable reference added so it is clear that it
was not.fixed by POL decision. This is a contract responsibility on POL to record these and
issue Fujitsu with a notification
Page I 43
Version & Last updated: See file n
Document owner Steve Bre
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
&
Release Mgt tab — for BIF, CBIF and PTF
Hioka S
“The fhe may change the functionality of the system and consequently POL wil be required to provide sation, and rating. to the
“The fx may need tobe done nt conjuncton wi changes performed by some of POL's other suppliers and POL wal need to manage and synchyonte that acy, I
“The fix may need to be done concurrenty wth a separate future planned change. due to the hwo fixes besng logically re
The foc may relate to active discussions between Fujisu and POL on a speci and topic and hence shoud be
Fujitsu does not beteve a xis a sensible option and seeks POL's agreement to record the cumstances ina KB only
Fest cout progress
iiese PIF progress
ib
bs
ct RH update
Page I 44
Version & Last updated: See file name
Document owner: Steve Browell
CBIF / HDR Diagram
If it isa Live Defect then
add the
LiveAffectingDefect Cl
If it is a HDR Incident
then add relevant Cl
Updates auto replicate
POL rely on ServiceNow
Page I 45
POA Improvements — Streams 1-4
FUJ00232758
FUJ00232758
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Incident — Peak — Defect — HDR — CBIF
Potential Defect
Investigation Peak
Confirmed Defect
~ POL Incident
[ServiceNow]
Bonded
Fujitsu Incident
(TfSNow]
If POL not
needed
ification
Fujitsu Internal
Version & Last updated
Document owner
Fujitsu Internal
Fujitsu Reports
HDR/CBIF, or
Continuous Improvement I
Live Defect Peak
Internal Live
Defect Peak
[Call Type changed
to “#"]
CBIF Peak
Deferred Live Peak
See file name
Steve Browell
All should be Call Type “#”
All should have the Collection
HitLiveAffectingDefect
If HDR then relevant Collection should be
added
Updates do not auto replicate
Updates are system driven by reports:
1. Live Defects with the HDR Collection -
for the HDR meeting
2. CBIF qualifying Peaks ~ for the HDR
meeting
3. Live Defects excluding the HDR
Collection - reported (TBC) under
Continuous Improvement
4. Deferred Defect Peaks — for
information and tracking
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Actions
System Changes
o CBIF reason criteria added to the Release Mgt tab
One-Time Actions
o HDR
1.
2.
3. Steve Br — look at how HDR should be referenced in the contract documents
Page I 46
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Appendix A — Peak data anomaly checks
To ensure the data in Peak remains consistent with the intentions of the changes within this
document, period checks will be needed (in addition to the checklist actions owned by stack owners
and support staff) to ensure the data remains ‘clean’ and that the checklists can be updated to
gradually capture every potential edit needed. POA Defect Manager will need to enable automated
reporting and suitable cross-checking.
The checks relate to Peaks that have the ##LiveAffectingDefect Collection added.
Data Consistency & Accuracy
1. Wrong Call Type — check 1
o Collection contains ##LiveAffectingDefect
o Planned Out Live is blank or in the future
o Peak is not Status C
o Call Type is not Live Incident or Defect Identified
o Response Category is not NFF
Result set should be sent to the Assigned Team stack owners to challenge why the Call
Type is not “I” or “#”
2. Wrong Call Type — check 2
o Collection contains ##LiveAffectingDefect
o Planned Out Live is blank or in the future
o Peak is not Status C
o Response Category is “Product Error Diagnosed” or “Documentation Error
Diagnosed”
o Call Type is not Defect Identified
Result set should be sent to'the. Assigned Team stack owners to challenge why the Call
Type is not “#”
« If TFSBonded is set to t,and the POL SNOW Reference field has a value then
these Peaks should be cloned to Defect Peaks and the Peaks on the result set
should be closed
3. Unassigned Peaks
o Collection contains ##LiveAffectingDefect
o Planned,Out Live is blank or in the future
o Peak is not\Status C
o Assignee is _Unassigned_
Result set. should be sent to the Assigned Team stack owners to challenge why there is
no one assigned to own the Peak
4. Status is,“F’inal but the fix is deployed
o Collection contains ##LiveAffectingDefect
o Planned Out Live is in the past
o Peak is Status F
o Assignee is _Unassigned_
Result set should be sent to the Call Logger and Assigned Team stack owners to
challenge why the Peak has not been closed
5. Status is Open — appear to be waiting action
o Collection contains ##LiveAffectingDefect
o Peak is Status O
Result set should be sent to the Assigned Team stack owners to challenge why the Peak
has not progressed
6. Defect Identified - and still bonded to POL ServiceNow
o Collection contains ##LiveAffectingDefect
o Call Type is Defect Identified
Page I 47
Version & Last updated See file n
Document owner Steve Bre
Page I 48
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
000
°
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Planned Out Live is blank or in the future
Peak is not Status C
TFSBonded is 1
POL SNOW Reference is not blank
Result set should be sent to the Assigned Team stack owners to have the Peaks cloned
and closed
7. HDR — under investigation but not POL bonded
°
°
°
°
°
°
Collection contains ##LiveAffectingDefect
Collection contains HDR
Call Type is not Defect Identified
Planned Out Live is blank or in the future
Peak is not Status C
TFSBonded is 0
Result set should be sent to the Assigned Team stack owners to have the Peaks re-
created and bonded to POL ServiceNow (unless MAC team,confirm they are tracking
these by a different TfSNow INC reference in which case the Peak should be updated to
show the correct TfSNow Incident and POL SNOW reference field settings)
Steve B
See file name
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Appendix A— Peaks closed that POL should consider following up on
Peaks are closed when the outcome is something that requires a new feature request to be submitted
or sometime to explain why the solution works the way it does when that may in fact be causing
issues for POL or its postmasters. Peaks that are closed in this way warrant review by POL as it may
determine that it would like to add either new features or more user supporting features to reduce
Incidents and improve the solution. These should be reported on to POL for them to consider. The
frequency of sharing should be monthly with the list growing based on a cumulative view.
The checks relate to Peaks that have the ##LiveAffectingDefect Collection added and hence relate to
the Live system.
POL Feature Consideration Report
o Collection contains ##LiveAffectingDefect
o Peak is Status C
o Response Category is “Enhancement Request’ or “Advice after Investigation”
Result set should be extracted for sharing with POLin the\form ofa report
e Fields to include will need further work as they should ideally come from the
Peak itself and be clearly understandable
e The list should be sorted by Date Closed descending so the newer closed Peaks
are at the top
Page I 49
Version & Last updated See file n
Document owner Steve Bre
FU,
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Appendix A— Release Management checklist
To ensure the data in Peak remains consistent with the intentions of the changes within this
document,
4
2.
[Release Management] The key fields on any Peaks presented at BIF, CBIF or PTF must be
checked and amended accordingly
[Release Management] Peaks with release set to “Re-target” should have the PTF Action
automatically set
[Release Management] Check that Peaks that have the CBIF flags set do not have the PTF
action set until CBIF has been updated (catch the accidental setting of PTF Action after BIF but
before CBIF decision provided)
[Release Management] All Peaks with Planned Out Live (Date Out Live-field on Peak:screens)
in the past should be Closed. The ‘fix’ has been deployed. If they are Status’F,then the Call
Logger or Call Logger Team manager should ensure these are closed
[Release Management] All Peaks where the Planned Out Live (Date)Out Live field on Peak
screens) is blank or in the future should not be Closed as the*fix’.has not yet been deployed
co These Peaks can be closed if they have a No Fault Found Response Category as
this shows they were subsequently determined to require no action by Fujitsu
[Release Management] All Peaks with Target Release Type of “Targeted At” are Release
Management responsibility to drive to deployment demanding action from other teams as
needed to ensure timely progress
[Release Management] When a Peak is discussed, for the first time at a BIF, CBIF or PTF
meeting then the applicable Planned Date,and Actual, Date should be set to the same date. If
the Peak is re-presented at any of these:meetings then the Actual Date should change to the
date they were reviewed. Suitable comments should be added to the relevant section and
updates should be appended to maintain.a log
[Release Management] If a Peak is approved at BIF then it must have the “BIFApproved”
Collection added and the BIF Action removed
[Release Management] If a Peak.is approved at BIF and does not need to go to CBIF then it
must have the PTF Action set and the BIF Action removed
[Release Management] If a Peak is rejected at BIF then it is expected that the Peak will be
closed with an appropriaté‘update. The Peak must have the “BIFRejected” Collection added
and the BIF Action removed
. [Release Management] If a Peak is not approved at BIF (and not rejected) then the BIF Action
should remain so the Peak is picked up at the next BIF meeting
. [Release Management] If a Peak is targeted at PTF then the PTF Action should be removed
. [Release Management] If a Peak is not targeted at PTF then the PTF Action should remain so
the Peak is picked up at the next PTF meeting
. [Release, Management] The BIF Action should only be removed if BIF approves or rejects a
Peak
. [Release Management] The Root Cause on any Peak should be maintained and it should be
checked carefully when being targeted and prepared for release to live
. [Business Development] Any Peaks with the Collection "Deferral Agreed" should be Call Type
"#" unless the defect needs further investigation in which case it is Call Type "L"
e Deferred Peaks must have the ##LiveAffectingDefect Collection added once the
release they relate to is deployed (unless they relate to issues in test environments
and NOT the Live system)
e This can exclude Peaks where the Planned Out Live (Date Out Live field on Peak
screens) is in the past and the ‘fix’ has been deployed
. [ALL Dev Teams] When a Live Defect is confirmed, if the Peak is bonded to TfSNow and POL
ServiceNow then it must be cloned. The clone reference is to be added to the original Peak
and the original Peak closed with the Response Category “Cloned to create defect Peak”. If the
Peak is not bonded to TfSNow and POL ServiceNow then it can just have the Call Type
changed to “#”
Page I 50
Version & Last updated: See file n
Document owner Steve Bro
FUJ00232758
1J00232758
FU,
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
18. [ALL Dev Teams] When a Live Defect is confirmed and the Call Type is changed to “#” the BIF
Action must be set as soon possible so that the Peak moves quickly towards being targeted
19. [SSC] Peaks containing the HDR Collection that:
e Are not Call Type "#"
e Do not the Planned Out Live (Date Out Live field on Peak screens) in the past as the
‘fix’ has been deployed
e Are not closed as they had a No Fault Found Response Category
e And were not Deferred
must have a TfSNow and a ServiceNow Incident reference as they are under active
investigation and affect a POL branch so POL must be aware through the service management
toolsets
Process Consistency & Rigour
[Release Management] Peaks that are Defect Identified that are Priority Ator B or have a HDR-
* Collection must get an urgent BIF/PTF review to be assigned a Release as wéll.as a Release
Date. A hot-fix must also be proposed for POA/POL management decision
[Release Management] Peaks that are Call Type "# - Defect Identified’ but have not yet been
to BIF (BIF action not yet set and BIFApproved not in Collection) then.action is needed unless
they are scheduled for the next BIF meeting
«This can exclude Peaks where the Planned,Out Live (Date Out Live field on Peak
screens) is in the past and the ‘fix’ has been deployed.
« This can exclude Peaks that are Targeted At as they may have been handled prior to
the new processes
«These Peaks can be closed if they have a\No Fault Found Response Category as
this shows they were subsequently determined to require no action by Fujitsu
[Release Management] Targeted At Peaks should be Call Type "#" as the Defect is identified.
This should have been caught at BIF and/or PTF
«This can exclude Peaks Where the Planned Out Live (Date Out Live field on Peak
screens) is in the past and the ‘fix’ has been deployed
* These Peaks can be closed if they have a No Fault Found Response Category as
this shows they were subsequently determined to require no action by Fujitsu
[Release Management] Peaks that are identified as “Re-target” should have the PTF action set
to force the continued discussion so a next step is clear
[Release Management] Targeted At and Proposed For - where Planned Out Live (Date Out
Live field on Peak screens) is blank or in the future should be Open (O or P) and not Closed (F
or C). Although F is still technically open, the Call Logger may deem it acceptable to close it
prematurely = hence Status F should be avoided
[Release Management] Where release numbers are referenced in Target Releases, a date for
the release should be added and reasons why no date can be assigned should be challenged
(Release: Management] We need to highlight where the Target Release is ‘Rel. Ind.’ or ‘Next
Counter Release’ — perhaps with POL so they share our enthusiasm to schedule and fix - and
in so doing we keep momentum.
[Release Management] If a Peak has been to BIF it needs to have the BIFApproved or
BiFRejected collection added. If not then it should have the BIF Action flag set as it is to be re-
presented
[All] Managers/Team Leaders must check for Peaks that have been cloned to ensure the
reasons match the conditions agreed. If they do not, then appropriate action must be taken
(update the cloning rules, remove the clone, ensure the reason for cloning is captured on the
master Peak and that the purpose of the new clone is captured in the cloned Peak)
Page I 51
Version & Last updated: See file n
Document owner Steve Bro
FUJ00232758
1J00232758
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Appendix 8 - TSNow data anomaly checks
To ensure the data in TfSNow remains consistent with the intentions of the changes within this
document, managers will need to conduct manual checks. Those checks should cover at least the
following. Expanded checklists should be created within each team. The POA Defect Manager will
also need to do this at a cross-function level.
The checks relate to TfSNow Incidents that have had the ##LiveAffectingDefect or any HDR-*
Configuration Items added.
Data Consistency & Accuracy
e [Defect Manager] Check TfSNow Incidents ...
Page I 52
updated See file name
Steve Browell
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Appendix C — draft criteria for closing Defect Peaks with NO action
There will always be Live Defects that experience and judgement says are simply not worth fixing. To
ensure this is a matter of policy and not one of subjective decision making, criteria is needed that
staff can use to make decisions.
The following is an initial draft to build upon.
A fix for a Live Defect will NOT be progressed if at least THREE of the following conditions apply:
* The frequency of occurrence of the Live Defect is rare — less than TWICE perannum,
* The impact of the Live Defect is minor — it does NOT affect branch operations,or Fujitsu
service delivery
* The impact of the Live Defect only affects Fujitsu service delivery— and Fujitsu has
compensating controls in place and Fujitsu management,has agreed to taking no action
* The impact of the Live Defect is accepted by POL — andya KBA has been created by both
Fujitsu and POL clearly stating the decision and the decision maker
* The Live Defect is in a part of the system that will be,decommissioned before any fix could
be developed and deployed
* The Live Defect relates to Fujitsu intemal documentation only and the remedy will not affect
the understanding or support of the system by Fujitsu
Live Defects recorded in Jira’s,that meet the above criteria do not need to be raised as Peaks as
doing so would simply see the Peaks immediately closed. A Jira that describes a Live Defect that
would warrant a KBA must havea KBA written to help future support activities.
Page I 53
Version & Last updated See file n
Document owner Steve Bre
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Appendix D - HDR Report Creation Work Instructions
To create the weekly HDR Report which is shared with POL, follow these steps:
°
°
As at the date of this document, the criteria to be used to determine HDR reporting
candidates to share with POL will be determined by creating 3 lists using the following logic.
The resulting lists will then be merged and the HDR candidates identified.
A spreadsheet format has been used to date so the previous week’s POL HDR Report
submission should be used as the basis for the new report — removing all previous week
highlighting and deleting rows scored out as POL have been told these are being removed
Then, open the Peak_Defect_Management spreadsheet and Enable Content and go to the
Data tab and click Refresh All on each tab. The password to run the embedded queries
needs entering 3 times and i
when the extract was created —S0 it an be referred back to
Filter the Peak_Defect_Management spreadsheet ##LiveAffectingDefect tab on these values
first:
« Must have the ##LiveAffectingDefect Collection (relates to the Live system and
does, or might, need a fix) — auto done for yowusing'the ##LiveAffectingDefect tab
e Must have the either the HDR-Fin or HDR-Exp Collection (Collections contains HDR)
e Must have a Planned Out Live date, in the future or blank (it has not been deployed)
« Must not have the Response Category setito any of these values as these are No
Fault Found:
Response Category — 62 -- Final — No fault in product
Response Category — 63 — Final -- Programme Approved — No Fix Required
I Response Category — 66 — Final -- Enhancement Request
Response Category — 68 -- Final -- Administrative Response
Response Category — 72 -- Final -- Duplicate Call
Response Category — 94 -- Final -- Advice and guidance given
Response Category — 95 -- Final -- Advice after Investigation
Response Category — 96 -- Final -- Insufficient evidence
" Response Category — 97 -- Final -- Unspecified insufficient evidence
I Response Category — 98 -- Final -- User error :
Response Category — 100 -- Final -- Route call to TfS.
Response Category — 120 -- Final -- Cloned to create Defect Peak
Response Category — 200 -- Final - Call withdrawn by user
List 1 — Deferred Live Defect Peaks
e Must also have the Collection “Deferral Agreed” (Collections also contains “Deferral”)
e These are unlikely to be discussed at HDR as they are previously approved and
understood but are provided to show the level of Fujitsu control
e Extract the list showing:
Page I 54
Version & Last updated: See file n
Document owner Steve Bro
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
= Category (HDR-Fin = Impact, HDR-Exp = Experience)
« Place the entries into the correct Impact or Experience section
= POL Reference (set to N/A)
= Then copy the data fields from the Peak_Defect_Management subset the
filters have derived and paste to replace the Deferred Defects list on the
POL HDR Report
e Fujitsu Reference (the Peak Call Reference)
e Summary
« Confirmed Defect (Call Type is Defect Identified = Yes, otherwise
No)
« Workaround
impact
o Next Lists — non-Deferred Peaks
« Must NOT have the Collection “Deferral Agreed” of “Deferral Proposed” (Collections
does not contain “Deferral”
e List 2 — Project Live Defects.
= If clearly from a Project that is under a.controlied rollout where the Fujitsu
and POL Project Managers are working together (e.g. PBS — identifiable by
the use of “PBS” or “PITPOS" {which is an)Ingenico Jira reference}, or other
identifiable text)
« Summary contains “PBS or contains “PITPOS”
= There may be none
= These are unlikely to be discussed at HDR as they are part of the ongoing
Project Manager regular review calls
= Extract thelist showing:
« Category (HDR-Fin = Impact, HDR-Exp = Experience)
o Place the entries into the correct Impact or Experience
section
@, POlbReference (set to N/A)
* © Then copy the data fields from the Peak_Defect_Management
, subset the filters have derived and paste to replace the Deferred
Defects list on the POL HDR Report
o Fujitsu Reference (the Peak Call Reference)
o Summary
o Confirmed Defect (Call Type is Defect Identified = Yes,
otherwise No)
o Workaround
roast [wa wove,
e List 3 — non-Project Live Defects (likely originating from an Incident during normal
service delivery)
= These will be those that remain that are NOT on Lists 1 and 2
= These require more comprehensive information as these will be discussed at
the HDR meeting
* Having reached this point there will be a small number of entries left
Page I 55
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
= This needs cross-referencing to the previous week's submission to check if
anything is new or if anything has disappeared. This will need manual
checking for confidence
= To do this start with the POL HDR Report list and check if they are still on
the data subset showing on the Peak_Defect_Management filtered list in
view
e Note any that seems to have gone so you can check why
e Add any that seem to be new so you can check later
= Some may still be under investigation. They will have a Call Type of “Live
Incident” and will have TfSNow/ServiceNow Incident references
= Some may relate to Fujitsu Problems. The Collections should contain
“FJPRB-". For these, the Fujitsu Update should be the latest entry in.the
relevant Fujitsu Problem record in TfSNow
= The remainder should have the Call Type “Defect Identified’»For these, the
Fujitsu Update should be derived from the Business Impact field which will
need to be checked and improved if necessary
= Extract the list showing:
« Category (HDR-Fin = Impact,HDR-Exp = Experience)
co Place the entries into the correct Impact or Experience
section
e POL Reference (this should.be known unless the entry is new)
e For new entries, copy the data fields from the
Peak_Defect_Management,subset the filters have derived and paste
into the new line youwhave created on the POL HDR Report
o Fujitsu Reference (the Peak Call reference for Call Type #,
‘otherwise the TfSNow/ServiceNow Incident or Problem
feference)
o), Summary
o Confirmed Defect (Call Type is Defect Identified = Yes,
otherwise No)
o Workaround
o Business Impact (or latest Problem record update if known
to be being managed as a Problem)
Beans I r
* » Compare the previous HDR report to the new list and amend accordingly so the new
HDR report list matches what the system now shows
= Any that have been closed should be scored out and highlighted in yellow
= Any that are new should be added to the relevant Impact or Experience
section and highlighted in red
e These then need scrutiny to ensure they look correctly tagged as
HDR and that the Impact is accurate. If they are HDR then the
required fields for the HDR report need to be checked with SMEs
and 4LS chased for updates. These red entries are the ones
reviewed by the Fujitsu HDR meeting attendees prior to the HDR
report being submitted
«When the report is ready to submit, the highlighting should be
changed to yellow
Page I 56
Version & Last updated: See file name
Document owner Steve Browell
Page I 57
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
= Any existing entries that remain on the list should be checked for updates to
the Impact statement and, if progressing from Live Incident to Defect
Confirmed, to amend the reference from a TfSNow Incident to the Defect
Peak reference
e The far right column “Change from last week” should be used to say what has
changed so it is clear where to look and why. It should also be set to yellow highlight
if it has changed
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Appendix E - CBIF Submission Extract Work Instructions
To identify if there are any CBIF submission necessary to POL, follow these steps:
o Asat the date of this document, the criteria to be used to determine CBIF candidates to
share with POL will be determined by creating 3 lists using the following logic. The resulting
lists will then be merged and the CBIF candidates identified. A CBIF Proposal will then be
needed as this is what will be submitted to POL.
co Filter on these values first:
« Must have the ##LiveAffectingDefect tag (relates to the Live system and does, or
might, need a fix)
« Must be Call Type "# - Defect Identified" (a fix is needed)
e Must have a Planned Out Live date in the future or blank (it has not,been deployed)
e Must not be Targeted At (Target Release Type is not Targeted At) as this means it
has gone through PTF already
« Must not have a HDR Collection (or it has been to! HDRoanyway)
¢ Must have a date in the BIF Planned Date (it has to have been to a BIF meeting)
° Must have the BIF Approved Collection set or have a I BIF Completed Date in the
past (it has been technically qualified)
« Must not have the BIF action set meaning it needs further discussion at BIF
(Actioned Team is not BIF)
e Must not have the PTF action set as that means it has gone past CBIF (Actioned
Team is not PTF)
« Must not have PTF dates as that means it has gone past CBIF (PTF Planned Date is
blank)
e Must not have the Pa Category set to any of these values as these are No
Fault Found:
I Response Category — 62 -- Final — No fault in product
Response Category — 63 -- Final -- Programme Approved — No Fix Required
Response Category — 66 -- Final -- Enhancement Request
Response Category — 68 -- Final -- Administrative Response
I Response Category — 72 -- Final -- Duplicate Call
I Response Category — 94 - Final -- Advice and guidance given
I Response Category — 95 -- Final -- Advice after Investigation
Response Category — 96 -- Final -- Insufficient evidence
I Response Category — 97 -— Final -- Unspecified insufficient evidence
Response Category — 98 -- Final -- User error
Response Category — 100 -- Final -- Route call to TfS.
Response Category — 120 -- Final -- Cloned to create Defect Peak
Response Category — 200 -- Final - Call withdrawn by user
© Then, in turn, check these filters to build the 3 lists:
e List 1 — high priority Live Defects:
Page I 58
Version & Last updated See file n
Document owner Steve Bre
FUJ00232758
FUJ00232758
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
= Must be Priority A or B (highest impact defects)
e List 2 — Live Defects that originated from a POL ServiceNow bonded Incident:
= Must have a POL SNOW Reference
e List 3 - Live Defects explicitly identified at BIF for taking to CBIF:
= Must have a CBIF Criteria checked marker — BIF_Ticked_Questions is not
blank (BIF selected it for CBIF)
Page I 59