FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Contents
Introduction...
Terms and Terminology.
New terms...
Terminology — Overview...
Systems and Teams...
Managing Incidents.
Managing Problems...
Actions.
System Changes..
New Ways of Working.....
Managing Peaks....
Release Management.
Actions,
System Changes..
New Ways of Working
Live Defect Management — Live DefectDefinition.
Live Defect Management — Goals.
Live Defect Management — Key Fields in Peal
Live Defect Management — Reporting.
Actions.
System Changes.
One-Time Actions.
New Ways.of Working...
BI
CBIF...
PT Fiscs
HDR....
KB — Info only...
Release Mgt tab — for BIF, CBIF and PTF...
CBIF / HDR Diagram
Appendix AO — Checklists for TfSNow Resolver Group & Peak Stack owners...
Appendix A1 — Peak data anomaly checks.
Page I 1
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Appendix A2 — Peaks closed that POL should consider following up on..
Appendix A3 — Peaks closed with no obvious Release...
Appendix A4 — Release Management checklist.
Appendix B1 — Live Defect Management Monthly Report Creation Work Instructions.
Appendix B2 — Live Defect Management Weekly Progress Chaser Email Creation Work Instructions 55
Appendix C — DRAFT criteria for closing Defect Peaks with NO action..
Appendix D — Weekly HDR Report Creation Work Instructions...
Appendix E— Weekly CBIF Submission Extract Work Instructions.
Appendix F — No Fault Found Response Category values.
Page I 2
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232804
FUJ00232804
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)
¢ 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
¢ 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
e 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
e 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”
e 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 “#”
PageI 3
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
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 andmanaged 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 sourceoof all relevant content
MUST be TfSNow.
Problems
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:
Peaks
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.
o 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.
Release
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
o 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
Live 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
Page I 4
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
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)
Note: Only one HDR-* Collection needs to be set and if both could apply then HDR-Fin should
be chosen
IAdd Incident to Collection
HDR-Exp —- Horizon Defect Review - SPM Experience [Public] ¥][ Add to Collection
"7
HDR-Exp ~- Horizon Defect Review - SPM Experience [Public]
jorizon Defect Review - Financial Impact [Public]
e There may be a workaround, but the underlyingiissue 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 (aypotential 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 DefechManagement
o All Live Defects must be rigorously managed until resolved.
o 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.
BIF
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 I5
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
co The criteria are shown later in this document and that criteria will be agreed with POL.
o CBIF will become part of the POL HDR weekly meeting.
co The Horizon Defects Review (HDR) Forum is the new name for what was the Known Error
Review Forum (KERF).
o 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.
o There must be a POL Problem reference and a corresponding Fujitsu Incident, Peak.or
Problem reference.
o The updates to the Fujitsu tracked Incidents, Peaks and Problems will be shared at the HDR
Forum.
KB
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).
o KBAs do not need to be shared with POL as the tracking needs to be on the Peak and/or
Incident.
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 KBA so that the Incident that POL see
is a suitable complete reference.
Page I 6
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Systems and Teams
Managing Incidents
o An Incident is defined in the HNG-X contract as “any perceived abnormal or undesirable
occurrence relating to the Services”
o 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
o 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)
o Service Operations should only use TfSNow for communicating Incidents,between Fujitsu
and POL
o Incidents cannot be raised by email by POL or Fujitsu. Incidents must be raised in TfSNow
by Fujitsu or in ServiceNow by POL
o The Summary field should be understandable by most readers as this feeds Peak and also
shows on reports
e Forsystem monitoring this is set by SMC, bonded incidents it comes from POL,
otherwise it's Fujitsu staff (MAC & Security) that choose its content
co The Incident should be a complete and comprehensive self-contained reference to the status
of an Incident
o Incident progress MUST be shown on.the Incident im TfSNow and cannot be managed via
separate emails. Emails must be added to the,Incident in TfSNow if relevant to
demonstrating progress or status
o The Incident should appear to be integral = the fact that 3 and 4" line use a different toolset
should not be apparent
co 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
o 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)
o 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
o Aclear 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
e 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]
o 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 7
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
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
e 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 Insufficientevidence 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 is
PageI 8
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
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,it.is awareof 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
« Is, or appears to be, inconsistent with the agreed design or service specification
e Is, therefore, a fault that is likely to needsfixing
¢ Incidents that meet the definition of a/Live Defectymust have the
“LiveAffectingDefect” Cl added in TfSNow
e 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 theincident
= 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 AnIncident 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 9
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
= Configuration items Search Name
1 I to200f1235 >
7 _Al>Name>=HOR
Q Bname a SAssettag = Serialnumber = Company = Managed by
Search Search Search Search Search
HOR-EXP POA (empty)
HOR-FIN POA (empty)
e Affects, or has the potential to affect, branch financial outcomes (add the “HDR-Fin”
Cl)
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” Cl)
e Affects, or has the potential to affect, the experiencé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 themHDR-Fin should be chosen
o When the HDR* Cl is applied to an Incident, Fujitsu MAC.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 isyalso 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 Reeturring Incidents and Incidents with follow up actions require a Problem record to be
created, The Incidents are linked to the Problem
o To ensuré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
e For each, show views based on:
= Open category & Close codes
= Cl associations
« — Internal response times by type/priority
Page I 10
Version & Last updated: See file name
Document owner: Steve Browell
°
FUJ00232804
FUJ00232804
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 issuesidentified 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):
= Configuration items Search Name
1 to200f1,235 >
FJ Al>Name>=HoR
Q SName a S Asset tag
= company = Managed by
Search Search Search Search Search
HOR- EXP POA fempty)
@ HOR-FIN POA fempty)
e Affects, or has the potential to affect, branch financial outcomes (add the “HDR-Fin”
cl)
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” 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-* 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 and a
Problem (the former for management, the latter for joint process validation)
Page I 11
Version & Last updated. See file name
Document owner: Steve Browell
Actions
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
System Changes
e 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 Referenceiis.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 12
Version & Last updated. See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
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
co 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:
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 need fixing
...then it must be given the ##LiveAffectingDefect Collection and an Incident must be raised
in TfSNow if one is not already open.
I Add to Collection
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)
e Affects, or has the potential tovaffect, the way a postmaster is required to use the
system (User InterfaceyReport, 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
[Add Incident to Collection
HDR-Exp ~- Horizon Defect Review - SPM Experience [Public] ¥ [Add to Collection I
—
jorizon Defect Review - SPM Experience [Public]
Horizon Defect Review - Financial Impact [Public]
HDR-Exp -
Hl
co 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 13
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
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
See section Live Defect Management — Key Fields in Peak
o Cloning processes and rules need to be applied consistently:
Page I 14
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 Bridge do \not clone Peaks but instead they
obfuscate the original so it can be widely shared 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 anjincident)
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 tare. 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: if a 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:
Create a Defect Peak
‘Split into multiple streams
Disassociate from TfsNow ticket
Test rig reasons
Other
Enter new clone Summary:
{Clone test 2 - Testing Peak development
Version & Last updated. See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e 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 09:00:38 User: John Simpkins
ICALL PC@250898 opened
Details entered are:-
iSummary:test mb problem
Clone Reason: Create a Defect Peak
(Date:14-Dec-2015 15:52:55 User: _Customer Call_
ICALL PCO244669 opened
Details entered are:-
Summary: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.
e 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
e The Developers & Architects decide if it relates toLive 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 that:theelated, 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
Rules,on use of Call Type need restating so we ensure greater consistency
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
co 'Private' Peak updates can be added to the Progress field. They stay in Peak and are not
replicated across the OTI. Updates added the Response field are replicated across the OTI
« See screenshot
Page I 15
Version & Last updated: See file name
Document owner: Steve Browell
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
irwes.zes ose sons « [ese « [1194-1-56-809-3) - [ sttangt to wee Lali Sours Sequence sumer 38 SASL72, sable the corre
Progress Tet Prope Tompies
i Pose m
Note This isan OTI Provider Inset
*+ Progress Onty updates wal ot be eto the Consumer
Pentng Revpoes vl be et the Conner
1 Fit Respomes wl pn he cient back the Corser
(log te Pek)
Response Category I Fa) fer (hewn)
Developaeet tied) No Fercat Dae
([peekte deta] save]
Edited
Note the Text on the right-hand side of the progress entry box for further guidence.
If you select a response category then the text above the Progress changes to reflect this:
——
———
1 Pentng Response wile sat te Conner
{Fina Reger wal pose mde! sk he Cont
(donee
Response Caepery Fal sien own)
Forcat Dae Drlopmcet(MaaDeys) NoForecat Dae
No references will be sent across to TFSNow (or beyond) so all Documents, Baselines, KBs, Peak etc
can be added as references
FUJ00232804
FUJ00232804
co 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:
e Incident,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),
of 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
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
Page I 16
Version & Last updated. See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e “41 General — in Procedure” — caused by not following defined procedure
co 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
o 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
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 aay Fault Found/No Action
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 Unidentified Root Cause
Call withdrawn by user Cancelled
Fixed,atiFuture 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
Release Management
o Deferred Peaks should be recognisable against the release they were deferred from and the
release to which they are subsequently targeted
Page I 17
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
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
e the “Deferral Agreed” Collection set
e The Call Type set to “#’ if the Live Defect is confirmed and a fix canbe 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
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
HOR-Exp ~ Horizon Defect Review - SPM Experience [Public] © [Add to Collection
Sa
=
HDR-Exp ~ Horizon Defect Review - SPM Experience [Public]
HOR Fin — 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
spreadsheetithat can attached to the TfSNow Change ticket (format similar to below):
(Cal Reference unary [POL Problem Refiujtsu Problem Ref
1PC0295314-LST20.94 Proper messages has to dspaly stead of Agent eves inDCM_LREC.DCM_CREATE LREC_C4D jo
19C0298403 LST: 20.94: Too may D records in LREC fe
9C0295711 PBS Pio: INCS349716: Amex tu nt sted as expected when econiing DRS? reports
1960295725 PBS: INC83S4763 (TFSNow) :INCO3887I8 Lloyds £300 witraval [MCSUK-16376]
Gose
o Release Notes will not list:
e 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)
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
° Te ton of ey Release shouety SSC Sth ary eat KBAS canbe
BS
Page I 18
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
Page 18 Comments
BS1 RM will need to ensure SSC are overtly notified
SSC will need a process to take the required action
Browell, Steven, 25/08/2021 03:44 PM
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
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.
co If arelease has gone Live, then any Peaks which require a hotfix should)NOT beTargeted 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 so on
e 71.10-the master release was 71.10, already released from Fu 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
o Any peaks that are not urgent, and therefore 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 atleast 1 live branch saw new code installed)
e All future Releases must show,the latest anticipated release date for deployment —
irrespective of whowill 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.
e The TargetRelease 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 Incident Management System
I sain nee <
mau ——Ey eve Sea Nene 951
‘Pinout I Pontoon) a
Soe Change [Rese J Oo Rone rend
Incident Management
Stow wie
f=—r
feed fo in
Page I 19
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e 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 (DDMM'YYYY) ‘Actual Dates DDMM/YYYY)
(Out Development [ J
‘Out Integration [ J
Into LST i
‘OwLsT [ J
Into Production, [ i} I
« 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
« We all know that the goal is to progress from logging a perceived. fault tosfixing 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 determineWhat weyfix 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
e Create a button alongside the listed\Peaks onjthe 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 thénwecord it in the new cloned Peak, updated the cloning
process to take more fields‘across\to the clone
« To create menu list for reason for creating a clone and also to enable the Summary field to
be changed to a more appropriatestext string
New Ways of Working
1. Managers willmeed 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
AO
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
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.
othe ##LiveAffectingDefect Collection is set (if applicable)
othe “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
Page I 20
Version & Last updated See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
o Target Release Type changed to “Proposed for” for subsequent update via BIF/PTF
co 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)
Page I 21
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232804
FUJ00232804
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
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
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 financialloutcomes,(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)
IAdd Incident to Collection
HDR-Exp —- Horizon Defect Review - SPM Experience [Public] ¥][ Add to Collection
—
HDR-Exp ~- Horizon Defect Review - SPM Experience [Public]
HOR -Fin — Horizon Defect Review - Financial Impact [Public]
e There may be a workaround, but the underlying issue still meets the criteria above
e An Incident may be underiinvestigation that is not confirmed to meet the criteria
above but has attributes that meet the criteria above (a potential Live Defect/HDR
Defect)
co 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 ahid.: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:
« Live HDR Defects
_. Live (Non-HDR) Defects
« ~WNon-Live Defects (test/dev etc) — not tracked by Live Defect Management
co Note,3: 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 22
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
efect Management Changes
hhave been some changes to the Defect Management process to enable more accurate reporting. Please consider the following when reviewing a potential defect Peak:
Is this a Live Defect? If so, add the ##LiveA fectingDefect Collection,
Is the Call Type correct? Change to L ~ Live Incident or # ~ Defect Identified as applicable.
Does could this affect branch operations? If so, add either the HDR-Fin (Financial) or HDR-Exp (Experience) Collection.
Is there a Workaround? If so, add the Workaround Reference field and set it to Yes.
Have you added a Impact update? There is a new template to guide adding an impact.
Is the Priority correct? The default priority from TFSNow is often too low
re the Product & Product Group fields correct? Multiple products can be added if required,
is the Status (Response Category) correct? Does it reflect the current activity inthe defect process,
Where possible ensure your progress updates are understandable to non-technical users.
Peak Incident Management System - RMG Account
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 We need 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
o 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
contentiand 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 It is 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 23
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
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
o 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
o 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
co 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
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, mustiensure:
« the ##LiveAffectingDefect Collection is set where,applicable
Add to Collection I
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 setito “L” if the Live Defect still needs further
investigation
Admin Held
Peak Inciden
I REFERENCES o
fallReference _[PC0294913
[Release [Targeted At - HNG-X 21.52
[Call Type T--Live Incidents v
C~ Cloned call
E ~ Enhancement Request
F — Document Review/Design Walkthrough
G ~ GDC Testing incidents/Defects
I ~ Intemal Development Incidents/Defects
K — Primark
on SV&l BAUHBS.
ate: 01-Jun-2021 2:
LL PC294913 ope
VAI BAL/HES
‘M-— Problem Management
‘0 ~ Operational (SSC)
Product Incidents/Defects
R~ Release Notice Forum
‘System Testing Incidents/Defects,
frnczoent nanacenent ¥ ~ Technical query
ate/Time Raised: 3IU— Security Testing Incidents/Defects
V—Vuinerability
~ Reference Data Service
/stem Management Testing Incidents/Defects
ive (Non-RefData) Data Updates :
Page I 24
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e 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 applythen HDR-Fin
should be chosen
IAdd Incident to Collection
HDR-Exp -- Horizon Defect Review - SPM Experience [Public] II Add to Collection I
7
HDR-Exp ~ Horizon Defect Review - SPM Experience [Public]
HOR-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 live,and when future Releases are proposed for
so we have an outcome for any defect Peak
We need to provide a full list of ALL Live Defects closed in a Release with their associated
POL Problem references so that POLare 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 POL,reference 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 be\documented 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
co 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 haveibeen tested successfully and are still to be deployed must not be closed and
mustbe 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
°
for a slot to deploy as it is the date the fix could have been applied that is key — not the date
°
Page I 25
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
Page 25 Comments
BS2
BS3
SB to decide how this is tracked
Browell, Steven, 09/08/2021 03:31 PM
Date Opened to PTF Actual Date is how quick we determined way forward
Planned Out Live for Release is the first date the fix could go in
We need to avoid dependencies on POL to progress things so we drive the pace
Browell, Steven [2], 12/11/2021 10:20 AM
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
o Anumber of Response Category field values are considered No Fault Found. See Appendix
F
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 classed as ##LiveAffectingDefect that is open and still being investigated
should ensure progress is made optimally
o If we have a Live Defect 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)
c. Geta strong proposed date for these Releases (So we have a go live date in
mind) — this may require more input from/POk
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 teleases with confirmed dates
d. Stack owners and Release Management must ensure this is done
e. We should expectto putLive Defects that are Defect Identified into the next
month's maintenance release ‘at the latest’
co If we determine thatprogressing a Live Defect is not the best option (for example the feature
is being migrated and anysfix would serve little purpose) then we should act as follows:
e If there is a Live/Defect then we have an obligation to fix it
e We eithenfix it, or we get permission not to
e Permission ¢an be from POL (ideally) or from POA DE/VP (second choice) — but
they,have to be empowered to say “do nothing”
e We then write a KBA to describe the approved fault so future calls know that no
action is required
« We associate the KBA with the Defect Peak we will not be actioning
e We set the Response Category on the Defect Peak to “Programme approved — no fix
required” (so it is treated as a no action Peak)
« We close the Peak
e We leave the KBA open
o 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 implication of not allowing us to
progress them
Live Defect Management — Key Fields in Peak
The following are the key fields needed for Live Defect Management:
o Call Type - must be set to “#” Defect Identified when a Live Defect is confirmed. Prior to this
Page I 26
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Live Defects ought to be Call Type “L” Live Incident but can 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
i
if DETAILS REFERENCES PRODUCTS EVIDENCE IMPACT
all Reference [Pco295241
[Release [Reported In -- HNG-X Rel. Ind.
all Type © —- Operational (SSC) v
‘A-- Administrative use
[Impact C - Cloned call ng/not yet defined/TBA] St
E — Enhancement Request 7" ____
F — Document Review/Design Walkthrough
ate: 16-Jun-2021 10 G ~- GDC Testing Incidents/Defects
LL_PC@295241 oper I - Internal Development Incidents/Defects
etails entered areIK — Primark
Summary:testing I L - Live Incidents
all Type:L M - Problem Management
all Priority:D I _ Operational (SSC)
‘pI P~ Product Incidents/Defects
R — Release Notice Forum
S ~ System Testing Incidents/Defects
resting dev MD T~-Technical query
[End of Response] IU — Security Testing Incidents/Defects
Response code to cal V— Vulnerability lem Identified(38)
~Jun-2021 = W — Reference Data Service
fment
The Call record hasI X ~ System Management Testing Incidents/Defects ps
ate: 16-Jun-2021 10I Y — Live (Non-RefData) Data Updates +
velopment Cost updated? new cost is vs
[Start of Response]
est 1
[End of Response]
lesponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
ate: 16-Jun-2021 10:51:@8 User: John Simpkins
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)
o Impact = tabjand 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
e 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”
Page I 27
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
IAdd Incident to Collection
¥ II Add to Collection
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
~ SPM Experience [Public] __vI[ Add to Collection I
TOOT
pS DT TET =
HDR-Exp — Horizon Defect Review - SPM Experience [Public]
HDR-Fin — Horizon 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)
03/11/2021 Added to Collection ##LiveaffectingDefect by John Simpkins.
@3/11/2021 Collection ##LiveaffectingDefect removed by John Simpkins.
@3/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.
@3/11/2021 Collection HDR-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:
Peak Incident Management System -PU298241
i000
eat I SE
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 following screenshots shows
how to add the field:
Page I 28
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Peak Incident Management System - PCO29S247
AGG
Fy
l
o Workaround - to state “Yes/No” state if a 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
« Workaround is a Reference field and the following 2 screenshots show how to add
the field and set its value:
veak Incident Mlanageinent System -PCUZ9S241
aie
fecuzomase
[pcmicoo
ST]
ai
aa]
Peak Incident Management System - PCOZ
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
Page I 29
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
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
e 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 least weekly
A reminder will pop up on certain changes of Peak status to remind support staff to consider
the key fields:
e Events triggering presentation of the pop-up:
= The Peak Routing is changed
= The Call Type is changed
= The Response Category is changed.
= The ##LiveAffectingDefect Collectionis 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 lastupdate 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?
Live Defect Mahagement —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, Call Type, 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, BIF_Ticked_Questions,
Page I 30
Version & Last updated. See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
HDR_User, HDR_Date, BIF_User, BIF_Date, TFSBonded (1/0), Assignee, Time to
Target (Days)
Actions
System Changes
e Rename ##LiveAffectingSoftwareFault to ##LiveAffectingDefect and apply to all currently
tagged Peaks
e Rename Call Type "L" to remove “/Defects” from label
e New Workaround field with optional text values Yes/No
e New Call Type value of "#" for Defect Identified
¢ New HDR Collections of “HDR-Fin” and “HDR-Exp”
« Updated Release Mgt tab to add BIF, CBIF and PTF fields above current list (to,hold dates of
meetings and outcome summaries)
e Amended default guidance text for the Impact text box
e New Reference type of POL Problem Reference and enforce POLPRB- prefix
e New File Type of “CBIF Proposal”
« Removed “30 -- Pending -TL confirmed” Response Category
e 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”
e Added new Response Category “Cloned to create Defect Peak”
e Added text box to ask user why they are cloning,writing the response into the start of the
clone
e Added capability to setup email alerts if specific Collections are added or removed
e 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
1 Architecture
e 6 Design - Platform Design
7 Design - High Level Design
« 8 Design - System Outline
e 13 Development - Build Scripts
e 14 Development - Code
e 15 Development - Low Level Design
e 16 Development - Reference Data
e 21 Requirements
e 24 Cfg Mgt - Config Data Error
e 26 Integration - Build
e 31 Test - Test interpretation
e 32 Test - Script
¢ 33 Test -Data
¢ 34 Test - Environment
e 37 General - Network Change
e« 38 General - Hardware Fault
Page I 31
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e 39 General - User Knowledge
e 40 General - User
e 41° General - in Procedure
e 42 Gen - Outside Program Control
e 43 General - Operational Change
e 96 Gen - Investigation On-Going
e 97 General - 3rd Party issue
¢ 99 General - Unknown
—
2
3. 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 definedthat sees defect Peaks
either closed or actioned where currently they seem to havé’stagnated
4.
5. Steve Br - Agree a process for CBIF Proposal creation
6.
7. Steve Br — Investigate implications of Post,Office Cloud on ways of working. Check how Live
Defects are being recorded in AWSWIRA andbe 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)
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 Appendices A for checks
Page I 32
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
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
e Ifthe 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
= Add the ##LiveAffectingDefect Collection
‘Add to Collection I
ublic)
= If the cause and required action to remedy are»
¢ Still being investigated — then set the Call, Type to "L"
e Are confirmed — set the.Call Type to “#” and also update:
o Root Cause field is up to\date
Peak In:
{- petans REFERENCES, PRODUCTS EVIDENCE IMPACT
[Call Reference 0295241
[Release [Reported In — HNG-X Rel. Ind
[Call Type © — Operational (SSC) ~
ee ’A--Administratve use ;
(C= Cloned call i defned TBA] St
E — Enhancement Request =
F ~ Document Review/Design Walkthrough 3
GDC Testing Incidents/Defects
intemal Development Incidents/Defects
~ Primark
~ Live Incidents
“Problem Management
~ Operational (SSC)
~ Product incidents/Defects
Release Notice Forum
~ System Testing Incidents/Defects
T Technical query
U. Securty Testing Incidents/Defects,
V— Vulnerability
W Reference Data Service
X ~ System Management Testing Incidents/Defects
Y ~ Live (Non-RefData) Data Updates
velopment Cost upda =
[(start of Response)
rest 1
I[End of Response)
tesponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
jate: 16-Jun-2021 10:51:08 User: John 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 33
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
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
oc. BIF must consider the proposal (as it does currently) and also validate the following data
values for defect Peaks:
¢ = 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
= Ensure the ##LiveAffectingDefect Collection is set
Add Incident to Collection
#4LiveA\fetingDefect - Faul thatis present on the Live system fats inconsisten_ [Pubic ©] Ads to Collection
= If the cause and required action to remedy are:
¢ — Still being investigated — then’setthe Call Type to "L"
« Are confirmed — set the Call Type to “#” and also update:
o Root Cause field is up to date
Peak In
DETALS —II_REFEREN I___ PRopucts EVIDENCE IMPACT
[Pco295241
[Reported In -- HNG-X Rel Ind.
‘O — Operational (SSC) v
‘A- Administrative use as
C— Cloned call figinot yet defined TBA] St
E ~ Enhancement Request ee
F —- Document Review/Design Walkthrough
G ~ GDC Testing Incidents/Defects
1 Internal Development incidents/Defects
K ~ Primark
L— Live Incidents
M-~ Problem Management
_I 0 ~ Operational (SSC)
P Product Incidents/Defects
I R ~ Release Notice Forum
S ~ System Testing Incidents/Defects
T— Technical query
[End of Response] IU ~ Security Testing Incidents/Defects
iesponse code to caIV~ Vulnerability flem Identified(38)
ate: 16-Jun-2021 10] W -- Reference Data Service
1 record vs X ~ System Management Testing Incidents/Defects ps
jun-2021 10] Y -- Live (Non-RefData) Data Updates a
velopment Cost updated? new cost Is 2 (Man Days)
[start of Response]
fest 1
i[End of Response}
lesponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
jate: 16-Jun-2621 10:51:08 User: John Simkins
= 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
Page I 34
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
= Check if the new HDR Collections of “HDR-Fin” or “HDR-Exp” should apply.
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
Tncident to Collection
HDR-Exp ~ Horizon Defect Review - SPM Experience [Pubic] ¥ J Ads to Collection
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 aré;on the Release Mgt tab under the
BIF section
* Thesfix can be done in more than one way and POL would need to
guide Fujitsuon choosing the preferred option.
* — The fix may change the functionality of the system and consequently
POL will be required to provide appropriate communication, and
potentially training, to the subpostmasters.
* \/ The fix 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
oO. The BIF chair must record, in Peak on the Release Mgt tab, what decisions are made:
Page I 35
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
The new BIF date fields (Initial and Completed) will,need tobe completed during, or
after, the BIF meeting (not before or it will affect status reporting)
= Initial date - will hold the date of the first\BIF the Peak was first presented at
— this value should not change
= Completed date - will hold the last BIF meetingythe 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
If the Peak is approved at BIF\then the BIFApproved Collection must be added (also
for BIFRejected)
[Add Incident to Collection
[EiFApproved — Approved for fx by the Business Impact Forum [Team] SJ Add 0 Collection
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 Ifthe 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 is a 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 I
Extract Criteria below for the system value that will ~
determine CBIF applicability
Page I 36
MM
Document owner:
Steve Browell
°
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
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:
e 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 ofthe 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
e The outcomeéiof 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 Peakyneeds 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
e 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
¢ 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”
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
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 37
Version & Last updated. See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
All Peaks with the PTF Action flag set will be reviewed at BIF
¢ This will include all defect Peaks with the ##LiveAffectingDefect tag
e — [twill also include other Peaks that may relate to other topics such as environments
or Peaks that the Developers wish to discuss at the forum
oO. Ifa 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
o. The PTF chair must record, in Peak on the Release Mgt tab, what decisions are made:
e 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
co 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
e 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 38
Version & Last updated. See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
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
e If a 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 alertito 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
e New CBIF content will be shared with POL on a weekly report from Peak that will
include the proposal and will be sent to POkkin 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 ofthe 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 POLwill probably convert the SefviceNow, 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 ROL
o The agreed target dataset for reporting a defect is as follows as at the time of this report:
Page I 39
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
HORIZON DEFECT REVIEW FORUM - DEFECT SUMMARY
Document Classification: Fut Confidential Commerial-n-Conidence
[POL Problem Reference (PREGOnnnnn
Fujitsu Reference 'PCOnnnnnn
Date first logged at HOR.
Fujitsu Title
POLTitie
Description
Branch Financial Impact or Experience (Fujitsu HOR Fin/HOR Exp)
Branch impact described
Defect Confirmed (or still under investigation)
How found
‘When found
‘When it dates back to {When could it have started happening)
Branches affected (with detailed impact by branch where available)
Frequency of occurrence
Root cause
Isitdetected/monitored
‘Workaround
‘Workaround description
Fix required
Status update
Next action
Target Release number
Target Release date (latest estimate)
o Fujitsu will provide weekly updates prior to the meeting
e Potential HDR Defects — no action required as the updates will already be in POL
ServiceNow
« Confirmed and deferred HDR Defects — by,sharingthe latest update on the defect
Peak we are managing our side in the form of ayreport.
e 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.@fsure theyrare 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
o 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
o 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
o 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:
e They need to make it clear which HDR Defects are within Fujitsu's scope of
obligations
e 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
o 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
co There is no definition of HDR in the contract — this needs to be addressed
Page I 40
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Refer to Appendix D for instructions on how to create the weekly HDR Report for POL.
B — Info only
The Fujitsu KB is an information repository used for support purposes
Any observed Live Defects will be recorded as a KBA but the progress to investigate and
address them will be done via Peak(s) and Incident(s)
o KBAs do not need to be shared with POL as the tracking needs to be on the Peak and
Incident raised to progress them
co 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
co 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 41
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232804
FUJ00232804
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 aq
[-BIF Questions:
‘The fu can be dane m more than one way ané POL would need to gue Fuytsu on choosing the prefered ation
i
I__The ema cnange me cent he ate and conseuerty POL vb equres 9 prowde aeropiaeconmuncaton and plenty taneg 10 e subpostmases
(7 Te cay neato be done im cenucon wh changes promed by some of POL er upper and POL il need to manage and eyctone tha chy,
[
[
[
“The may neato be ne concent wih 3 separate Me sed change de foe ho is Borg oe els, a POL wo edo cf er wang to cet ay pole asi deploying Re
The may rate ace Gece beheen Fy and POL wpect and veparse ae ad hee std be ceed win at contd Fis managment aceon. I
Felts dosnt beleve afi» erie open and seeks POL agreemert io record he ceumsanes in a KE on
Test CIF progress
Test PTF progress
Test wr update
Page I 42
Version & Last updated: See file name
Document owner: Steve Browell
CBIF / HDR Diagram
Ifit is a Live Defect then
add the
LiveAffectingDefect Cl
If itis a HDR Incident
then add relevant Cl
Updates auto replicate
POL rely on ServiceNow
Page I 43
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
FUJ00232804
FUJ00232804
Incident — Peak — Defect — HDR — CBIF
Potential Defect
Investigation Peak
(Investigation) I
POL Incident
[ServiceNow]
Fujitsu
[T
If POL notification
needed
Fujitsu Internal
Internal Live
Investigation Peak
[Call Type “U")
Version & Last updated
Document owner
Confirmed Defect
Fujitsu Internal
I
Fujitsu Reports
HDR/CBIF, or
Continuous Improvement
Live Defec
Internal Liv
Defect Peak
[Call Type changed
to “#”]
Deferred Live Peak
See file name
Steve Browell
All should be Call Type “#”
All should have the Collection
HifLiveAffectingDefect
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
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Appendix AO — Checklists for TfSNow Resolver Group & Peak Stack
owners
A checklist has been produced to help owners of TfSNow Resolver Groups and Peak stacks to keep
the Incidents and Peaks in a manner consistent with the Live Defect Management processes. As at
the date of issue of this document they were as follows.
For Peak:
There’s a Peak in my stack.
(Shou th be ny stack? Hoth route Rt the ight Asgned
(athe Pek anignd tthe orc peron rot ff sk tlon POA?
12 ite potential tv Deft? so, ad the sthvebfecingDaect.
‘ented orto qualify it as NOT a ve Defect?
1 Witisa Ue Detect shold be Cal Type V" oF ~so changeit
Ieneeds tobe cloned and thence tis ok oly bonded to
now)
1 tt orcould be, branch impacting isa the HOR or HOR Ep
12 Witha HOR Caecion—Iet being ested a igh roy
1 Whar a HOR Caecion~Ie the impact ld upto date and wall
12 Has anthing changed thet would mean he AHUveAetingDelect ot
HOR Coens are no lenge correc and shoud be removed? Ho,
(Wii Oat ented, and har been Targeted PT, when wl work
art toceate the rece fn?
the Response Category correc?
Is the Pode nd Product Group comet?
‘When wait ast updated ~ andi ha on acetal inp?
For TfSNow:
‘Should this bein my Assignment Group? if not, then route tothe
Fight Assignment Group
lathe Incident assigned to the correct person (not of ick sion
POA)? not, then reassign it
athe Summary fed clear description that thers will
derstand?
1D the incident not bonded to POL ServiceNow, does it have the
Fight Open category”?
potenti Live Defect? so, othe LivenecingDetet
tis potential Live Defect, what needs doing to progresit to
confirmed defect orto quali as NOT a Live Defect?
12 Should POL be aware? 0, the Incident wil ned tobe logged by
[MAC withthe required specifi Categories so itcan be bonded to
OL SenieNow so POL can be kept updated with progress
or could be, branch impacting =f so, ensure MAC are asked
to edd the HOR-in or HOR Exp C1
Withasa HOR Clit being treated as high priority regardless
of Priority fil value?
1D tithes aHOR-* Cl—isa recent entry inthe “Adtional comments
(Customer visibly’ fed up to date and well worded so that POL
wil understand it?
the State ld correct set?
workaround avaiable (ths will showin the Peak if applicable
the Workaround Reference willbe set o Yes)? M30, make se
thatthe “Additional comments (Customer visible” field clearly
stats this ~ especialy if this Incidents bonded to POL ServiceNow
Has anything changed that would mean the sieAecingDefect
‘or HOR-* Cis are no longer correct and shoud be removed? Hs,
remove them
itis confirmed defect, when wil the resolution ation be taken
28: lit inked to8 TsNow Change?
Page I 44
ve dco akan place ver ema ora esting: hat sou
othe late uptesread wetland mae sense? not. change ham and
Istlear who (pectic is pected toate ext atin? at
Irate ear an ntl the etson expected ae
Peaks with the fllonng Response Categories tht have the
svesfecingDefect Coen shuld be Call Type a fs
{= Pedr roc tre rod
{Fendi Daometaton tr Bagrsed
efor being dosed. Make sure Ride’
eka racrty cloned with any ofthe folowing Retponde Categorie are
deemed to have been No Fut ound with acon needed thie
There’s an Incident in my TfSNow Assignment Group.
When wasit ast updated ands that an acceptable timespan?
Have discussions taken place oer emsilorin meetings that should
be added to the cident to ensure afl cords avaiable?
How longisitsnce the Incident was ated ~ ond that acceptable
cor does a review need doing?
1 Dothe atest updates reed well and moke sense? fot, change
them and coach the creator
the incidents bonded to POL SericeNow, does the latest update
tothe “Additional comments Customer visible" field mae clear
to POL what the status is? nt, add an update that does
Isit clear who (specicaly) is expected to take the next action? if
not, make lear and notify the person expected to act
If you are wating for someone external to your team to take action
challenge them to make progress
Isthe incident Suspended as no further Futsu actions needed? Hf
$0, an ater 10 working dys have eloped, the incident should be
dosed
Ifthe incidents being closed, ensureithas the right Closure code
sedan tcc ie net od rb
instructions)
‘Une of Summary
Incidents recent ose should be checked. f they were dosed
with no action requited by Fujitsu, does the incident cea state
‘hat? if they were sed fllowing actin taken by Fujitsu, does the
Incident clearly state that?
See file name
Steve Browell
Version & Last updated:
Document owner:
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Appendix Al — Peak data anomaly checks
To ensure the data in Peak remains consistent with the intentions of the changes within this
document, periodic checks are 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 MAC team will perform these checks and
approach the relevant people to have any changes made.
The checks relate to Peaks that have the ##LiveAffectingDefect Collection added.
Data Consistency & Accuracy
1. Wrong Call Type — check 1
o WHY -Call Types for Live Defects should be L if under investigation,or # once the
cause is confirmed. Various other Call Types can appear andyneed to be aligned
M
Peaks with Call
Example email - TYPE needing reviev
Collections contains ##LiveAffectingDefect
Planned Out Live is blank or in the future
Peak is not Status C
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 “#”
00000
2. Wrong Call Type — check 2
o WHY -For the response categories “...Error Diagnosed” these are confirmed so
should be Call Type #+ Defect Identified
M
Peaks thatneed the
Example effiail— Cel! TyPe and T'S be
Collections contains ##LiveA ffectingDefect
Planned. Out Live is blank or in the future
Peak is not.Status C
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 1 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
00000
3. Unassigned Peaks
Page I 45
o WHY -All Peaks should be assigned to someone so that that person can be chased
for progress — as well as the Assigned Team lead
M
Peaks with no
Example email- *Ssi9nee-msg
Collections contains ##LiveAffectingDefect
Planned Out Live is blank or in the future
Peak is not Status C
0000
Version & Last updated. See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
°
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
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
°
00000
WHY - when a Release is deployed to live, the Peaks should be set to Status “F”
and returned to the Call Logger for closure. Although there can be a short delay it
should be done promptly
M
Peaks that look to
Example email - 224 Closing.msg
Collections contains ##LiveAffectingDefect
Planned Out Live is in the past
Peak is Status F
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
°
°
°
°
WHY - Peaks with Status “O” are usually those that have just been logged before
someone picks them up and starts to work onthem»At that point the status changes
to “P”. Hence the implication is that Peaks in this state are not being assigned to
people to work on or people are not updating the Peaks properly
M
Peaks that appear
Example email — *° have not been pi
Collections contains ##LiveAffectingDefect
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
°
0000000
WHY - when weiconfirm that we have a Live Defect, the Call Type should be “#”.
However, that Peak should NOT be bonded to TfSNow or POL ServiceNow so that it
canybe progressed independent of the linked systems — which means the original
Incidents can be closed and updates as the Defect Peak progresses do not flow back
to the original systems
M
Defect Peaks still
Example email - bonded to POL Serv
Collections contains ##LiveAffectingDefect
Call Type is Defect Identified
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
°
Page I 46
WHY - we have stated that whilst we are investigating a Live Defect and until it is
confirmed, we will do that by ensuring there is a POL bonded Incident so they get
automatic progress updates. We should not have Peaks open that are HDR tagged
Version & Last updated. See file name
Document owner: Steve Browell
Page I 47
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
000000
°
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
that are not seeing updates shared with POL. Once the Live Defect is confirmed and
the Peak is cloned and set to Call Type “#” this will not apply
M
HDR investigation
Example email - Pe2ks with no obvic
Collections contains ##LiveAffectingDefect
Collections 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)
Version & Last updated See file name
Document owner Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
BSA]
Appendix A2 — 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.
1. POL Feature Consideration Report
o WHY —although we may consider our work done when we close a’Peak as needing
POL to take action, not us, it would be more helpful if we collated;the previous
month/quarter of things we decided were not going to be progressed and presented
them to POL for a properly considered decision. Thistisjin itsearly days and POA
does not have an owner or defined process for this yet
M
Enhancement
Example email - Reduest Advice afte
Collections contains ##LiveAffectingDefect
Peak is Status C
Response Category is “EnhancementRequest” or “Advice after Investigation”
Result set should be extracted for sharing with POL in the form of a 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 48
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
Page 48 Comments
BS4 A process is needed and an owner on POA to follow up
Browell, Steven [2], 06/01/2022 01:48 PM
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
[B55]
Appendix A3 — Peaks closed with no obvious Release
Peaks can be closed with no obvious reference to when the fix went live. This may be because the
fix did not go live under a Release so there are no Planned Out Live dates showing on the system.
Until this process is fixed, these Peaks need checking.
The checks relate to Peaks that have the ##LiveAffectingDefect Collection added and hence relate to
the Live system.
1. Peaks closed without a Release
o WHY -aclosed Peak SHOULD be because there was no fault found and hence no
fix required, or because the fix was deployed. At the moment there is,no process or
tagging to enable Peaks to be associated with TfSNow Changes or 3“ party delivered
changes outside of Fujitsu’s control. A process will be defined, andpuntil itis, this
prompt is intended to ensure that the Peak has not been incorrectly updated
M
Peaks closed -
Example email - utside of a Release
Collections contains ##LiveAffectingDefect
Peak is Status C
Planned Out Live is blank
o Response Category is not on the:No Fault,Found list
Result set should be extracted for,sharing with the Assigned Team stack owners and the
Call Logger (who closed the Peak) to confirm that the fix is in fact deployed
0000
Page I 49
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
Page 49 Comments
BS5 A solution to this needs to be defined by Steve Browell and then implemented
Browell, Steven [2], 06/01/2022 01:48 PM
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Appendix A4 — Release Management checklist
To ensure the data in Peak remains consistent with the intentions of the changes within this
document,
if.
2.
10.
11.
12.
13.
14,
15.
16.
az:
[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 Peakiscreens)
in the past should be Closed. The ‘fix’ has been deployed. If they are StatusiF.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
o 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 deploymentdemanding 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 maintainia log
[Release Management] If a Peak is approved at BIF then it must have the “BIFApproved”
Collection added and the BIF Actionremoved
[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 appropriate\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 name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
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 Avor B or have a HDR-
* Collection must get an urgent BIF/PTF review to be assigned a Release as well.as a Release
Date. A hot-fix must also be proposed for POA/POL management decision:
e [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
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,
e This can exclude Peaks that are Targeted At as they may have been handled prior to
the new processes
e 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 Reaks should be Call Type "#" as the Defect is identified.
This should have been caught at BIF and/or PTF
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
«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
e [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
e [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
e [Release Management] If a Peak has been to BIF it needs to have the BIFApproved or
BlFRejected collection added. If not then it should have the BIF Action flag set as it is to be re-
presented
e [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 name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Appendix B1 — Live Defect Management Monthly Report Creation
Work Instructions
To create the monthly Live Defect Management for POA stack owners and leadership, follow these
steps:
o Create the Peak extract to build the report from
Then, open any version of the “Peak_Defect_Management extract dd.mm.ccyy
hh.mm.xisx” spreadsheet and Enable Content and go to the Data tab and click
the extract was created — so it can be referred back to. Turn off’AutoSave:
o Prepare the report
A spreadsheet format has been used to date so the previous month's
“POA_Live_Defect_Management Monthly Report ddzmm.ceyy hh.mm.xisx” should
be used as the basis for the new report. To show history, copy the white box on the
top left of the Summary tab and paste it to the right as an image (you may need to
delete a previous image)
Save the file with the same date and time values as the Peak extract created earlier
so you know which extract the report‘felates to
o Go to the ##LiveAffectingDefect tab and filter as follows,
Then the 5 tabs are derived as follows:
Check the range of values in the Call Type column. If there are any that are neither “Live
Incident” nor “Defect Identified” then theseneed to be looked at to decide whether to treat them
as one of these 2 categories. There shouldn't be any, but if there are, it is most likely to be
Vulnerability which can be treated as Defect Identified. If so, amend the filtering below where ** is
shown.
co Still Investigating
Clear all filters.
Filter the Planned Out Live date so it is in the future or blank (it has not been
deployed)
Filter out the No Fault Found Response Category values (see Appendix F)
Filter Call Type to “Live Incident” ONLY **
= Consider filter on Status to exclude “C"losed — but beware the closures may be wrong
Extract the columns shown on the tab from the filtered list and paste the values into
the report
Expand/contract the Stack owner column by copying/pasting the formula so all rows
are attributed to a name
o DlI-Solutioning
Page I 52
Clear all filters
Filter the Planned Out Live date so it is in the future or blank (it has not been
deployed)
Filter out the No Fault Found Response Category values (see Appendix F)
Filter Call Type to “Defect Identified” ONLY **
Filter “Target Release Type” to exclude “Targeted At” and “Proposed For”
= Consider filter on Status to exclude “Closed — but beware the closures may be wrong
Version & Last updated. See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
°
°
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
"Manually add back in any that are “Targeted At’ or “Proposed For” and Target
Release is “Re-target’ if there are any
Extract the columns shown on the tab from the filtered list and paste the values into
the report
Expand/contract the Stack owner column by copying/pasting the formula so all rows
are attributed to a name
DI - Proposed For
Clear all filters
Filter the Planned Out Live date so it is in the future or blank (it has not been
deployed)
Filter out the No Fault Found Response Category values (see Appendix F)
Filter Call Type to “Defect Identified” ONLY **
Filter “Target Release Type” to “Proposed For” only
Filter “Target Release” to exclude “Re-target”
* Consider filter on Status to exclude “C’losed — but beware the closures may be wrong
Extract the columns shown on the tab from the filtered list and paste the values into
the report
Expand/contract the Stack owner column by copying/pasting the formula so all rows
are attributed to a name
DI - Targeted At - no live date
Clear all filters
Filter the Planned Out Live date so it is in the future or blank (it has not been
deployed)
Filter out the No Fault Found Response Category values (see Appendix F)
Filter Call Type to “Defect Identified” ONLY **
Filter “Target Release Type”to “Targeted At” only
Filter “Target Release” to exclude “Re-target”
* Consider filter on, Status to exclude “C’losed — but beware the closures may be wrong
Amend the filter on Planned Out Live to be blanks only
Extract the Columns shown on the tab from the filtered list and paste the values into
the report
Expand/contract the Stack owner column by copying/pasting the formula so all rows
are attributed toa name
DI — Targeted At — all ok
‘Startwith the result set in “DI — Targeted At - no live date”
Switch the filter on Planned Out Live to exclude blanks (and only include those with
dates showing)
Extract the columns shown on the tab from the filtered list and paste the values into
the report
Expand/contract the Stack owner column by copying/pasting the formula so all rows
are attributed to a name
o And finally:
Page I 53
Count the number of rows for each tab and add the figures to cells D5 to D9 on the
Summary tab
It will hopefully look different
Issue the update to all Stack owners and POA leadership
Version & Last updated. See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
Page I 54
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
M
Live Defects Status
Example email - 29-10-2021) - review
You will need to copy the last month and this month graphs and paste them as an
image into the email
Update the bullet points in the Summary section of the email to help the recipients
digest the content
Note: the actions each stack owner should take with each tab is described above the
graph alongside the count of the number of Peaks in the report
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Appendix B2 — Live Defect Management Weekly Progress Chaser
Email Creation Work Instructions
To create the weekly Live Defect Management progress chasers, follow these steps:
o Create the Peak extract to build the report from
e Then, open any version of the “Peak_Defect_Management extract dd.mm.ccyy
hh.mm.xisx” spreadsheet and Enable Content and go to the Data tab and click
Refresh All on The password to run the embedded queries, needs entering
3 times and is . Save the resulting file with the timestamp tomatch when
the extract was Créatéd— so it can be referred back to. Turn off/AutoSave:
o Prepare the report
e Aspreadsheet format has been used to date so the previous week's
“POA_Live_Defect_Management Weekly Progress'Chaser dd.mm.ccyy hh.mm.xlsx”
should be used as the basis for the new report
«Save the file with the same date and time values as the Peak extract created earlier
so you know which extract the report relates to
o Go to the ##LiveAffectingDefect tab and filter as follows
Then the 2 tabs are derived as follows:
Check the range of values in the Call Type column. If there are any that are neither “Live
Incident” nor “Defect Identified” then these need tobe looked at to decide whether to treat them
as one of these 2 categories. There shouldn't be any, but if there are, it is most likely to be
Vulnerability which can be treated as Defect Identified. If so, amend the filtering below where ** is
shown.
co Still Investigating
e Clear all filters.
e Filter the Planned Out Live date so it is in the future or blank (it has not been
deployed)
e Filter out the No Fault Found Response Category values (see Appendix F)
e Filter Call Type to “Live Incident” ONLY **
= Consider filter on Status to exclude “C"losed — but beware the closures may be wrong
e Extract the columns shown on the tab from the filtered list and paste the values into
the report
« ~ Expand/contract the Stack owner column by copying/pasting the formula so all rows
are attributed to a name
o Dl-not Targeted
e Clear all filters
e Filter the Planned Out Live date so it is in the future or blank (it has not been
deployed)
e Filter out the No Fault Found Response Category values (see Appendix F)
e Filter Call Type to “Defect Identified” ONLY **
e Filter “Target Release Type” to exclude “Targeted At” and “Proposed For”
"Consider filter on Status to exclude “C’losed — but beware the closures may be wrong
= Manually add back in any that are “Targeted At’ or “Proposed For” and Target
Release is “Re-target’ if there are any
Page I 55
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e Extract the columns shown on the tab from the filtered list and paste the values into
the report
e Expand/contract the Stack owner column by copying/pasting the formula so all rows
are attributed to a name
o And finally:
e Issue the update to all Stack owners whose names appear on either of the tabs
M
POA Live Defect
© Example email — Weekly Progress Ch
Page I 56
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
B56)
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 penannum
No mechanism to reproduce the Live Defect has been identified and information as to cause
is therefore not available to make any progress
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 délivery — and Fujitsu has
compensating controls in place and Fujitsu managementhas agreed to taking no action
The impact of the Live Defect is accepted by POL — anda 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 internal 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 have a KBA written to help future support activities.
Page I 57
Version & Last updated. See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
Page 57 Comments
BS6 This needs to be finalised and agreed on POA
Browell, Steven [2], 06/01/2022 01:49 PM
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Appendix D — Weekly HDR Report Creation Work Instructions
To create the weekly HDR Report which is shared with POL, follow these steps:
o 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.
co Prepare the report to send to POL
« Aspreadsheet format has been used to date so the previous week's POL “HDR
Defects update report — dd.mm.ccyy v1.0.xlsx” 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.
= Save the file as v0.1 initially and use v1.0 for the version.that is shared with
POL. As a visual reminder add WIP into cell B2
= Amend the date in F3 making sure to leave it’as,a text field or the title of the
section below it will not render correctly
o Create the Peak extract to build the report from
e Then, open any version of the “Peak_Defect_Management extract dd.mm.ccyy
hh.mm.xlsx” spreadsheet and Enable Content and go to the Data tab and click
Refresh All on h tab. The password)to. run the embedded queries needs entering
3 times and is - Save the resulting file with the timestamp to match when
the extract was created — so itcan be referred back to. Turn off AutoSave
o Go to the #LiveAffectingDefect tab\and filter as follows:
e Collections [column L] contains ##LiveAffectingDefect — auto done by using the
##LiveAffectingDefect tab
e Seta filter on Collections [column L] so it contains HDR
e Seta filter on Planned Out Live [column AH] so the dates are in the future or blank
(it has not been deployed)
e Set the filter omResponse Category [column J] to exclude the No Fault Found values
(see Appendix F)
Then the 3 Lists need to be,created:
o List 1— Deferred Live Defect Peaks
e Set thesfilter on Collections [column L] so it also contains “Deferral”
*) .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:
= Then copy the data fields from the result set and paste to replace the
Deferred Defects list on the POL HDR Report
e POL Reference (set to N/A)
¢ POL Title (set to N/A)
e Fujitsu Reference (the Peak Call Reference)
« Category (HDR-Fin = Impact, HDR-Exp = Experience)
« Summary (Peak Summary field)
Poe Fup
efrence POL THe Reference Category _Fuftu Te
o List 2 — Project Live Defects
e Collections [column L] does not contain “Deferral”
Page I 58
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e These are unlikely to be discussed at HDR as they are part of the ongoing Project
Manager regular review calls
« Summary [column B] contains “PBS” or contains “PITPOS” or “Ingenico”
= There may be none
= The entries showing “Ingenico” may alsop show as “PBS” or “PITPOS” so
filtering on just those 2 values may be sufficient
e Exclude closed Peaks where Status [column I] is “C” — as these may have been fixed
outside of a release by Ingenico themselves
«Then copy the data fields from the result set and paste values to replace the Project
Defects list on the POL HDR Report
= POL Reference (set to N/A)
= POL Title (set to N/A)
= Fujitsu Reference (the Peak Call Reference)
= Category (HDR-Fin = Impact, HDR-Exp = Experience),
= Summary (Peak Summary)
POL rope
ference POL Tle Rarer cateuory Fotos Te
o List 3- non-Project Live Defects (likely originating from an Incident during normal service
delivery)
e These will be those that remain that aré NOT on Lists 1 and 2
e These require more comprehensive information as these will be discussed at the
HDR meeting
e 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
e Todo this start with the POL HDR Report list and sort on the Fujitsu Ref column
= Check if they are stilton the data subset showing on the
Peak_Defect_ Management filtered list in view
= Note any that seems to have gone so you can check why
= Add any that seem, to be new so you can check later
e The Fujitsu reference will vary:
= 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
« Copy the data fields from the result set and paste to replace the HDR Defects list on
the POL HDR Report
= POL Reference (set to TBC if new and not yet shared by POL)
= POL Title (set to TBC if new and not yet shared by POL)
= Fujitsu Reference (the Peak Call Reference)
= Category (HDR-Fin = Impact, HDR-Exp = Experience)
= Fujitsu Title the Peak Summary)
= Confirmed Defect (Call Type is Defect Identified = Yes, otherwise No)
= Workaround (Yes or No)
= Update — 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 (will be
shown on the sub-tabs)
Page I 59
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Release Expected — either the confirmed Target Release or the anticipated
release (can say “Counter Release”). It should also be set to yellow highlight
if it has changed
Page I 60
« 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 moved to the HDR Closed Defects
section of the HDR Report
Any that are new should be added to the list and highlighted in red on the
HDR Report tab whilst they are checked and completed
e These then need scrutiny to ensure they look’correctly tagged as
HDR. This will require the Peak to be read and checked
e If they are HDR, then the Template tab needs to’be copied and
named to match the new Peak reference. Its tab colour should be
Red for Impact and Orange for Experience. It should be positioned in
numeric order with the other tabs
Document Casificaon: Fujtsu Confidential. Commercial in Conidonce
[POL Problem Reference [PRBOONnnnN
Fujitsu Reference, [PCOmnnnan
Date first logged at HOR.
FujitsuTitle
POLTitie
Description
Branch Financial Impact or Experience (Fujitsu HOR Fin/MOR xp),
Branch impact described
Defect Confirmed (or still under investigation)
How found
‘When found
‘When it dates back to {when could it have started happening)
Branches affected (with detailed impact by branch where available)
Frequency of occurrence
Root cause
Isitdetected/monitored
‘Workaround
‘Workaround description
Fix required
Status update
Next action
Target Release number
Target Release date (latest estimate)
« The main HDR Report page cell showing the new Fujitsu Ref (Peak
number) should be hyperlinked to the new tab for ease of navigation
e The required fields on the new tab should be populated as best as
can be derived from the Impact and Details screens in Peak. This
should then be sent to the relevant SMEs and 4LS to ensure it reads
well and is suitable to share with POL
« When the report is ready to submit, the highlighting should be
changed to yellow
Any existing entries that remain on the list should be checked for updates to
the fields on their specific tab and, if progressing from Live Incident to Defect
Confirmed, to amend the reference from a TfSNow Incident to the Defect
Peak reference
e Any amendments to the tabs should be highlighted in yellow and the
reason for Update should be added to the HDR Report entry too
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Appendix E — Weekly CBIF Submission Extract Work Instructions
To identify if there are any CBIF submissions necessary to POL, follow these steps:
o Peaks to take to CBIF
Page I 61
Collections [column L] contains ##LiveAffectingDefect — auto done by using the
##LiveAffectingDefect tab
Call Type [column F] is "# - Defect Identified" (a fix is needed)
Planned Out Live [column AH] date is in the future or blank (it has not been
deployed)
Target Release Type [column S] is not Targeted At (as this means it}has gone
through PTF already)
Collections [column L] does not contain HDR
BIF Planned Date [column U] must not be blank (it has.to have\been to’a BIF
meeting)
PTF Planed Date [column AA] must be blank (it has Notbeento PTF)
The Actioned Team [column Av] must not be BIF (not\eady for CBIF) or PTF (gone
past the CBIF step)
Set the filter on Response Category [column J] to €xclude the No Fault Found values
(see Appendix F)
BIF_Ticked_Questions [column AM] is not/blank (BIF selected it for CBIF)
Check that each Peak in the result;setis correctly marked by reviewing the Peak Details
and looking at the Release Mgt.tab for notes that clarify. Any Peaks that are confirmed
as CBIF candidates then need a CBIF Proposal creating as this is what will be submitted
to POL.
CBIF is part of the HDR meeting, and any proposals should be submitted along with the
weekly HDR report for discussion at the weekly HDR meeting with POL.
Version & Last updated. See file name
Document owner: Steve Browell
FUJ00232804
FUJ00232804
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Appendix F — No Fault Found Response Category values
Peaks with the following Response Categories are deemed to be No Fault Found as no action was
required to remedy the issue raised. In some cases this is because the fault is within an area of the
system that is managed using TfSNow and hence Peak is not the source of the Live Defect
information.
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 TfS
Response Category — 120 -- Final -- Cloned to create Defect Peak
Response Category — 200 — Final -- Call withdrawn by user
Page I 62
Version & Last updated: See file name
Document owner Steve Browell