FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Changes in v1.1
1. Added What’s New
2. Added numerous diagrams to aid understanding
3. Removed requirement for Development (ManDays) to be entered on any Peak and also
removed Development (ManDays) as a criteria for submission to CBIF
Refined criteria to be reviewed at BIF to guide what is taken to CBIF
5. Added additional references for Response Category and Root Cause field values
6. Added additional clarification that deferred Peaks that still require investigation’ are assigned
Call Type “L” not “#”
7. Added guidelines for use of the “Additional comments (Customer visible)’ field in TfSNow
8. Updated Actions
Page I 1
1 & Last updated: See file n
ent owner Steve Bre
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Contents
What’s New
New terms..
Investigation Peaks becoming Defect Peaks...
TfSNow Incident needed for things POL should know.
New fields in Peak...
New field values in Peak.
Renewed importance for Peak fields.
New field values in TfSNow..
Renewed importance TfSNow fields...
BIF..
CBIF...
PTF.
© 0&0 MoM DON DAHAAA YU
HDR
Diag!
Introduction & Overview. .10
The Goal..... .10
Purpose & Scope
The Streams.
Terminology — Overview...
Stream 1— Incident & Problem (links to Peak, Key Meetings & Live Defect Management)...
Managing Incidéfts....
Managing Problems......
Actions.......
System Change:
One-Time Actions...
Release...
Actions.
System Changes.
Page I 2
1 & Last updated: See file n:
vent owner Steve Bre
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
One-Time Actions...
New Ways of Working
Stream 3 — Live Defect Management...
Live Defect Management - Live Defect Definition........
Live Defect Management — Goal:
Live Defect Management — Key Fields in Peak..
Live Defect Management — Reporting.
Actions...
System Changes.
One-Time Actions..........00+
New Ways of Working
Stream 4 — BIF, CBIF, PTF and HDR.......
BIF..
CBIF...
PTF...
HDR.
KB — Info only.
Release Mgt tab — for BIF, CBIF and PTF...
CBIF / HDR Diagram...
Actions.......
System Changes.
One-Time Actions.
New Ways of Working.
Stream 5 —Security Improvements.
SecOps BAU.
Additional Items...
Actions.......
System Change:
One-Time Actions...
New Ways of Working
Stream 6 — Elevated Access & Tooling.
Actions.
One-Time Actions...........6+
Page I 3
Version & Last updated See file n
Document owner Steve Bre
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Stream 7 — Various..
ACtions.......00+
One-Time ACtionS......eececseeeeeseeeeeneeeeeneeneeeeeeieeeeneneeneeieeneseeeeneeeensneeneeneneeeeeeieeneeeeeeeeneneenenes 50
Page I 4
Version &
See file name
Document I
St vell
FU,
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
What's New?
This document describes a number of changes to the Post Office Account ways of working and use
of systems. This section provides highlights but the entire document should be read to gather
awareness of all changes being implemented.
Our interactions needs 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.
New terms
Throughout this document, there are new terms and phrases that will need to be understood so we
increasingly use a common language. The main ones are:
« Live Defect — is a logged Incident that is present on the Live system that is, or appears to be,
inconsistent with the agreed design or service specification
e HDR Defect - Live Defects that affect, or have the potential to affect, branch operations
(financial, experience, or end customer)
e Horizon Defect Review (HDR) — a weekly 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 thatis being investigated where the cause and required
action are not yet confirmed. A linked TfSNow Incident may well exist - and MUST exist if
POL need to be aware. The,Peak Call Type should be “L” if this is a Live Defect
« Defect Peak — is a Peak that is not linked to a TfSNow Incident and that describes the
confirmed Live Defect that will be progressed through the SDLC (BIF, PTF, Dev, Test,
Release) to live-deployment
¢ Investigation Incident (TfSNow) - is an Incident that is being investigated where the cause
and required action are not yet confirmed. The Incident MUST be bonded if POL need to be
aware
¢ Defect Incident (TfSNow) — is a TfSNow Incident that describes the confirmed Live Defect
that will,be’progressed by a Resolver Group that does not use Peak (e.g. Networks, Security,
Unix)
¢ 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 “#"
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”
« 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”
Page I5
Version & Last updated See file n
Document owner Steve Bre
FUJ00232720
1J00232720
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
¢ OTI-is the interface between Peak and TfSNow that allows tickets to be transferred
between the systems and updates to tickets to replicate
Investigation Peaks becoming Defect Peaks
e Peaks can exist to investigate Incidents. These are known as Investigation Peaks
« Some Peaks are linked to TfSNow Incidents allowing for updates to flow over the OT!
between TfSNow and Peak (and via bonding to POL ServiceNow)
e When the investigation work has concluded on an Investigation Peak and a Live Defect has
been confirmed then one of the following actions need to be taken — most likely by
Development
o If the Investigation Peak has been raised internally and is not linked to a TfSNow
Incident then its Call Type just needs changing to “#" - Defect Identified
o If the Investigation Peak is linked to a TfSNow Incident then the.Investigation Peak
must be cloned to create a new Defect Peak. The Defect Peak must be given the
Call Type “#” - Defect Identified. The Investigation Peakymust,have the Defect Peak
reference added to the last progress update. The Investigation Peak must then be
closed with an appropriate Response Category an@)Root.Cause being added. This
Defect Peak reference will then flow back to the’ TfSNow Incident (via the
Investigation Peak progress update) and also to the, POL ServiceNow Incident (if
applicable). The TfSNow Incident will then also be closed. Future tracking of
progress will then be done using Peak by monitoring the Defect Peak created until it
is fixed and released to live
TfSNow Incident needed for things POL.shotild kaéw
e Fujitsu must not raise and manage dncidents that POL should be aware of without having a
bonded TfSNow Incident raised
« Creating a Peak to investigate an Incident is not sufficient if the Incident is something POL
need to be aware of. In that scenario Fujitsu MAC need to be contacted to create a new and
bonded Incident in TfSNow. This will cause a new Peak to be raised into which the
investigation Peak contents must be moved and the investigation Peak closed. This ensures
a link exists from the new, Peak back to the POL ServiceNow Incident
New fields in Peak
Some new fields have been added to Peak that must be used from this time:
o POL Problem reference — using the prefix “POLPRB-“ so it is obvious and also searchable.
Most likely:only required when the Peak is declared to be a HDR Defect
o Fujitsu Problem reference — using the prefix “FJPRB-" so it is obvious and also searchable.
Mostlikely to be updated by the Fujitsu Problem Manager to ensure the link is clear
o Workaround - to state “Yes/No” state if an accepted workaround has been implemented. If
the field is blank or contains “No” then no workaround has been identified (see screenshot
later in the document)
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 (see screenshot later in
the document)
New field values in Peak
Some new values have been added to existing fields that must be used to improve Peak reporting
and tracking:
Page I6
Version & Last updated See file n
Document owner Steve Bre
°
°
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Call Type — must be set to “#” Defect Identified when a Live Defect is confirmed. Prior to this
Live Defects ought to be Call Type “L” Live Incident but can have other Call Types provided
they carry the ##LiveAffectingDefect Collection
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
Collections of “HDR-Fin” or “HDR-Exp” for HDR Defects
Renewed importance for Peak fields
A number of existing fields have become important and must be completed for all Peaks:
°
Call Type — must be set to “#” Defect Identified when a Live Defect is confirmed. Prior to this
Live Defects ought to be Call Type “L” Live Incident but can have other Call Types provided
they carry the ##LiveAffectingDefect Collection
Summary — must be written so as to be understandable by mostreaders: 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)
Impact — tab and free form field to articulate impact, status and,next steps so it is easy to
understand for anyone. This will be maintained for/HDR Peaks weekly. For other Peaks it can
be as needed
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>>
Priority — which must be validated at,all times so it is accurately shown as this will affect
reporting and decision making,
Assigned Team — must show which team is currently responsible for taking the next action
or ensuring action is taken
Product Group and Product- We need to know the part of the system that the Live Defect
relates to for reporting and quality purposes
Root Cause — we neéd to know what type of fix was needed, which when matched to the
part of the system, affected, gives us further quality data. Some Root Cause options will also
lead to Live Defects»being qualified out and not reported on. We will exclude the following
Root Cause values from Live Defects so these need to be applied with caution:
« “39 General — User Knowledge” — caused by lack of knowledge with the user
« "40" General — User” — caused by an action performed by the user which was
Outside expected use
*®,/ “41 General — in Procedure” — caused by not following defined procedure
Response Category — specific values have been identified to enable clarity and to spot
exclusions. Although there are many values for this field, the following have important
meanings — mostly is qualifying Live Defects as not defects and hence allowing their
exclusion from reporting:
e “63 -- Final -- Programme approved - No fix required” — for Peaks rejected at CBIF
« “66 -- Final -- Enhancement Request” — for Peaks tagged with the
##LiveAffectingDefect Collection that were subsequently qualified as not being Live
Defects but enhancement requests
e “68 -- Final -- Administrative Response” — for Peaks tagged with the
##LiveAffectingDefect Collection that were subsequently qualified as not being Live
Defects
Page I7
Version & Last updated: See file n
Document owner Steve Bro
FU,
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e “95 -- Final — Advice after Investigation” — for Peaks tagged with the
##LiveAffectingDefect Collection that were subsequently qualified as not being Live
Defects
e “100 -- Final -- Route call to TfS” - for Peaks tagged with the ##LiveAffectingDefect
Collection that were subsequently qualified as not being Live Defects within Peak
New field values in TfSNow
e Configuration Item of - HDR-Fin, HDR-Exp and LiveAffectingDefect for Incidents and
Problems
o LiveAffectingDefect must be set when the TfSNow Incident meets the criteria for a
Live Defect at the earliest possible opportunity
o “HDR-Fin” or “HDR-Exp” for HDR Defects
Renewed importance TfSNow fields
e State - will allow reporting on Potential Defects and Confirmed Defects
o Acknowledged — Fujitsu is aware of the Incident but is not yet working on it
o Work In Progress/Researching — Fujitsu is investigating the issue described in the
Incident
o Fix In Progress — Fujitsu has confirmed that the Incident requires an action to fix it —
most likely linked to a Change ticket
o Suspend — action is complete by Fujitsu or is,required from another entity
e Additional comments (Customer visible) — this. 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:
o Business impact: <<description of the business impact, succinct>>
o Status update: <<description of current status - succinct>>
o Next action: <<next action to be taken and expected date for next update>>
BIF
e BIF now needs to check certain fields have been updated as part of the review process. In
particular, it needs toyset specific CBIF flags if POL involvement is needed.
«The forecast man days effort will no longer be a deciding factor for submission to CBIF
« — The date of the BIF_meeting and the notes made at the meeting will be held in Peak
removing theyneed to create or review separate minutes
¢ Peaks to be taken to CBIF will be identifiable from criteria based on data fields on a Peak
« Submissions to CBIF will use a new proposal form to ensure the meeting focusses on the
decision and not the articulation of the topic. The proposal will be stored as a file attachment
in the Peak
e POL are expected to make a decision based on the proposal (as they would for a CWO)
e The date of the CBIF meeting and the notes made at the meeting will be held in Peak
removing the need to create or review separate minutes
e The date of the PTF meeting and the notes made at the meeting will be held in Peak
removing the need to create or review separate minutes
Page I 8
Version & Last updated See file n
Document owner Steve Bre
FUJ00232720
1J00232720
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
HDR
¢ This is a critical meeting which sees POL and Fujitsu having mutual awareness of the main
Live Defects that could affect branch operations and the progress being made on them
e The Horizon Defects Review (HDR) meeting is the new name for what was the Known Error
Review Forum (KERF)
e It is a joint Fujitsu and POL weekly forum to manage HDR Defects that meet the stated
definition
e¢ POL will maintain a list of all HDR Defects and their progress
e Fujitsu will provide updates on the HDR Defects it is tracking using a weekly report that will
extract information from Peak for the applicable Defect Peaks. Hence the importance of the
Peak field values
« Fujitsu will also provide updates on Peaks that were deferred from releases where they meet
the HDR Defect criteria as these are, by definition, Live Defects
Didgrams TBE
Page I 9
Version & Last updated See file n
Document owner Steve Bre
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Introduction & Overview
The Goal...
To implement the defined list of improvements in this document in substantive part by...
31° July 2021
...and to have completed all improvement including any early challenges and snags by
31% August 2021
Purpose & Scope
o Byrunning a series of Streams of work we will systematically drive improvements across
POA
The Streams will likely overlap and may well change format as\progress is made
Although active participation in a Stream may be low for,some, it is critical that there is a
common understanding or we will not achieve cross functional change
Stream members may change over time
Each Stream will have a set of actions to complete = initially derived from this document
The team can add additional actions as needed
POA needs to urgently evolve to a cross functionally agreed set of ways of working so that it
can be explained to any interested party,withease
o Our interactions needs to be system and process driven not people and experience — and
that will create a clear audit trail too
o We need to limit the dependency on meeting-specific reports or embedded tables in minutes
to show progress on important matters
o Transparency is key — to thefullestsensible 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
o That means we need tobe clearer and consistent about what we mean by Incidents,
Problems, service'management toolsets, Peak, KB, Live Defects, Live Defect Management,
BIF, CBIF“HDR, Release Notes, RAM/RAB deferred Live Defects and probably more
o We need to agree the functions of the various platforms and meetings to ensure it all joins up
(thisdocument is a start)
o If POL is tracking it - or applying governance to it — then so should we — and our process
should be in advance of theirs so we have no surprises
o We do not have all the tools and integrations we would like, so the goal is to make the best
possible use of what we have already
o We need to protect our internal systems from a need for routine disclosure — so we can work
our way
o We need to ensure any POL desires on our ways of working relate to contracted obligations
and suit how our systems and people work — unless we are commissioned to change any of
those — as this is more likely to be consistent and reliable
o For this to succeed we need considerable cross functional support coupled with manager and
team member engagement
°
°
The Streams
e Stream 1 - Incident & Problem (links to Peak, Key Meetings & Live Defect Management)
Page I 10
Version & Last updated See file n
Document owner Steve Bre
FU,
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
co Focusses on clarifying how Incidents & Problems should be managed and reported
on including their relationship to Live Defects and the integrations with POL’s
ServiceNow and Fujitsu's Peak systems
e Stream 2 - Use of Peak (3LS, 4LS & Release)
o Focusses on the Peak Incident management features and their links to Live Defect
Management and Release Management
e Stream 3 - Live Defect Management
o Defines an improved way to capture Live Defect information and report on it both
internally and to POL
« Stream 4 -BIF, CBIF, PTF and HDR
co Refines the ways these key meetings are managed and integrates them with the
revised ways of working on Incidents, Problems, Peak, Release-and,Live Defects
Each Stream documents the key elements that reinforce an existing way of working or state a new
way of working. This content will be embedded into existing account documents for it to be
formalised. Each Stream will then contain references to any System Ghanges made (optional), the
One-Time Actions needed to move to the defined ways of working, and.then the New Ways of
Working that will describe what is different from how things are done today.
Actions that have been completed are scored out. The One-Time Actions that are underway at the
moment are highlighted in green although some of the other actions may also be partly active too.
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 areiintended 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 require the awareness or involvement of POL must be created and
managed in TfSNow,and,be bonded so that they replicate to POL ServiceNow. Although
actions and progress may happen in other tools, systems and processes, the primary source
of all relevant content MUST be TfSNow.
lems
o All Problems must be raised in TfSNow and be reviewed on an agreed schedule with POL.
As Problems'cannot be bonded, additional work will be needed to manually share updates
and hold mutual reference numbers.
o Peaks can be used for many purposes. Where Peaks relate to Incidents initiated from
TfSNow, the relevant Peak updates MUST be synchronised with TfSNow. Peaks raised
outside of an Incident MUST also be raised as TfSNow Incidents if they require the
awareness or involvement of POL. Peak is the only system used to record and manage Live
Defects.
o Peaks do not need 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.
Page I 11
Version & Last updated: See file n
Document owner Steve Bre
FUJ00232720
1J00232720
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
o Release Notes must state all Peaks that are being closed when the Release goes live. 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.
Live Def
co ALive Defect is defined as an issue that:
e Relates to the LIVE system only (this excludes Test, RDT, and internal tasks)
e Is, or appears to be, inconsistent with the agreed design or service specification
« 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)
e There may be a workaround, but the underlying issue still meets the criteria above
« The HDR Defect may be under investigation and.is not confirmed to meet the criteria
above but has attributes that meet the criteria above (a potential HDR Defect)
o When the HDR Defect is being investigated,there will be a TfSNow Incident open and
bonded. POL may track status using theinServiceNow 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'will be 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 meeting.
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 Deféet Management
o All Live Defects must be rigorously managed until fixed. 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 meeting; and the rest by a helpful 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.
CBIF
co All Live Defects that are Priority A or B or require >2 days work, or relate to an Incident
raised by POL will go to the Customer Business Impact Forum (CBIF) for a decision. CBIF
may be a component part of the POL HDR weekly meeting.
Page I 12
Version & Last updated See file n
Document owner Steve Bre
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
HDR
o The Horizon Defects Review (HDR) meeting is the new name for what was the Known Error
Review Forum (KERF). It is a joint weekly forum to manage HDR Defects that meet the
stated definition. POL will maintain a list of all HDR Defects and their progress. Fujitsu will
provide updates to the HDR Defects being tracked. There must be a POL Problem reference
and a corresponding Fujitsu Incident, Peak or Problem reference. The updates to the Fujitsu
tickets will be shared at the HDR meeting. 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.
KB
o The Fujitsu KB is an information repository used for support purposes. Any observed defects
will be recorded as a KBA but the progress to investigate and address:them will be done via
Peak(s) and/or Incident(s). KBAs do not need to be shared with POL as the tracking needs to
be on the Peak and/or Incident. If the awareness or involvement of POL is applicable then
there will be a TfSNow bonded Incident and this will contain all relevant-parts of any KBA so
that the Incident that POL see is a suitable complete reference»
Page I 13
Version & Last updated See file n
Document owner Steve Bre
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Stream 1—Incident & Problem (links to Peak, Key Meetings & Live
Defect Management)
°
Team — Steve Bansal, Sandie Bothick & Matt Hatch
Managing Incidents
°
An Incident is defined in the HNG-X contract as “any perceived abnormal or undesirable
occurrence relating to the Services”
Incidents for the Live environment that POL need to be notified of and be aware of must be
logged in the Fujitsu service management toolsets, TfSNow, and bonded so it is visible in the
POL service management toolset, ServiceNow
Fujitsu must ensure TfSNow Incidents are raised and bonded where POL notification is
required (e.g. when relevant KBAs are created, or faults are identified whilst doing other work
such as testing or problem determination)
Service Operations should only use TfSNow for communicating Incidents between Fujitsu
and POL
Incidents cannot be raised by email by POL or Fujitsus!ncidents must be raised in TfSNow
by Fujitsu or in ServiceNow by POL
The Summary field should be understandable by most readers as this feeds Peak and also
shows on reports.
¢ For system monitoring this is set by SMG;,bonded Incidents it comes from POL,
otherwise it’s Fujitsu staff (MAC & Security) that choose its content
The Incident should be a complete and’comprehensive self-contained reference to the status
of an Incident
Incident progress MUST be shown on the.Incident ticket and cannot be managed via
separate emails. Emails must be added to the Incident ticket if relevant to demonstrating
progress or status
The Incident should appear to, be integral — the fact that 3° and 4" line use a different toolset
should not be apparent
There should be no references visible to POL (going forward) to toolsets used by Fujitsu that
are not accessible toPOL such as Peak or KBA for status information (as these are Fujitsu
internal) — a Peak reference is acceptable for a reference to a defect Peak that is being
progressed. References for Fujitsu use only must be maintained
Incidents must be updated to contain relevant updates from systems such as Peak (but not
private updates) and relevant parts of KBAs (not the internal instructions)
Incidents raised as Fujitsu internal that do not need to be notified to POL may contain
internal system references
Incident updates should contain meaningful and appropriately detailed technical content
Incident updates, and in particular updates summarising the current status, should be written
in plain English to be understandable to most readers
A clear statement of the latest status and the next action should be obvious within the
Incident. This needs to be the last, or very recent, update
« The “Additional comments (Customer visible)” field must provide a latest status view
— at least periodically and for POL bonded Incidents mainly — so it can be easily
understood by any reader. Peak uses a dedicated field for this and uses the following
format:
= Business impact: <<description of the business impact, succinct>>
= Status update: <<description of current status — succinct>>
Page I 14
1 & Last updated: See file ni
rent owner Steve Bre
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
= 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
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
« Open category — TfSNow has Configuration Items that should be used
* Closure code — TfSNow has these and they should be used
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
« Incidents we have marked as requiring a fix shouldbe closed in TfSNow with the
defect Peak reference added as that is what wilhbe 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 thé last assigned Resolver Group has completed
their action — but it may require’ other actions by other Resolver Groups. Therefore, Resolved
is not replicated to ServiceNow or POL will wrongly assume it is Resolved and will likely close
their Incident. When all p6ssible actions are complete and MAC believe it is truly Resolved
then they will request /POL to close it.
e¢ 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 itis 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 aware of Incidents
where POL have an interest so that it can review content and status frequently. Adding any
relevant POL references, such as the POL Problem reference, should be considered
o ALive Defect is defined as an issue that:
e Relates to the LIVE system only (this excludes Test, RDT, and internal tasks)
« Is, or appears to be, inconsistent with the agreed design or service specification
¢ Incidents that meet the definition of a Live Defect must have the
“LiveAffectingDefect” Cl added in TfSNow
e The State field values must be used
« Acknowledged — Fujitsu is aware of the Incident but is not yet working on it
= Work In Progress/Researching — Fujitsu is investigating the issue described
in the Incident
= Fix In Progress — Fujitsu has confirmed that the Incident requires an action to
fix it - most likely linked to a Change ticket
Page I 15
Version & Last updated See file n
Document owner Steve Bre
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
= Suspend — action is complete by Fujitsu or is required from another entity
e An Incident 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):
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 PosfOffice customer or
client (add the “HDR-Exp” Cl)
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 eafly warning that a
new HDR Incident has been raised
© 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 is also closed or has its Call Type changed to “#”. The original
Peak must be kept open until the cloned,Peak is:¢losed 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 haveva ServiceNow reference with the reason being that a cloned
Peak is now to be tracked will be sent back to Peak by MAC to reopen the Peak as this must
be maintained to ensure the continued automatic flow of updates to the originator
o Recurring Incidents ‘and Incidents with follow up actions require a Problem record to be
created. The Incidents are linked to the Problem
o To ensure we avoid updates being overtly associated with an individual, meetings, updates,
and reports*relating to Incidents must be system driven from the relevant tickets — 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
«” Live Defect Incidents — potential and confirmed
e HDR Defects — potential and confirmed
« For each, show views based on:
= Open category & Close codes
* Cl associations
« — Internal response times by type/priority
= 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)
o 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
Page I 16
Version & Last updated See file n
Document owner Steve Bre
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Managing Problems
o Problems must be logged in the Fujitsu service management toolset, TfSNow
o 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
o 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
o Peaks related to Fujitsu Problems will need to have the Fujitsu Problem reference added so
the association is clear when checked from either system
o Note: Fujitsu use Problem tasks and manage the updates to those
o Major Incidents will lead to Problems being raised to close outonvall findings
o Fujitsu MAC will notify Problem of underlying issues identified from Incidents -these tend to
relate to Unix, NT etc (TfSNow Resolver Groups) and no Peaks (Peak has its own processes)
o Problems also use the State field - Acknowledged, Work In Progress, Researching, Fix In
Progress, Suspend — to record and track status.
o Problems should have the HDR applicable Cl added if applicable
o Problem reporting should how HDR tagged Problems
o 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)
Actions
System Changes
One-Time Actions
1.
2.
3. Sandie/Steve(s) - We need a comms to go to ALL TfSNow users to remind them that
e any Incident that POL need to be notified of or be aware of must be logged in
TfSNow and bonded. Raising a Peak only is not correct
«we do not reference KBAs, Peaks or internal content in TfSNow bonded Incidents
and that the TfSNow Incident must contain all relevant content and 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)
« the Summary field needs to be well worded and understandable by most readers as it
will be used in reports for management and POL and will affect the description fed to
POL and into our own Peak system
« we should not using separate emails to share progress that is not embedded into the
Incident updates
Page I 17
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e less qualified individuals may read Incident content so it must be well worded and
should use language that is understandable to most readers
* anyone should be able to look at an Incident and quickly determine the current status
and the next action so as to be in no doubt that the Incident is under full control. The
most effective way to do this is to make updates that convey this message and avoid
updates that lack context
e they must not change the Category/Sub-category on bonded Incidents or it will break
the replication link
« We should use the relevant open and close categories when handling Incidents —
applying additional caution with bonded Incidents to use the mutually agreed settings
e The LiveAffectingDefect Cl is needed for Live Defects
e The HDR* Cls are needed for special category Incidents and this will be set by
Fujitsu management
« 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 is received from you.” Is to be‘added. After 10 days, these
Incidents should be closed
e We need any local Work Instructions or process:documents updating to reflect these
changes j
« We need to raise Incidents when internalPeaks relate to Incidents that POL should
be aware of
4. Sandie - confirm the mutually applicable open and close categories and Cls with POL and
document for both parties to be clear
11.
12.
13.
14. Steve Ba/Sandie/Matt H — identify all documents that need to be updated to formally
implement all these changes:
a. MAC Wis
b. Major Incident procedures
Page I 18
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Incident procedures
Problem procedures
Duty Manager handbook
c.
d
e.
f.
17. Sandie - we need a process for new Incidents raised when a Peak is determined by any
team to need alerting to POL that creates a new Peak that has the content of the original
Peak copied across so as to ensure the updates continue to flow through TfSNowand
ServiceNow. The original Peak should then be closed as it has been superseded
18. Sandie - we need MAC to ensure that any Peak ticket that is closed that hasybeen cloned
and for which continued TfSNow updates are still needed (e.g. it is bonded to POL) is sent
back to Peak for the Peak to be reopened. Otherwise the TfSNow incident will stagnate as no
Peak updates will be received and manual chasing will be needed to getprogress updates on
the cloned Peak
19. Steve Br - arrange a briefing call with all relevant POA managers, to explain this stream
20. Steve Br - Investigate how Post Office Cloud systems and processes will affect these
processes and ways of working
New Ways of Working
1. Sandie/SDMs - We need to regularly check thatany Incident that POL need to be notified of
or be aware of has been logged in TfSNow,and bonded
2. Sandie - We need to regularly check
¢ that we do not reference KBAs, Peaks or include internal content in TfSNow bonded
Incidents and that the TfSNow Incident contain all relevant content and be a
comprehensive self-contained reference to the status of an Incident. The only Peak
reference that should bevadded is for defect Peaks (if applicable)
e Incidents are being updated and that we are not using separate emails to share
progress that isnot embedded into the Incident updates
« Incident updates are’well worded and use language that is understandable to most
readers — Challenging and coaching where needed
e the currentstatus 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
e ‘the relevant open and close categories are being used when handling Incidents —
applying additional caution with bonded 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 Reference is also added to the Incident)
e 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 is received from you.” has added. After 10 days, these
Incidents should be closed
3. 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 to improve error repellence
4. Sandie/Steve Ba — create a weekly report and review process to check that HDR Incident
updates are reading well and are up to date
Page I 19
Version & Last updated See file n
Document owner Steve Bre
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
5. Sandie - Close Incidents when investigation Peak is closed and a defect Peak Reference is
provided
6. Matt H - ensure slow responses to Problem updates by POL are escalated and covered at
the monthly SMR
7. Matt H - ensure Peak reporting of Peaks tagged as relevant to Problems is received and
used to help drive Problem management
Page I 20
ed: See file name
Steve B
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Stream 2 — Use of Peak (3LS, 4LS & Release)
°
Team — Adam Woodley, Tariq Arain, Matt Swain, Tomi Okelola — plus John Simpkins & Mark
Wright
The use of Peak and the updates to the tickets must be consistent and documented. That
takes the onus off the people and it enables anomaly reporting and management oversight
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
If any 3LS, 4LS or Architect creates a Peak in the course of their normal duties that matches
the definition of Live Defect:
¢ Relates to the LIVE system only (this excludes Test, RDT, and internal tasks)
¢ Is, or appears to be, inconsistent with the agreed design or service specification
...then it must be given the ##LiveAffectingDefect Collection and anIncident must be raised
in TfSNow if one is not already open.
If a 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 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)
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 whichwill 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 aPeak linked to TfSNow
When the investigation into an issue defined in a Peak originating from TfSNow is concluded,
the ‘investigation’ Peak can be closed
e lf 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)
« 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)
« 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
The interface between TfSNow and Peak (OTI) must protect the internal system references
to Peaks of 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
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
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
Page I 21
Version & Last updated: See file n
Document owner Steve Bro
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e See section Live Defect Management — Key Fields in Peak
© Cloning processes and rules need to be applied consistently:
e Cloning must carry forward all References and it must show cloned from and cloned
to support chain of events tracking
* Cloning should be for specific purposes:
= 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 an Incident)
= Creating the defect Peak to progress the Live Defect to.resolution
= Creating Test Only Peaks where the test in a particular environment can’t
mirror the entirety of the issue described e.g. 3% party connections are not
available. This is rare. Testing is then:done onthe 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
o Peaks raised in Test or Dev that also relate to the,Live environment will 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 tothe Developers. It has a Call Type “P” by default
e The Developers & Architects decide if it relates to Live and must set the relevant
Live Defect meta datavas described above
co 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 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 have been held by EDSC due to having been cloned and having a ServiceNow
reference must be periodically reviewed to ensure updates from the cloned Peak are applied
o Peaks, that.are closed that have a ServiceNow reference with the reason being that a cloned
Peak is now to be tracked will be sent back to Peak by MAC to reopen the Peak as this must
be maintained to ensure the continued automatic flow of updates to the originator
o Rules on use of Call Type need restating so we ensure greater consistency
o All Peaks must be owned by a team whose manager will check that progress is being made
We need regular management quality checks — use of fields, age of tickets, 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 isn’t readily query-able until it is in Excel so we will need Excel
reporting
co ‘Private’ Peak updates can be added to the Progress field. They stay in Peak and are not
replicated across the OTI
Page I 22
Version & Last updated See file n
Document owner Steve Bre
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
o Updates added the Response field are replicated across the OTI
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),
or when the next action needs to be assigned to another TfSNow Resolver Group
(the Peak is no longer needed)
e Incident related Peaks are closed when the investigation phase has concluded and
we have a confirmed Live Defect. This would see a cloned Peak raisedias 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 “#”
e 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 specificrules — 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 in
order to improve error repellence. A likely source,Of these. will 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
« “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 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 from the relevant ticket — not separate emails or meeting comments
o We need to definé.a Peak extract process that will brand, classify and version control
content.Jt‘must also tedact/obfuscate to remove PII and remove internal only Progress
updates
o Deferred Peaks from RAM/RAB should be recognisable against the release they were
deferred from and the release to which they are subsequently targeted
o RAM/RAB can only defer Peaks — it CANNOT defer Jira’s or other things stored outside of
Peak
o Deferred Peaks are by definition Live Defects. The RAM/RAB lead must ensure:
e the ##LiveAffectingDefect Collection is set
e the “Deferral Agreed” Collection set
e 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
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):
Page I 23
Version & Last updated See file n
Document owner Steve Bre
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
= 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)
o Release Notes must list all Peaks that are fixed and being deployed. The extract/report must
also show the POLPRB- reference for HDR Defects and the Fujitsu Problem references if
they have been tagged to be tracked by the Problem manager(s). This is achieved by
clicking the button to the right of the listed Peaks in the Release Note which»creates an Excel
spreadsheet that can attached to the TfSNow Change ticket (format similar,to below):
Por Problem Refiuisn Probie Ref
sts in DCM_LREC.DCM_ CREATE LREC_C4D jo
CalReironesumamy SS
3 4: Proper messages has to dispaly stead of Age
Too tm D records it LREC fle
ted as expected when reconcing DRS? reports
3388718 Lloyds £300 withdrawal [MCSUK-16376]
o Release Notes will not list:
« the Peaks that are being deferred (as they are not fixed yet)
e 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 alliaré’set to Status “F” and alert the originator that
the fix is deployed and they are asked to close the Peak
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 rélease that they relate to and the third node is the hotfix
number. Peaks that form part ofa hotfix will be targeted at the 3 node Release
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, Pilotrelease date when at least 1 live branch saw new code installed)
e All future Releases must show the latest anticipated release date for deployment —
irrespective of who will be leading the deployment
« The Target Release screen should be used to make universal changes to Peaks
when release information changes
‘», 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
Actions
System Changes
4. Johi te-a-butt ide-the-listed Peaks-on-the Rel Note-that- gather-th
7 g
tenth into-the TESNow-Ch: ticket-to-includ extract
Page I 24
1 & Last updated: See file n:
vent owner Steve Bre
POA Improvements
FUJ00232720
FUJ00232720
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
(Ca
PC0295314
4: Proper messages has to dispaly instead of Agent events in DCM_LREC.DCM_CREATE LREC_ C4
PCO29S403 LST: 20.94: Too many D records in LREC fe
PC0295711 PBS Pao
3349716: Amex tas not settled a expected when reconciling DRS2 reports
PC0298725 PBS: INC8354763 (IFSNow) : INCO388718 Lloyds £300 witlrawal [MCSUK-16376]
One-Time Actions
1. Adam/Sandie — check which documents on the use of Peak/TfSNow/POA ways of working
need to change to what is described in this document
a. Application Support Strategy
i. Needs full explanation of the new Live Defect key fields
ii. Root Cause values need explaining
Architecture
Design - Platform Design
Design - High Level Design
Design - System Outline
Development - Build Scripts
Development - Code
Development - Low,Level Design
Development - Reference Data
Requirements
Cfg Mgt - Config Data Error
Integration - Build
Test - Test interpretation
Test - Script
Test Data
Test - Environment
_General - Network Change
General - Hardware Fault
General - User Knowledge
General - User
General - in Procedure
Gen - Outside Program Control
General - Operational Change
Gen - Investigation On-Going
General - 3rd Party issue
General - Unknown
e 1
° 6
° 7
. 8
e 13
. 14
e 15
° 16
e 21
e 24
« 26
e 31
e 32
© 33
©) 34
2 37
© 38
2 39
« 40
° 41
° 42
e« 43
e« 96
2 97
e« 99
b. SSC Wis
c. Peak User Guide
2.
Page I 25
Version & Last updated
Document owner:
See file name
Steve Browell
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
4 i i i ised AETER-a-Peak-to-th
7. Adam/Tariq/Simon — 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
8. Adam - Guidance on the reasons for cloning needs restating to ensure consistency across
teams (awareness of the UK Bridge new process for GDC GDPR obfuscation should also be
cascaded) -
9. Adam - Rules on use of Call Type need restating so we ensure greater consistency
10. Adam/Tariq — Guidance on.when Peaks can be closed needs restating so we ensure greater
consistency :
11. Adam/Steve Ba/Sandie — Peaks closed as user/process error should be considered along
with TfSNowincidents closed for the same reasons to provide a monthly report to POL to
recommend enhancements in order to improve error repellence
12. 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
13. Adam/Tariq - Manager reports will need to be created to enable spot checks on Peak data
entry quality and to encourage new habits — fields filled in, fields read well, clones created for
correct situations
14. Sandie/Steve Ba - SMC need to ensure KBA references are added to the Peak References
field
15. Matt S - Release Management to populate all past and future release dates (where known)
on the Target Release screen — this only needs to cater for historic releases mentioned in
Hi NeAfectingDefect tagged Peaks (ins will limit the historical scope)
Page I 26
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
° Peon astern POrR
48. Matt S—Hotfi ini-tel d-should. th 3-nede-rek b
19.
20. John - Conduct feasibility work to check how Peak extracts can be created — branded,
obfuscated, redacted, exclude Progress updates etc — for potential future sharing
commitments
21. Adam - Notify the SSC team and create a process so that 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 So that the related
TfSNow and ServiceNow Incidents continue to receive updates. We.need to agree,
implement and document a frequency for doing this. Is weekly'enough?.If updates are
demanded more frequently then MAC will be chasing so it will become apparent quite quickly
if higher frequency updates are needed. 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
22. Adam — we need a process for new Incidents raised whenia Peak is determined by any team
to need alerting to POL that creates a new Peak that has the content of the original Peak
copied across so as to ensure the updates continue to flow through TfSNow and ServiceNow.
The original Peak should then be closed as,it has been superseded
23. Adam — we need SSC to understandthat/MAC may reopen Peaks by assigning them back to
the Peak resolver groups to ensure that any Peak ticket that is closed that has been cloned
and for which continued TfSNow updates are still needed (e.g. it is bonded to POL) is kept
open to ensure updates continue to be provided. Otherwise the TfSNow incident will stagnate
as no Peak updates will be received and manual chasing will be needed to get progress
updates on the cloned Peak
21. Steve Br - Look at reporting tools to remove dependency on individuals and their Excel skills
22. Steve Br — arrange a,briefing call with all relevant POA managers to explain this stream
23. Steve Br - Investigate how Post Office Cloud systems and processes will affect these
processes and ways of working
« MS mentioned Jira — is this what we are now expected to use? Or is it Peak?
« MW mentioned the new cloud systems will use Jira not Peak
*. TA mentioned 4LS do not have access to the POL JIRA system unless in the P2C
team. What are the FJ views and processes around POL JIRA?
New Ways ofWorking
1. Adam/Sandie — update documents on the use of Peak/TfSNow/POA ways of working that
need to change to what is described in this document
2. Adam/Tariq/Simon/Sandie — regular checks should be made to ensure 3LS, 4LS or
Architects who create Peaks in the course of their normal duties that relate to the Live
system where POL should be notified are contacting Fujitsu MAC to raise an Incident and
determine how to ensure the Peak is correctly associated
3. Adam/Tariq/Simon - The fields relevant to Live Defect Management tracking and reporting
need to be completed by various parties as the Peak progresses
4. Adam/Tariq - Investigation Peaks are to be closed when a Live Defect is confirmed - once a
clone has been created for the defect Peak
Page I 27
Version & Last updated: See file name
Document owner: Steve Browell
11.
. Adam — Check Peak closure guidance is being followed
13.
14.
18.
20.
21.
FU,
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Sandie/Adam/SMC - The Summary field needs improving to make more sense to more
readers as it will be used in internal management reports and extemal POL reports
Adam/Tariq - Call Type “#” is for confirmed Live Defects only and needs to be used by the
teams
Adam/Tariq - Peaks that relate to the Live system should have their Call Type set to “L” until
they are confirmed or qualified out
Adam/Tariq/Simon - Current progress and status must be in the Peak and not in separate
emails, minutes or documents. Such external content must be added to the Peak
Adam/Tariq/Simon - Managers will need to conduct spot checks on Peak data entry quality
and encourage new habits — fields filled in, fields read well, clones created for correct
situations
. Adam/Tariq/Simon - 'Private' Peak updates can be added to the Progress field but caution
should apply in case the content is ever accidentally shared
Adam - Check cloning consistency periodically
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 in order to improve error repellence
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 showthe outcome was that POL need to raise an
enhancement request
. Matt S - Release Management must maintain. the, Target Release dates and ensure they
propagate to associated Peaks — at least weekly
. Matt S — Release Management mustuse:the 3-node release numbering system for hotfixes
and must target the relevant Peaks at the hotfix reference
. Matt S - Release Notes must list all Peaks that are fixed and being deployed and be shared
with POL — and show the POLPRB- reference and Fujitsu Problem references if stored in the
Peak (to enable other functions to validate status). This is achieved by clicking the button to
the right of the listed Peaks in, the Release Note which creates an Excel spreadsheet that can
attached to the TfSNow Change ticket (format similar to below):
CaRaiaseSammay Sas : [POL Pokaan aad
FPCO29S314_LST2094: Proper meas lst dsply ntl of Apt eve mDEM,LREC-DCM, CREATE_LRBC_CAD 0
19C0295403 1ST:2094:Too may D rcors n LREC Se
1PC0295711 PBS Pit INC349T16: Ane bs ot seted a epaced whoa icons DRS? ipa
BRC0D9S725 PBS: INCE3S476S (LFSNow) :1NCO368718 Lys 200 witha (CSUK-16376]
cy
Matt S + Release Management must ensure TfSNow Change tickets show all Peaks being
fixed along with their applicable POL and/or Fujitsu Problem references
. Matt S — Hotfixes are a mini release and should be managed that way to enable Peaks to be
targeted at them and the release dates to be more clearly traceable
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
RAMIRAB - Deferred Peaks will need to be updated. The RAM/RAB chair will need to
ensure:
othe ##LiveAffectingDefect Collection is set
othe “Deferral Agreed” Collection set
o 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
o Target Release Type changed to “Proposed for” for subsequent update via BIF/PTF
Page I 28
Version & Last updated: See file n
Document owner Steve Bro
FUJ00232720
1J00232720
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
Page I 29
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
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)
See file name
Steve B all
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Stream 3 — Live Defect Management
o Team — Adam Woodley & Tariq Arain — plus John Simpkins
Live Defect Management — Live Defect Definition
o All Live Defects are managed in Peak only
o Some classifications of Live Defects are managed in a joint weekly Horizon Defect Review
meeting chaired by POL. These are known as HDR Defects
o ALive Defect is defined as an issue that:
e Relates to the LIVE system only (this excludes Test, RDT, and internaltasks)
e ls, or appears to be, inconsistent with the agreed design or service specification
« 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)
« There may be a workaround, but the/underlying issue still meets the criteria above
e An Incident may be under investigation’that is not confirmed to meet the criteria
above but has attributes that meet the criteria above (a potential Live Defect/HDR
Defect)
o Note 1: Defects identified and managed throughout the Development and Test stages are not under
this Live Defect Management process as they:do not relate to the Live system. Hence there are 3
types of defect:
* Live HOR Defects
«Live (Non-HDR) Defects
* Non-Live Defects, (test/dev etc) — not tracked by Live Defect Management
o Note 2: KBAs can be raised 'to.describe Live Defects but the management of the Live Defect is done
by the Peak ticket and.this.Live Defect Management process
Live Defect Mamagement — Goals
o Live Defect Management must have a designated owner on POA to manage and evolve the
processes. and systems used
o Staff will need training and guidance on how POA wants Live Defects to be managed and
how,the systems need to be kept up to date
o Live Defects must be recorded as Peaks and managed using the Peak system
e Fujitsu may have Problems open for Live Defects but the Problem record needs to
hold the relevant Peak reference as this will be where progress updates will be
derived
o We must know how many Live Defects there are at any point in time — and importantly, we
must know which ones are part of the HDR Defect tracking led by POL and we must store the
POL tracking reference on our defect Peak
o Weneed to be able to differentiate between Live Defects that are still being investigated and
are not confirmed, and Live Defects that have been confirmed and require action to resolve
o We need to know the status of all Live Defects and whether there are any issues needing
attention
Page I 30
1 & Last updated: See file n:
vent owner Steve Bre
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
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
o Live Defects must be clearly titled so that they can be understood by the majority of readers
o Live Defect status must be clearly stated and be current and not require the reader to read
content and come to a summarised view themselves
o All Live Defects must have a clear next action stated that can be tracked
o 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 Incidentopen 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 itis 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 —
Enhancement Request’] which will see it‘excluded from Live Defect counts in the future. The
HDR-* Collection should remain so we:knowiit was considered within the HDR meeting
o When a HDR Defect is confirmed a§ 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 ticket
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 meeting.
o Live Defects that:are not classified as HDR Defects are managed internally by Fujitsu using
Peak. Reports willbe 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 Defect Peaks deferred from RAM/RAB when a release is deployed are, by definition, Live
Defects. The RAM/RAB lead must ensure:
e the ##LiveAffectingDefect Collection is set
e the “Deferral Agreed” Collection set
e 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
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)
Page I 31
Version & Last updated See file n
Document owner Steve Bre
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
= 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)
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
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
o We need to provide a full list of ALL Live Defects closed in a Release with their associated
POL Problem references so that POL are also able to manage their HDR process
o Reports are needed for management to show the overall status, trends, and.patterns related
to all current Live Defects and historical Live Defects
co CBIF rejections will get a 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
o The outcome of BIF/CBIF/PTF meetings will be held in concise notes in the relevant text
boxes on the Release Mgt tab. No need for separate, minutes
o Peaks that have been tested successfully and are still to be deployed must not be closed and
must be routed to RM-x and assigned to “Release to Live” so it is clear that the Live Defect is
still present in the system but that its fix,nas been’tested and is awaiting release
Live Defect Management — Key Fields it 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
Live Defects ought to be Call Type “L” Live Incident but can have other Call Types provided
they carry the ##LiveAffectingDefect Collection
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 preservellinks where raised in another system)
co Impact tab and free form field to articulate impact, status and next steps so it is easy to
understand for anyone. This will be maintained for HDR Peaks weekly. For other Peaks it can
beas 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
o Priority —- which must be validated at all times so it is accurately shown as this will affect
reporting and decision making
o Collections of “HDR-Fin” or “HDR-Exp” for HDR Defects
o POL Problem reference — using the prefix “POLPRB-“ so it is obvious and also searchable
o Fujitsu Problem reference — using the prefix “FJPRB-" so it is obvious and also searchable
Page I 32
Version & Last updated See file n
Document owner Steve Bre
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
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
e Workaround is a Reference field and the following 2 screenshots show how to add
the field and set its value:
eak incident Management System - 2C0295241
poe as oT
feat ntsc rary
(cate
(cantatas
Freer Rel
Peak Incident Management System - PCO
Feats Te
[cat reference
‘Aad Riera
Fapesed Fama =e]
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 isitaken
o Product Group and Product - We need to know the part of the system that the Live Defect
relates to for reporting and quality purposes
o Root Cause~ we need to know what type of fix was needed, which when matched to the
part of the system affected, gives us further quality data
o Response Category — specific values have been identified to enable clarity and to spot
exclusions:
e “63 -- Final -- Programme approved - No fix required” — for Peaks rejected at CBIF
e “66 -- Final -- Enhancement Request” — for Peaks tagged with the HDR Collection
that were subsequently qualified as not being HDR Defects but enhancement
requests
e “95 -- Final — Advice after Investigation” — for Peaks tagged with the HDR Collection
that were subsequently qualified as not being HDR Defects
o Management governance and checking is needed to ensure this is how the system is being
used — correcting at least weekly
Page I 33
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Live Defect Ma
« 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
e The 2 reports are:
1. Report to extract all ##LiveAffectingDefect tagged Peaks and show the following
columns:
2. Report to extract all Open Peaks and show the columns as above
agement — Reporting
e The output fields for both queries are to be:
Call Reference, Summary, Date Opened, Product, Product Group, CallyType; Priority,
Assigned Team, Status, Root Cause, Collections, References, TfSNow, Incident; SNOW
Incident, 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, Cloned from, Cloned to, Contact Name
Actions
System Changes
John —Ri HH TypeL"t “Defects? fromtabel{ Jeted-c47.06-2024
ps feomp! 7065
pf 6 2 PH PH Fw DP
Page I 34
Version & Last updated See file n
Document owner Steve Bre
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
15. John/Steve Br — Create reports to spot Response Category values and Call Type “#”
mismatches and other related anomalies
One-Time Actions
Page I 35
of the following fields to th: " tf
g iy
Workaround
Product
thi has-3 " d-this-field-will-be-shared.
Pi P
t t the-whole-field_past ied-text-bety th
pai to
th r ted Busi \ + ine-Check-th
iP ie -
B i " nl th tion-he
pact: a
tat date <<deseription-of tstat "
pdate: iP
Next action: taction-to-be taki expected dat
fe tupdat itis-ch hatis-being-d db:
Ps g y
when>>
Root Cause
Ifa KBA refe t:shown-but the-detail-text
PP
then-add it to-the Ref field-so-itcan-b -easil
4 ¥
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
3.
4.
5.
6. Adam - what documents need updating to formalise all this?
e Application Support Strategy
* SSC WIs
e Peak User Guide
7. Adam/Steve Br - what reports are needed to help police the use of the system and.alert to
anomalies?
8.
9.
50 it is clear that the Live Defect is still present in the system but that its fix has been tested
and is awaiting release
10. Steve Br/Steve Ba/Tariq/Adam/Graham — when the final listtof Live Defects is visible,
identify policy statements and decision criteria thatican be defined that sees defect Peaks
either closed or actioned where currently they’Seem to,have stagnated
11. Steve Br — we need to assign a Defect Manager’on POA to own and evolve Live Defect
Management
12. Steve Br — Draft a Live Defect Management document for Dimensions
13. Steve Br — Write examples of text for Business Impact or Status update
17. Steve Br - Agree a process for CBIF Proposal creation
18. Steve Br - Check tagging of closed Peaks (Status “F” or “C”) where the Release is yet to be
deployed
19. Steve Br — arrange’abriefing call with all relevant POA managers to explain this stream
20. Steve Br — Investigate implications of Post Office Cloud on ways of working. Check how Live
Defects,are being recorded in AWS JIRA and be sure it is aligned to this Live Defect
Management process or that an agreed alternative way of working is defined and agreed at
DE/VP level
New Waysof 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
3. Adam/Tariq — Change the process to create a defect Peak with Call Type "#" that will be
managed to release at end of investigation and close the original Peak. If the confirmed Live
Defect is from a cloned Peak then the cloned Peak can just have its Call Type changed to “#”
4. Tariq — advise Developers to promote to Call Type “#” when diagnosis made
5. Tariq — Jiras must be regularly checked and any that need action should be raised as Peaks.
6. Steve Br - We need reports to spot Response Category values and Call Type “#”
mismatches
Page I 36
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Page I 37
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Stream 4 — BIF, CBIF, PTF and HDR
o Team -— Steve Bansal, Sandie Bothick, Adam Woodley, Tariq Arain, Matt Swain, Tomi
Okelola, James Guy — plus cascade to all 3LS, 4LS, and Architects
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 If the Peak:
= Relates to the LIVE system only (this excludes Test, RDT, and internal tasks)
= — Is, or appears to be, inconsistent with the agreed design or service
specification
= Add the ##LiveAffectingDefect Collection
= If the cause and required action to remedy, are?
e — Still being investigated — then set the.Call.Type to "L"
« Are confirmed — set the Call Type to “#",and also update:
o Root Cause field is up to date
= 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 fieldsis up to date
o All Peaks with the BIF Action flag setwill 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
oO. Ifa Peak had previously been rejected - as more information was required - then it will have
the BIF Action flag’set again when the Developer is ready to re-present their proposal
oO BIF must consider the'proposal (as it does currently) and also validate the following data
values for defect Peaks:
¢ = Ifthe Peak:
=) Relates to the LIVE system only (this excludes Test, RDT, and internal tasks)
= _ Is, or appears to be, inconsistent with the agreed design or service
specification
= Ensure the ##LiveAffectingDefect Collection is set
= 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
= Ensure Workaround field is up to date
= Ensure Product Group field is up to date
= Ensure Product field is up to date
= Ensure Priority field is up to date
= Ensure Impact field is up to date
= Check if the new HDR Collections of “HDR-Fin” or “HDR-Exp” should apply.
If it needs applying then the chair must alert Steve Bansal, Adam Woodley
and Sandie Bothick. If the issue in the Peak:
Page I 38
Version & Last updated See file n
Document owner Steve Bre
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e Affects, or has the potential to affect, branch financial outcomes, add
the HDR-Fin Collection
« Affects, or has the potential to affect, the way a postmaster is
required to use the system (User Interface, Report, Function), add
the HDR-Exp Collection
e Affects, or has the potential to affect, the experience of a Post Office
customer or client, add the HDR-Exp Collection
= Check if there are conditions that would mean the Peak needs POL input and
hence must go to CBIF:
* — The fix can be done in more than one way and POL would need to
guide Fujitsu on choosing the preferred option.
* The fix may change the functionality of the systermand 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 heed 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 (Fujitsumanagement discretion).
* Fujitsu does not believe a fix is a sensible option and seeks POL’s
agreement toyrecord 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 recordjsin Peak on the Release Mgt tab, what decisions are made:
e The new BIF date fields (Initial and Completed) will need to be completed during, or
after, the BIF meeting (not before or it will affect status reporting)
« Initial date - will hold the date of the first BIF the Peak was first presented at
- this value should not change
= Completed date - will hold the last BIF meeting the Peak was discussed at —
this value will change if the Peak is iteratively presented for review and it will
allow reporting on what was reviewed at the last BIF meeting
* The outcome of BIF discussions should be added to the BIF text box on the Release
Mgt tab. A concise note is all that is needed. No need for separate in BIF minutes
Page I 39
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
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
«If the Peak does not need to go to CBIF then the PTF Action flag will be set
The definition of BIF in the contract ASM schedule needs to be updated
CBIF is a joint meeting with POL.
CBIF will continue to exist and it will be merged with the
HDR meeting
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:
« PTF Action is not set
e PTF Initial and Completed dates are still/blank
e BIF has been completed — the new BIF
Completed date is prior to today
e The Peak has the ##LiveAffectingDefect
Collection
e Priority is A or B
e Peak originated from a,POL raised ServiceNow Incident
¢ Peak has one of the:CBIF criteria checked from
BIF
Peaks required to go to CBIF willbe 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 tovinviteran SME to elaborate (only for exceptional submissions) then the
SME will beinvited. 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:
=I
= z
ial and
e The new CBIF date fields (Initi:
Completed) will need to be completed during,
or after, the BIF meeting (not before or it will affect status reporting)
= — Initial date - will hold the date of the first CBIF the Peak was first presented
at — this value should not change
Page I 40
See file name
Steve Browell
Version & Last updated:
Document owner
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
= Completed date - will hold the last CBIF meeting the Peak was discussed at
— this value will change if the Peak is iteratively presented for review and it
will allow reporting on what was reviewed at the last CBIF meeting
* The outcome of CBIF discussions should be added to the CBIF text box on the
Release Mgt tab. A concise note is all that is needed. No need for separate in CBIF
minutes
e If the Peak needs to go back to the Developer then it should be assigned to the
Developer team
e 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
e CBIF rejections must get a POL reference which we add to the,Peak and also to the
KBA so we know this was a POL decision. The Peak is then closed with Response
Category “63 -- Final -- Programme approved - No fix required”
o There will need to be a weekly report seen by management of what.is to’be presented at
CBIF, and what the status is of open CBIF items and POL decisions
co There is no definition of CBIF in the contract — it says BIF — this needs to be addressed
PTF
o PTF is a Fujitsu internal meeting
co All Peaks with the PTF Action flag set will be reviewed at BIF
e This will include all defect Peaks‘with the ##LiveAffectingDefect tag
¢ It will also include other Peakssthat may relate to other topics such as environments
or Peaks that the Developers wish to discuss at the forum
If a Peak needs to be re-presented at PTF then it will have the PTF Action flag set again
o PTF must consider the proposal (as it does currently) and additionally be mindful that any
that carry a HDR Collection or that have been presented at CBIF must get additional scrutiny
— and potentially prioritisation. — as progress will be reported to POL weekly
o. The PTF chair must record, in Peak on the Release Mgt tab, what decisions are made:
« The new PTF date fields (Initial and Completed) will need to be completed during, or
after, the PTF meeting (not before or it will affect status reporting)
= — Initial date - will hold the date of the first PTF the Peak was first presented at
— this value should not change
= Completed date - will hold the last PTF meeting the Peak was discussed at —
this value will change if the Peak is iteratively presented for review and it will
allow reporting on what was reviewed at the last BIF meeting
Page I 41
Version & Last updated: See file n:
Document owner Steve Bre
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
« 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.
¢ Fujitsu embeds any relevant KBA or Peak content into the Incident it Shares
¢ Fujitsu tags its Incidents and Peaks with the applicable HDR-* Cl or Collection tags
¢ 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
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 aKBA, 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
« Updates on potential Live Defects is provided via bonded Incident updates
« Updates on confirmed Live Defects is provided by defect Peak weekly reports
e The above ensure POL has visibility at all times either from their ServiceNow
Incident or by maintaining their ServiceNow Problem ticket (POL will need to
transpose datafromithe weekly Fujitsu reports into its Problem tickets)
e As this is an early warning forum too, we will also issue an email alert to the Fujitsu
Duty Manager distribution list and a POL distribution list to alert interested parties
o Summary
« Potential HDR Defects will be reported automatically to POL via the service
management toolset replication driven by Fujitsu updates to the TfSNow Incident
e Actual HDR Defects (including any deferred) will be shared with POL weekly by an
extract report from Peak that will be sent to POL in advance of the meeting showing
the latest update
¢ New CBIF content will be shared with POL on a weekly report from Peak that will
include the proposal and will be sent to POL in advance of the meeting
e Updates to CBIF content will be shared with POL weekly by a extract report from
Peak that will be sent to POL in advance of the meeting showing the latest update
o 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 ServiceNow Incident to a ServiceNow Problem — but that is
their choice
co 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
Page I 42
Version & Last updated See file n
Document owner Steve Bre
°
°
°
°
°
KB — Info O@ly
°
°
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
For the purposes of Live Defect Management, Fujitsu will use Peak references not TfSNow
Problem references
Fujitsu will provide its view of status — from its systems — and manage any difference of
opinion with POL
Fujitsu will provide weekly updates prior to the meeting
Potential Live Defects — no action required as the updates will already be in POL
ServiceNow
Confirmed, active CBIF, and deferred Live Defects — by sharing the latest update on
the defect Peak we are managing our side in the form of a report.
CBIF new Live Defects — for decision by sharing the pro-forma proposal in,a report
and inviting a decision
Note: Any reports will be checked and sent in advance of the HDR meeting, so POL’can add it
to their Problem ticket and ensure they are ready to provide a decisién to the\CBIF new Live
Defects
The HDR meeting 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
If POL need more information, the Fujitsu ticket owner is tasked to,get it and add it to our
ticket — or we get the CBIF proposal updated for resubmission. The new information must be
added to the system
POL need to hold the Fujitsu Incident or defect Peak reference in their Problem ticket so they
know what to ask us for an update on — and what to apply our report updates to in their
system
The HDR minutes need an overhaul for Fujitsu. This is the Fujitsu specific meeting and yet it
lists numerous Live Defects that are’not related to Fujitsu and the minutes are sprawling and
hard to follow. POL will be advised that:
.
They need to make it¢lear which HDR Defects are within Fujitsu's scope of
obligations
They need to show'the Fujitsu Live Defect reference (ServiceNow/TfSNow Incident
or defect Peak)
They need'to show Fujitsu's latest update
A summary, view at the top is needed - New, Open, Closed, by Severity, by area
affected, and trend
Any ad-hoe.calls should only be required when the next scheduled meeting is too far away.
Updates from Fujitsu must come from the Incident update or defect Peak report with any
additional comments made during the meeting being added to the Incident or defect Peak
There is, no‘definition of HDR in the contract — this needs to be addressed
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)
KBAs do not need to be shared with POL as the tracking needs to be on the Peak and
Incident raised to progress them
If the awareness or involvement of POL is applicable then there will be a TfSNow bonded
Incident and this will contain all relevant parts of any KBA so that the Incident that POL see
is a suitable complete reference
If POL accept a Live Defect —- namely decide that no action is required — then the KBA will be
updated accordingly and will have the POL applicable reference added so it is clear that it
Page I 43
Version & Last updated: See file n
Document owner Steve Bro
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
was not fixed by POL decision. This is a contract responsibility on POL to record these and
issue Fujitsu with a notification
Page I 44
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Release Mgt tab — for BIF, CBIF and PTF
pera I sermnces I movers I smmce I mmc I couscns I tanaermme [ mums wor
f Tides} 1247 i Last Eat ioin Smphins i ‘DateTimeI2021-07-08 163948
[Business impact Forum GBIF) 5
"ter te camere BIF status. Indie items suchas.
1, Date - Date ofthe fast review
2. Stans - BIF statu Sitowing the astacton
3. Action -Person/Departnest with ay actions to progress ifDefirred,
4, Reject Reason - Reasor i
(Customer Bunness inpact Foran (CBIF)
[Ester te cunent CBIF stam Incide tems uch as
1. Date - Date ofthe fast review
‘2 Stas - CBF staus folowing the last acon
wth any actions to prowess ifDefrred.
4, Reject Reason - Reasors ifautomers
Peak Tapeing Fon PIF)
[Emer the cuene PIF status Inchde tens suchas
1. Date -Date oft as review
2 ‘Stans - Targeted Release
3. Acton - Person’ Deparmert wth any actions to progress ifDefxred.
‘Managenere Foran (RMF)
[Enter the camene caus flomthe Rekase Management Forum Incude tems suchas
1. Date -Dat oft ast review
2. Action Person/Departnent wth any acions to progress the Defect Deferred
3. Review- Date review actons
Intal Dats DDNALYYYY) ‘Conpieed Dates DDNALTYYY)
Toa T
ToCutoner BF {
PF { i
Plamed Dates DDNMYYYY) ‘Heaul Dates DOMMYYYY)
Oubeeopmet
Ou litewraton i
moist
Oalst
Tito Prodiction T i
Sums I [Ztiew vy [Gow I HNG-x 209404 I [Owner I L I [ Save Changes
Page I 45
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232720
FUJ00232720
CBIF / HDR Diagram
If it 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 46
POA Improvements
FUJ00232720
FUJ00232720
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Incident — Peak — Defect — HDR — CBIF
Potential Defect
POL ServiceNow
POL Incident
I Bonded
If POL not
needed
ification
jOTl
Fujitsu Internal
Version & Last updated
Document owner:
Confirmed Defect
Fujitsu Reports
HOR/CBIF, or
Continuous Improvement
Live Defect Peak
Internal Live
Defect Peak
[Call Type changed
to “#"]
CBIF Peak
Deferred Live Peak
See file name
Steve Browell
All should be Call Type “#”
All should have the Collection
HitLiveAffectingDefect
If HDR then relevant Collection should be
added
Updates do not auto replicate
Updates are system driven by reports:
1. Live Defects with the HDR Collection -
for the HDR meeting
2. CBIF qualifying Peaks - for the HDR
meeting
3. Live Defects excluding the HDR
Collection - reported (TBC) under
Continuous Improvement
4, Deferred Defect Peaks — for
information and tracking
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
Actions
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
System Changes
1. John S - add CBIF selectable criteria to be completed during BIF
The fix can be done in more than one way and POL would need to guide Fujitsu on
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 withinthat context (Fujitsu
management discretion).
Fujitsu does not believe a fix is a sensible option andjseeks POL’s agreement to
record the circumstances in a KBA only.
One-Time Actions
o =BIF
o «CBIF
BENS
o PTF
Page I 47
Tariq — ensure the Developers know'the important Peak fields as they bring Peaks to
BIF
Tariq/Matt S — identify any documents that refer to BIF that need to be updated (e.g.
Work Instructions)
Steve Br —look.at amending the BIF references in the contract documents
Matt S/Steve\Br/John — identify reports for what needs to go to BIF, and what came
out of BIF (forminutes perhaps)
James -— identify any documents that refer to CBIF that need to be updated (e.g.
Work Instructions)
James/Steve Br — identify the POL obligations to provide references for rejected
proposals and ensure they are appropriately stored in Peak and on KBAs
Steve Br — look at amending the BIF references in the contract documents
James/Steve Br/John — identify reports for what needs to go to CBIF (incl CBIF
Proposal extracted), and what came out of CBIF (for minutes perhaps)
Steve Br/James — agree the process for the weekly report creation, validation, and
sharing with POL
Version & Last updated: See file name
Document owner: Steve Browell
FU,
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
4. Matt S/Steve Br/John — identify reports for what needs to go to PTF, and what came
out of PTF (for minutes perhaps)
o HDR
1.
2.
3. Steve Br — amend TOR to incorporate CBIF and the basis of what qualifies for CBIF
submission
4.
5. Steve Br/Steve Ba — agree the process for the weekly report creation, validation,
and sharing with POL
6. Steve Br — look at how HDR should be referenced in.the contract documents
New Ways of Working
o =BIF
e Tariq — Developers taking defect Peaks to BIF need to ensure the Peak fields are
set as follows
= Set the BIF Action flag
= Ensure the Call Type is set tov'#”
= Ensure the ##LiveAffectingDefect Collection is set
e Matt S - ensure that the BIF chainis aware they must:
= Ensure current Priority is correctly set
= Ensure Call Type is setito “#”
= Ensure the ##LiveAffectingDefect Collection is set - except for internal
environment Peaks
= 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
= Update the BIF date fields on the Release Mgt tab for each Peak reviewed
* Add. concise note to the BIF text box on the Release Mgt tab. No need for
separate in BIF minutes
= 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
= If the Peak does not need to go to CBIF then the BIF chair should set the
PTF Action flag
= Create any BIF minutes by using Peak queries that extract the fields required
o CBIF
e James -— The CBIF representative must record, in Peak on the Release Mgt tab (but
not in the presence of POL), what decisions are made
= The new CBIF date fields (Initial and Completed) will need to be completed
during, or after, the BIF meeting (not before or it will affect status reporting)
«Initial date - will hold the date of the first CBIF the Peak was first
presented at — this value should not change
e 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
Page I 48
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232720
1J00232720
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
o PTF
.
o HDR
.
.
.
Page I 49
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
= The outcome of CBIF discussions should be added to the CBIF text box on
the Release Mgt tab. A concise note is all that is needed. No need for
separate in CBIF minutes
= If the Peak needs to go back to the Developer then it should be assigned to
the Developer team
= If the Peak can proceed as discussed then the PTF Action flag will be set
= — If the Peak is to be discussed next time (as POL wish to seek wider feedback
within their own organisation) then the PTF Action flag will not be set and this
will cause the Peak to reappear on the weekly report
= 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 “63 -- Final -- Programme approved - No fix required”
Matt S — ensure that the PTF chair is aware they must:
= Check if the new HDR Collections apply, or if the Peaks have been to CBIF
to ensure they get proper consideration and priority
= Update the PTF date fields on the Release Mgt,tab for each Peak reviewed
= Add concise note to the PTF text box on the\Release Mgt tab. No need for
separate in PTF minutes
= Create any PTF minutes by using Peak queries that extract the fields
required
Steve Br/Steve Ba/Adam/Sandie — the’Meeting needs to be fed with a report shared
in advance for confirmed Live Defects and CBIF updates (potential Live Defects are
updated through the serviceymanagement toolsets)
Steve Ba/Adam/Sandie - tickets in either Peak or TfSNow need to be robustly
managed and management willineed to check and coach the teams
Steve Ba/Adam/Sandie — Incidents tagged with “HDR*” need to be intercepted early
and an alert sent:to.an agreed distribution list in both Fujitsu and POL
Version & Last updated: See file n
Document owner Steve Bre
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Stream 5 — Security Improvements
o Team — Geoff Baker & Jason Muir
SecOps BAU
o Priority - Geoff
e Validate PAM roles for Belfast teams. The superuser roles should be the minimum
possible to achieve the operational responsibilities
e Ensure current levels of logging meet MSCF and contract obligations
e Shore up the internal PAM monthly verification processes, and add,a report and
governance for ISM and CISO review
e All POA users must be reminded that they must follow the account UAM and PAM
processes
e Review SVM/SEC/PRO/0012 and check that the 57 RBAC entries are still correct
despite it saying last reviewed 19/08/2020
e JML form does not link clearly to ROLE and RBAC
e Account creation - Wintel & other account creation functions should not use cloning
e Define reports and audience (perhaps all. PAM roles) — what do SecOps actually
track
« Define governance to be applied — what do SecOps check is ok and action
« Update all related documents on‘UAM and PAM - and contract documents if needed -
SVM/SEC/PRO/0006
Additional Items
co Priority- Jason
e Sort/explain non-compliant admin accounts that contravene segregation of duty rules
(to EBMS)
e Establish a central register of shared, break-glass and local admin accounts —
records of and management of (discovery and processes). Arrange call with Jill
SmythAndy Gibson, John Bradley, Chris Harrison, Gerald Barnes, Geoff Baker,
Andy Hemmingway, Tariq Arain, Matt Swain cc: Steve Bansal, Simon Wilson,
Graham Allen
=) Consider...
« Upgrade KeePass to commercial version/better solution
e Add KeePass content to weekly report
e¢ Confirm meaning of the PCI pen test obligations in the Security Service Description
o TBC
e Look into additional logging, reporting and review of Remote Connectivity activity —
or describe ‘as is’ and seek agreement
e Investigate the use of the remote Syslog server and determine if any logging should
be directed to Netcool. Capacity issues may limit options
e Counter access — why are counters accessed so frequently, should access be on
request not by default to protect our staff and the company from incorrect
accusations. We need to restrict RCA capability to escalate privileges. Also need to
confirm that commands are read only, counter account is read only, commands are
restricted — any doubt and we need to make changes
Page I 50
Version & Last updated See file n
Document owner Steve Bre
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Actions
System Changes
o TBC
One-Time Actions
Priority
1.
a. Belfast teams creating new granular specific admin roles and assigningteam to more
specific responsibilities
Mapping complete. Chasing validation from corporate and thenwe ean identify the
actions we need to consider
New Ways of Working - .
1. Geoff -— PAM verification process to be reported on monthly within SecOps governance (to
include routine validation of superuser roles)
2. Geoff - operate the monthly PAM verification process to a higher-level of rigour
3. SecOps — Maintain records,of all shared/service/local admin accounts and spot check the
processes around them
Page I 51
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Stream 6 — Elevated Access & Tooling
o Team - Varied. Mostly a one-time action stream
Actions
One-Time Actions
APPSUP
1.
2. Adam - Ensure 4 eyes/peer review happens - NWH or OOH
3. Steve Br — Amend both organisations’ Change Control documents to show APPSUP is
allowed out of process X
APPSUP — non-BRDB
1.
2.
3. Steve Br — Notify POL of action taken
Interface Interactions Logging
Page I 52
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Stream 7 — Various
o Team - Varied. Mostly a one-time action stream
Actions
One-Time Actions
Historical Investig
process
3. Steve Br — All staff must realise the need to demand a TfSNow ticket is.raised’by POL
(hence the above intercept will apply) — it cannot come in via email only
Monthly SMR pack
1. Steve Ba/Sandie — Limited Incident data - add trending and patterns
Steve Ba/Sandie — Highlights page is largely of no value
Steve Ba/Sandie — Some cumulative failures are not carried forward in stats columns
Steve Ba/Sandie — We embed minutes of other meetings and list Incidents - it's overly
padded
5. Steve Ba/Sandie — Needs to add links to HDR Defects,
PON
Peripheral Key Logger :
1. Steve Br — Decommission functionality as,notused
e Steve Browell asked Dean Bessell again on Thursday 24th June 2021 to check with
Lorna Owens and get.us a decision. CBIF 12.07.2021 has shown some POL
confusion that will be addressed at CBIF 19.07.2021
Documentation
1. Steve Br/Matt L —- We need to get all fundamental content gaps identified and actions
assigned
¢ Outstanding-CCD actions
e Service Descriptions
¢ Referenced documents in the contract
2. Steve Br/Matt L — Document list:
a), Security Service Description SVM/SDM/SD/0017
b) Governance Schedule A2 — names, chair and scope of meetings
cc) ,ASM Schedule 12 - BIF definition, Peak and KB proprietary references, POL KB
references for approved BEDs
d) Testing Strategy - 0936 document
e)
f) The CBA document Simon mentioned had the wrong Windows version in it
g) SVM/SDM/SD/0003 - DC Ops SD - states plans we should be creating [looks to be
ok — Steve Br to double check]
h) Change Control to mention APPSUP-
i) Application Support Strategy to mention Peak and Live Defect Management
Governance Meetings
1.
2.
Page I 53
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232720
FUJ00232720
POA Improvements
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
3. Steve Br/Dan — Working list of key meetings (POL attempting to lead on this):
a) Governance Meeting (Supplier Meeting)
b) Demand Planning
c) RAM/RAB
d) Change Control
Page I 54
Version & Lz
Document o1