Pe
FUJITSU
Live Defect Management on POA - v0.7
ASummary followed by supporting detail for each system
Changes in this version are shown by the yellow box top right and arrows to the parts that changed ~ as on this slide
FUJ00232847
FUJ00232847
©2021 FUITsU
Copyright 2011 FUJITSU
FUJ00232847
FUJ00232847
Document control (hidden slide) FUJITSU
Live Defect Management Overview
See file name until assigned
\n overview of the Live Defect Management process on the Post Office Account
o7
15-MAR-2022
DRAFT
Steve Browell
None
Fujitsu Restricted - Internal Use Only (see slide footers)
(CFaitsu Restricted intemal Use Only) (Giais side hidden and wil not be Alsplayed when your presentation running) ©2021 FUITSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Abbreviations & Glossary (hidden slide) FUJITSU
= Goatees tive Deel HSNon) seve Delt wee the couse an equ eo tae kn. he ves goton hes ona. ATISNow Dele net wi ext wih het dst 10a
rages
© Confined tive Detect (Peak) isa Live Defect where the couse ane requied action to fixate known, The investigation has conclaed, Adefect Peak wl exist with Cal Type"#"
= Defect Incdent (HSNow) ~isa SNow Incident that describes theconfmed Live Defect that wil be progressed bya Resoiver Group that does nat use Pak fe. Networs, Security, Unis)
Detect Peak ~ Isa Peak tat isnt linked ta TSNow incident ané that éescibes the cofimed ive Defect that wl be progressed trough the SOLC (IF, FTF, Dev, Test, Release} to lve
epioyment
= MORDetect ~ Live Detects tha affect, or have the potential to affect, branch operations finan experience, or end customer)
‘= Morizon Defect Review (HDR) «4 wee meeting wth POL to review HOR Defects POL nee to know the HOR Defects andthe status, They sae this with postmaster, This isa vey important meeting
that ses Fuss and POL aligned onthe HDR Deets
‘= Investigation Incident (11SNow) _~ isan cient thot is beng iavestigated where the couse an requied action ae not yt confimed Te lacident MUST be bonded if POL need tobe aware
‘= Investigation Peak - isan iccent thats being investigate where the cause an requied action ae not yet confmed. linked HSNow Incident may wel exist - an MUST eit if POL need
to beaware. The Peak Gl Typesould bet ifthisisa Live Defect
= an ~ Know/edge Base Ail. The term KEL s nolonger ta be used
= UveDeteet isa logee incident thats present on the Live sytem that iso: appeas tobe, inconsistent withthe agreed design or service specification
= on isthe interface between Peak and 1ISMow tht allows Incidents tobe transfered between the systems and updates to hedents to replicate
= ox ~ Post Office Account
= Po ~ Post offic Limited
= Potentiat Live Detect (Peak) ~ Isa Live Defect that we ar ti /ookinginto, There wil ely be a investigation Peak open and probably a Now Investigation Incident too. The Peak Cal Type shouldbe
be
‘© Potentat Live Detect (1fSNow) ia Live Defect that we atest ookingint thats lagged ase HSNow Investigation Incident The State wil be “Acknowledged, Workin Progress, or Researching”
(CFaitsu Restricted intemal Use Only) (Giais side hidden and wil not be Alsplayed when your presentation running) (© 2021 FUINTSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
The Goal
The POA Goals relating to Live Incidents and Live Defects
FUJITSU
Foltsu Restricted —Intemal Use Ony 4
© 2021 FUINSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Our Goals... FUJITSU
™ We action ALL logged Live Incidents as quickly as possible
@ We prioritise action on Live Incidents over ALL other work tasks
@ We log all Live Incidents in TfSNow and bond them to POL ServiceNow if POL need to be
aware
@ We investigate Live Incidents quickly providing clear and regular progress updates in TfSNow
@ If the Live Incident is NOT a Live Defect, we provide a clear update on our assessment of
cause
@ If the Live Incident is a Live Defect, we work quickly to determine the fix
m@ When the fix for a Live Defect is known, we work quickly to deploy it to the Live system
@ If the Live Incident or Live Defect affects, or could affect, branch operations, we share it with
POL at the Horizon Defect Review (HDR) weekly meeting
Foltsu Restricted —Intemal Use Ony 5 © 2021 FUITSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Summary
If you only need to know the key information...
Fojtsy Restricted —Interal Use On 6 ©2021 FUITSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Background - it isn't all new... FUJITSU
POA has operated a Live Defect Management and Incident Management process throughout
the whole term of the contract
This slide deck takes all of the previous methods and augments them with some new fields
and field values that support an improved end to end process for Incidents and Defects
The new processes also align to the agreed 2021 definitions of a Live Defect and a branch
impacting defect which have been defined with POL
The effective management of Incidents and Defects requires the consistent use of systems by
all specialist support staff and also relies on many manual processes
The information in this slide deck is meant as a quick guide for all specialist support staff
(MAC, 3LS, 4LS & Architects) using either Peak or TFSNow
Specific communications have been held at team level and a Live Defect Management guide
document will shortly be released to Dimensions as a fuller description
Foltsu Restricted —Intemal Use Ony 7 © 2021 FUINSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
It all starts with an Incident being logged FUJITSU
@ 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 aware of must be logged in
the Fujitsu service management toolset, TfSNow, and bonded so it is visible in the
POL service management toolset, ServiceNow
@ Incidents can relate to many aspects of the HNG-X solution but if they relate to the
Live environment then they have the potential to be Live Defects
@ This may not be apparent at the outset so the status will need to be under
constant review
@ If at any point the Incident is deemed to be a Live Defect, then it will need specific
tags adding and certain fields maintain (explained later)
Foltsu Restricted —Intemal Use Ony 8 © 2021 FUINSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Live Defect Management - Summary on-a-Page Fujitsu
sTfsNowlncdent *No ation needed *Solton ewan sCodefbuld solution + Package fixes ‘Deploy to Live
“Tavestgation Fesk Raise change appr0
nitiate Fe Tae to CF i neded
We always og Incigents that reat to the Liv envtonmentinTISHow and bond them if POL. eed to be aware. Ircidents logged nly in Peak mus be Fujitsu intemal ony
“Target toa Release Confirm itworks
“sien ei
atin eng
Ian Incident relates to the Live environment, then itis treated asa Live Defect until proven otherwise and it has LiveAlfectingDefect or Collection added for easier identification
‘We workat pace to investigate and reach a confi
1ed cutcome for Live Defects - either a Confirmed Live Defect or No Fault Found/Enhancement Request
‘We keep the fields and tags within either Peak or TISNow up to date to enable tracking of status and reporting of progress
Confirmed Live Defects are NOT bonded to TISNow and are managed through Fujitsu internal processes
Assigned TeamiAssignment Group owners must ensure progiess on ite
in their stacks and should encourage tearm members to do the same - especially in 315 and 41S
Live Defects take priority over Project work ~ including during the investigation stage ~ confit i to be escalated and handled by management
We always seek to identity a workaround for Confirmed Live Defects and we update the Peak Workaround reference te say YesNo andor we adda relevant update to HSNow
We always look at out-of course rapid deployment options for defects that are HDR-* or Priaity A (with implications & dependencies clearly stated). This MUST be considered at BIF & PTF
Every Confirmed Live Defect gets targeted to a numbered release fast (the next scheduled release forthe component area) - even ifthe release has no date
Releases without dates must be escalated to POA and POL until a date i assigned ~ this can be mitigated with pre-agreed maintenance release schedules
POA should have the next maintenance release date agreed with POL for EVERY component soa golive date can be stated for ary Confirmed Live Defect - PO. need to support this - POA
need the dependent processes al aligned so this can happen
POL cancelipostpone a scheduled maintenance elease, then this sa POL decision and any Confirmed Live Defects within that proposed release become accepted defects by POL,
Maintenance releases should be included on the Demand Planning «
jew ist and should be seen as the highest priority as they relate te LIVE SERVICE
= Counter maintenance releases need to be included within the major counter release schedules ~ POA needs a counter maintenance release option for low impact fixes
a Restited
Fal femal Use Only 3 ©2021 FUITsU
© FUJITSU 2021
FUJ00232847
FUJ00232847
ServiceNow, TfSNow, Peak and Defect Peaks FUJITSU
Potential Live Investigation Peak Confirmed Live
Defect Defect
Fujitsu Internal Fujitsu Internal
{unless HDR]
+ Updates auto
remicte + Live Defect Peaks are
. managed using Fujitsu
bere standard processes -BIF, CBIF,
Bonded updates PTF and the SDLC
Investigation Peak ola
oe ern on + Updates to Live Defect Peaks
4 are NOT linked to a TISNow
+ Wxiees Incident so are internal only
Seneeo - + Live Defect Peaks that have
Live imestigtion been marked as HDR Defects
apse will be reported to POL
Katgeru through a weekly report created
from specific fields in Peak
10 © 2021 FUIITSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Checklist guide for TfSNow Assignment Groups Fujitsu
Foltsu Restricted —Intemal Use Ony u ©2021 FUITsU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Checklist guide for Peak stack management FUJITSU
Foltsu Restricted —Intemal Use Ony 2 ©2021 FUITsU
© FUJITSU 2021
FUJ00232847
FUJ00232847
== =]
Live Defect progression... FUJITSU
2D IDEb Ib IDID IID
‘fSNow Incident *Noactionneeded —*Defect Peak “Soon eviewand “Target tt ropse Cadell soltion ~Pctagefies <Conimitwors~Deplyte Live
Investigation Peak Raise Change *Solution being Fora Release
“itiate Fix Identified “iki
1. INVESTIGATING - A Live Defect will start out as a Potential Live Defect until sufficient investigation has taken place
= [Fujitsu internal unless linked to a bonded Incident]
2. SOLUTIONING - If a fault is confirmed then this will progress to be a Confirmed Live Defect (if it is not a fault then the
Potential Live Defect will be closed). This stage is where the solution to the Live Defect is proposed for agreement by the
technical teams before moving to the next stage
= [Fujitsu internal as a viable solution still needs to be identified and agreed]
3. PROPOSED FOR - Once a solution is identified for a Confirmed Live Defect it will need to go through the POA processes
before the fix is assigned to a sensible Release. Proposed For is a recommendation as to the Release applicable and is
subject to change
= [Fujitsu internal involving developer / feature conflict check. Counter defects are discussed with POL]
4, TARGETED AT - The Release is known and defined. Releases are then managed through to deployment to Live
= __ [Visible to all parties as the Release work starts]
iced Only B ©2021 FUNTSU
Fal
© FUJITSU 2021
FUJ00232847
FUJ00232847
More detail on the systems and telated fields
and processés
1% ©2021 FUITsU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Fujirsu
shaping tomorrow with you
Live Defects...
Fojtsy Restricted —Interal Use On 15 ©2021 FUITSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
What is a Live Defect?
@ Live Defect
@ Is present ona LIVE system
@ Is within Fujitsu's scope of obligations
& Is, or appears to be, inconsistent with the
agreed design or service specification
@ Is, therefore, a fault that may need fixing
™ There may be a workaround, but the
underlying issue still meets the criteria
above
FUJITSU
To ensure that Live Defects are easily
identifiable, support staff should do the
following:
TISNow - add the LiveAffectingDefect Cl
Peak - add the #iffLiveAffectingDefect Collection
Foltsu Restricted —Intemal Use Ony 16
© 2021 FUINSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Live Defect progression... FUJITSU
@ A Live Defect will start out as a Potential Live Defect until sufficient investigation has taken
place
@ Assuming that there is a fault, this will progress to be a Confirmed Live Defect (if it is not a
fault then the Live Defect will be closed)
@ A Confirmed Live Defect will need to go through the POA processes before the fix is
eventually deployed to Live
@ The flow below shows the progression path for a Live Defect
@ Fujitsu is not currently required to report on the status and progress of non-HDR Defects
TfSNow Incident ‘action needed Defect Peak ‘Solution review and Target toa Release *Codelbulld solution *Packagefixes “Confirm it works *Deploy to Live
Investigation Peak “Seiten beg “approval
Tete sitkete cari
0 © 202 FUNTSY
© FUJITSU 2021
FUJ00232847
FUJ00232847
Understanding the status of a Live Defect FUJITSU
™ To be able to effectively track and report on Live Defects, numerous fields
must be completed and maintained
§ This will vary depending on whether the Live Defect is being managed
through TfSNow or Peak or both
@ Later slides explain the key fields for each system, and the checklists
provided in the summary section provide a guide for all users to remember
which fields to keep up to date
18 © 2021 FUINSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Handling Live Defects where no action seems
sensible FUjITSU
If we determine that progressing a Live Defect is not the best option (for example the feature is being
migrated and any fix would serve little purpose) then we should act as follows:
™ If there is a Live Defect then we have an obligation to fix it
™ We either fix it, or we get permission not to
= Permission can be from POL (ideally) or from POA DE/VP (second choice) - but they have to be empowered
to say “do nothing”
™ We then write a KBA to describe the approved fault so future calls know that no action is required
m™ We associate the KBA with the Defect Peak we will not be actioning
m We set the Response Category on the Defect Peak to “Programme approved - no fix required” (so it is
treated as a no action Peak)
™ We close the Peak
™ We leave the KBA open
Foltsu Restricted —Intemal Use Ony 19 © 2021 FUITSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Fujirsu
shaping tomorrow with you
HDR Defects...
Fojtsy Restricted —Interal Use On 20 ©2021 FUITSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
What is a HDR Defect? FUJITSU
@ HDR is the abbreviation for the POL led Horizon Defects Review forum
meeting
@ Live Defects that affect, or have the potential to affect, branch operations
are known as HDR Defects
@ HDR Defects can only apply to the Live system and are a specific
classification of a Live Defect
@ HDR Defects are shared with POL and progress on them is reported weekly
@ HDR Defects are the highest priority of Live Defect and are communicated
to postmasters by POL as part of its new ways of working
@ Progress on HDR Defects is highly visible
2 © 2021 FUINSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
How do you identify a HDR Defect? FUJITSU
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 To ensure that HDR Defects are easily
“HDR-Fin” Collection) identifiable, support staff should do the
following:
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)
TISNow - add the relevant HDR-* Cl
Peak - add the relevant HDR-* Collection
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)
Foltsu Restricted —Intemal Use Ony 2 © 2021 FUINSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
HDR Live Defect Tracking & Reporting FUJITSU
@ HDR - tracks the whole lifecycle of HDR Defects
j
if
DDL AD ADI =D AD!
‘fSNow Incident *Noactionneeded —*Defect Peak ‘Solution review and Target toa Release *Codelbuild solution *Packagefixes *Conflm it works *Deploy to Live
Investigation Peak Raise Change Solution being —_approval
sinitiate Fix WentitiedI Take to CBIF i
needed
Foltsu Restricted —Intemal Use Ony 2 © 2021 FUINSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Understanding the status of HDR Defects FUJITSU
™ To be able to effectively track and report on HDR Defects, numerous fields
must be completed and maintained as described earlier for Live Defects
§ This will vary depending on whether the HDR Defect is being managed
through TfSNow or Peak or both
@ Later slides explain the key fields for each system, and the checklists
provided in the summary section provide a guide for all users to remember
which fields to keep up to date
@ As HDR Defects are reported to POL, and from POL to the postmasters, it is
imperative that fields such as Summary, Call Type, Impact, and
Workaround are accurate as these are used for the standard reporting
2 © 2021 FUINSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Keeping TfSNow updated correctly...
Fojtsy Restricted —Interal Use On 25
©2021 FUITSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
TfSNow FUJITSU
™ We do not reference KBAs, Peaks or internal content in TfSNow bonded Incidents. The TfSNow Incident must contain all relevant content and be a
comprehensive self-contained reference to the status of an Incident. The only Peak ieference 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
I We should not using separate emails to share progress that is not embedded into the Incident updates
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 quickly determine the current status and the next action on an Incident so as to be in no doubt that the Incident is under
full contiol. The most effective way to do this is to make updates in “Additional comments (Customer visible)" that convey this message and avoid
updates that lack context
= Category/Sub-category must not be changed on POL bonded Incidents or it will break the replication link
m= We should use the relevant open and close categories when handling Incidents - applying additional caution with bonded Incidents to use the
mutually agreed settings
The LiveAffectingDefect (lis needed for Live Defects
m The HDR* Cis are needed for special category Incidents and this will be set by Fujitsu management - and will trigger a Fujitsu MAC alerting process
The State fled is important as itis now used to report status
.
When an Incident is placed into Suspend as no fuither 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 fiom you.” Is to be added. After 10 days, these Incidents should be closed
Alllocal Work Instructions or process documents should be updated to reflect these changes
isu Restricted — Internal Use Or 26 (© 2021 FUINTSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Keeping Peak updated correctly...
Fojtsy Restricted —Interal Use On 2
©2021 FUITSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Instructions at login and in FAQ FUJITSU
@ Summary instructions have been added to the initial screen presented after logging in:
Peak Incident Management System - RMG Account
—
™ Guiding content is also referenced in the news ticker when you sign in to Peak and in the Peak FAQ titled “What are
the current guidelines to manage Incidents and Defects in Peak?” (here).
[tat [> fbn Spi a 2021-30-11 12:55
An abridged of the recent changes for Incic and Defect: on Peak in a simple checklist format: Incident and Defect
‘management on a Page
Foltsu Restricted —Intemal Use Ony 28 (© 2021 FUINTSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Peak — new reference fields
™ POL Problem reference - using the prefix “POLPRB-" so
FUJITSU
it is obvious and also searchable. Most likely only
fequired when the Peak is declared to be a HDR Defect
(see screenshot showing location of Reference fields)
@ Fujitsu Problem reference - using the prefix “FJPRB-”
so it is obvious and also searchable. Most likely to be
updated by the Fujitsu Problem Manager to ensure the
link is clear (see screenshot showing location of
Reference fields)
Pea incident Manngeent Sytem PU
™ 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 for how to set the value)
Foltsu Restricted —Intemal Use Ony 29
(© 2021 FUINTSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Peak - critical fields and their values FUJITSU
= Collection ##LiveAffectingDefect. This
Collection must be set when the Peak meets the [Sus===
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
™ 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
= Collections of “HDR-Fin” or "HDR-Exp” for HDR §
Defects
Foltsu Restricted —Intemal Use Ony 30 (© 2021 FUINTSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Checking Collection setting history... FUJITSU
@ When a Collection is added or removed the history is held on the Release
Mgt tab in the RMF area as shown below:
Release Management Forum (RMF)
(03/11/2021 Added to Collection ##LiveaffectingDefect by John Simpkins.
(03/11/2021 Collection ##LiveAffectingDefect removed by John Simpkins.
(03/11/2021 Added to Collection HOR-Exp by John Simpkins.
(03/11/2021 Collection HOR-Exp removed by John Simpkins.
(03/11/2021 Added to Collection HOR-Fin by John Simpkins.
(93/11/2021 Collection HOR-Fin removed by John Simpkins.I
Foltsu Restricted —Intemal Use Ony 3 ©2021 FUITsU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Peak - important fields FUJITSU
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 most readers. This will need more thought when Peaks are raised.
Management should amend this during weekly clean-ups (careful to preserve links where raised in another system)
Impact - tab and free form field to articulate impact, status and next steps so it is easy to understand for anyone. This now uses a
context sensitive table which needs to be maintained (for HDR Peaks weekly) es: eel
Non-HDR -> HDR ->
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 a is taken
ion or ensuring acti
= Product Group and Product - We need to know the part of the system that the Live Defect relates to for reporting and quality purposes
Fojtsu Restricted
ternal Use On 32 ©2021 FUITsU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Peak updates - Internal & External
™ When adding Progress to a ‘bonded’ Peak, the — Jam es ater ae
default response option is ‘- Progress Only’ and I
this does NOT flow back to TfSNow “i
NOTE - but it would be visible if we were asked to
provide a copy of the Peak as the POF feature takes
ALL content
™ Ifyou select a Response Category then any text
you add at the same time WILL flow back to
TfSNow if the Peak is ‘bonded’
™ No References are sent to TfSNow for ‘bonded’
Peak, so all Documents, Baselines, KBs, and Peak
references can be added for Fujitsu only access
Foltsu Restricted —Intemal Use Ony 3
(© 2021 FUINTSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
us further quality data
allowing their exclusion from reporting:
Peak — Root Cause & Response Category
Root Cause - we need to know what type of fix was needed, which when matched to the part of the system affect
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 defec’s and hence
eps Ctguy SFA
ce Ato ed
ayn Categny 20a
agomeCateny StF ocvetaen cae Cane
‘apne Catgany fF taanener Rms
poe tegen 96 Frl-slidentevieee
pons Ctegay 6 Fl ropa Approve Fackegured
espe Categey 64
espns Categany 9? —Fa—Unpacted nscn ece
Foltsu Restricted —Intemal Use Ony
34
(© 2021 FUINTSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Peak Cloning FUJITSU
= Cloning
= when clones are created you will be asked for a reason and this will be captured in the cloned Peak. Selecting "Create a
Defect Peak’ will auto set the Call Type on the clone to “#”
You will also be asked to update the Summary so the description is unique and appropriate
= Clones now carry forward many more fields (such as Collections, Reference, Workaround, and Release Mgt meeting
fields)
ae [bsesai-nee-2001 ovro0:90 revrlabn Slankin
[Overocate Fo TN it
aes
See fee] [pete:: 2015 15:52:
lett pcazeases opened
Seas
Toss Restrited ternal Ue On % ©7021 FUN
© FUJITSU 2021
FUJ00232847
FUJ00232847
Peak - No Fault Found
Response Category — 100 ~ Final
Response Category — 120 ~ Final
Response Category - 200 Final
Response Category —63 ~ Final ~I
Response Category — 66 ~ Final -
Response Category —68 ~ Final
Response Category 72 ~ Final I
Response Category —94 ~ Final ~
Response Category 95 ~ Final
Response Category 96 ~ Final I
Response Category —97 ~ Final
Response Category —98 ~ Final ~
No fut in product
Programme Approved —No Fx Required
Ennancement Request
Administrative Response
Duplicate Cal
‘Advice and guidance given
Advice after Investigation
Insufficient evidence
Unspectied inautiient evidence
User error
~ Route call to TS
~ Goned to create Defect Peak
~ Call withdrawn by user
FUJITSU
These Peak field values mean No Fault Found and will cause Peaks to be excluded when counts
are done of defects and progress on investigations into defects (see SVM/SDM/PRO/0875):
Response Category — 62 ~ Final —
TESNow may well then
show a defect
assigned to a different
Resolver Group ~ but it
has ceased to be
something to track in
Peak
Foltsu Restricted —Intemal Use Ony
36
(© 2021 FUINTSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Fujirsu
shaping tomorrow with you
Changes for Test
Fojtsy Restricted —Interal Use On 37 ©2021 FUITSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Small changes for Test FUJITSU
@ 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 has been tested and is awaiting release
38 © 2021 FUINSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Improvements for Release Management
Fojtsy Restricted —Interal Use On 39
©2021 FUITSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Hotfixes FUJITSU
@ Hotfixes are a mini release and will use the new 3-node release numbering xx.yy.zz where
the primary 2 nodes are the release that they relate to and the third node is the hotfix
number
@ Ifa release has gone Live, then any Peaks which require a hotfix should NOT be Targeted A
the master release, but at a hotfix release. For example:
™ Ifthe master release was 20.94, any hot fixes have their own release 20.94.01, 20.94.02 ... 20.94.1
and so on
m Ifthe master release was 71.10, any hot fixes for this would be 71.10.01, followed by 71.10.02 and so
on.
@ Ifa hotfix is needed, Release Management will create the hotfix release in Peak with its own
set of dates, so that it can be properly tracked
™ Any peaks that are not urgent, and therefore not a hotfix, should go to BIF/PTF for release via
the Maintenance Release process
Foltsu Restricted —Intemal Use Ony 0 © 2021 FUITSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Maintenance Releases FUJITSU
@ Maintenance Releases allow all Live Defects to have a route to Live
@ If a Live Defect cannot be added to an existing release, a new
Maintenance Release will be created using a release model that Release
Management will own
@ The release model has template deployment schedules for all types of
Distribution Group covering the point of cut off for inclusion, through
development, testing and release
@ Maintenance Releases will carry as many Live Defects as they can and will
be presented to Demand Planning for POL agreement/re-prioritisation
a © 2021 FUINSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
Updated RELEASE MG
™ 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)
@ This will be maintained by the
applicable chairs for BIF, CBIF and
PTF
FUJITSU
Foltsu Restricted —Intemal Use Ony
2
©2021 FUITSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
BIF - Managed through Peak FUJITSU
= The BIF chair must record, in Peak on the Release Mgt tab, what decisions are
made
™ 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 BIF
minutes
If the Peak is approved at BIF then the BIFApproved Collection must be added
{also for BIFRejected)
= 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
a © 2021 FUITSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
CBIF - Managed through Peak FUJITSU
@ If BIF has determined that a Peak needs to go to CBIF
then at least one of the check boxes on the Release Mgt
@ If a Peak is to be taken to CBIF, then the CBIF proposal
form must be completed as this is what will be shared
with POL for it to make its decision
Foltsu Restricted —Intemal Use Ony 4a ©2021 FUITsU
© FUJITSU 2021
FUJ00232847
FUJ00232847
PTF - Managed through Peak FUJITSU
™ The PTF chair must record, in Peak on the Release Mgt tab,
what decisions are made
@ The new PTF date fields (Initial and Completed) will need to
be completed during, or after, the PTF meeting (not before...
or it will affect status reporting)
= Initial date - will hold the date of the first PTF the Peak
was first presented at - this value should not change
™ Completed date - will hold the last PTF meeting the
Peak was discussed at - this value will change if the
Peak is iteratively presented for review and it will allow
reporting on what was reviewed at the last PTF meeting
™ The outcome of PTF discussions should be added to the PTF
text box on the Release Mgt tab. A concise note is all that
is needed. No need for separate PTF minutes
Foltsu Restricted —Intemal Use Ony 45 ©2021 FUITsU
© FUJITSU 2021
FUJ00232847
FUJ00232847
All releases show Planned Dates FUJITSU
@ In addition, Release Managers will also maintain the key dates that
reflect the deployment to Live of a release
= Central updates of these fields by Release Management will be
propagated to all Peaks linked to the release to allow status tracking and
reporting
Planned Dates (DDMMYYYY) ‘Actual Dates DDMMIYYYY)
Our Development l
(Out Integration J
Into LST
OuLsT I
Into Production I i}
46 © 2021 FUINSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
7 T Getieaaea I
FUJITSU
Reporting
ey (© 2021 FUINTSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
a I
POA internal monthly reporting FUJITSU
@ MAC team create a view of all Live Defects on a monthly basis
Tee Affecting Defects
Foltsu Restricted —Intemal Use Ony 8 ©2021 FUITsU
© FUJITSU 2021
FUJ00232847
FUJ00232847
= aa
POA Executive reporting FUJITSU
ott amy
™@ Aview of progress month to month forms part of the DE reporting
pack (example slide)
@ Total increased by 1, Branch Affecting increased by 1
™ Considerable majority now Targeted At a release
Live Defects Branch Affecting Live Defects ‘
+ INVESTIGATING ve Detect actual potenti tl ing need Mayor may na be Live Defect te xsaa. a
‘© SOLUTIONING- confirmed Le Defects where the slitin is being inti for agreement bythe techwical teams tesa
* PROPOSED FOR - the solution is confirmed, and a suitable release has been proposed (subject to further validation - typically counter releases) =
¢ TARGETED AT- tho ich» etd lose though which tle deployed. Avan doplymant tes
8 ©2021 FUND
© FUJITSU 2021
FUJ00232847
FUJ00232847
== al
POL HDR Reporting FUJITSU
@ Aweekly report of all HDR Defects is shared and discussed with POL
=a 7
®@ Deferred & Project HDR Defects are also shared - but not currently discussed
a os)
52
aw
Foltsu Restricted —Interal Use Ony 50 (© 2021 FUINTSU
© FUJITSU 2021
FUJ00232847
FUJ00232847
2)
FUJITSU
shaping tomorrow with you
Copyright 2011 FUJITSU