POL00458014
POL00458014
WORKING DRAFT
POST
OFFICE
POL00458014
POL00458014
WORKING DRAFT
Contents
Accenture conducted a
diagnostic review of the Post O1 Executive Summary 3
Office SPM Programme in
Autumn 2023. 02 Context 9
This report contains the 03 Findings & Recommendations Summary 14
observations and
recommendations of this O04 Appendix 28
diagnostic.
> @ Copyright © 2023 Accenture. All rights reserved. 2
POL00458014
4
O1I
EXECUTIVE SUMMARY
> Cae Copyright © 2023 Accenture. All rights reserved. 3
POL00458014
POL00458014
WORKING DRAFT
EXECUTIVE SUMMARY I EXECUTIVESUMMARY I
Post Office Limited (POL) commissioned an independent diagnostic review of its Strategic Platform Modernisation (SPM) Programme in Autumn 2023, given
significant delays and cost overruns.
The diagnostic has found that:
* The purpose of the SPM programme (to replace the Horizon platform) is sound, removing functional and commercial dependence on an end-of-life core
system whilst providing a flexible platform to enable future retail initiatives. There is some misalignment amongst stakeholders regarding the specific scope of
the programme, which is being addressed
+ The technology architecture is fit for purpose, based on modern technologies that will scale to support future products and services, however some critical
remediation activities have been identified. The technical build is well underway, with a live service (Drop & Collect) and an NBIT Pilot already delivered and
well received by both the business and Postmasters
+ However, SPM is suffering in delivery execution and, without a change in course, will fail:
- POL does not have the required internal experience to lead and deliver a large-scale IT transformation like SPM (despite assigning some capable colleagues to
the programme)
~ The current delivery model is not channelling POL’s capability in a way that will deliver the programme at pace
~ Delivery team morale is low - people don’t feel equipped to deliver a programme of this importance
Based on the findings of this diagnostic and Accenture’s experience we recommend resetting the programme to:
> Clarify vision and revalidate current scope - through scope guiding principles clearly linked back to the overall programme vision
> Engage an experienced IT and Change Transformation delivery partner — define a delivery model enabled by external transformation expertise whilst building
POL’s internal capability
> Agree delivery method, organisation and governance - with clear business sponsorship and streamlined forums
> Re-plan and re-cost the programme to next logical stage - including a t-shirt sized estimate based on the chosen delivery model and method
> Embed data-driven management and decisioning - from GE, through SteerCo and delegated to lower levels to allow the programme to move at pace
>
Re-energise your teams and stakeholders - cascade a consistent vision and plan, address ways of working, and maintain comms across and beyond the
programme
> Implement tech remediation plan - with consistent standards across environments, security and modern engineering approaches
> Embed business change and support into programme - empower teams to identify, design and deliver the right interventions for stakeholders and BAU
> @ Copyright © 2023 Accenture. All rights reserved. 4
KEY OBSERVATIONS
POL00458014
POLO0458014
WORKING DRAFT
THE PROGRAMME HAS SOME GOOD FOUNDATIONS BUT SIGNIFICANT CHALLENGES EXIST
Y Deliveredalive
service and pilot
that have been
wellreceived
v Progressed
Horizon
replacement
objectives further
than any attempt
prior to 2021
v Implemented
remediation
actions
recognising that
programmeis
challenged, and
delivery is at risk
e.g., by bringing in
IT transformation
skills & leadership,
and by conducting
this independent
diagnostic review
>@
Robust scope guiding principles are not in place leading to inconsistent scope translation from the vision
Post Office is playing the ‘integrator’ role internally despite limited complex IT delivery capability
Delivery methodology is not fit-for-purpose constraining ability to deliver solution and manage business change with confidence
Governance has been ineffective given some unclear accountabilities and inconsistent adherence to RACI
Frequent amendments to timelines and cost forecasts have led to concerns around delivery confidence
Limited data-driven reporting on programme progress has prevented the ability to detect issues early
Culture has been a key blocker for overall success impacting team morale and impeding collaboration
Tech solution has been built on a modern and stable architecture but requires some critical remediation and consistent rollout
Change and deployment teams have been brought together but it is not yet clear how they will be embedded into delivery
Copyright © 2023 Accenture. All rights reserved
KEY RECOMMENDATIONS
POL00458014
POL00458014
WORKING DRAFT
OUR KEY RECOMMENDATIONS DIRECTLY ADDRESS THE KEY OBSERVATIONS
KEY OBSERVATIONS
A
Robust scope guiding principles are not in place leading to inconsistent
scope translation from the vision
Post Office is playing the ‘integrator’ role internally despite limited
complex IT delivery capability
Delivery methodology is not fit-for-purpose constraining ability to
deliver solution and manage business change with confidence
Governance has been ineffective given some unclear accountabilities
and inconsistent adherence to RACI
Frequent amendments to timelines and cost forecasts have led to
concerns around delivery confidence
Limited data-driven reporting on programme progress has prevented
the ability to detect issues early
Culture has been a key blocker for overall success impacting team
morale and impeding collaboration
Tech solution has been built on a modern and stable architecture but
requires some critical remediation and consistent rollout
Change and deployment teams have been brought together but it is not
yet clear how they will be embedded into delivery
>@
KEY RECOMMENDATIONS
Clarify vision and revalidate current scope - through scope guiding principles clearly linked
back to the overall programme vision
Engage an experienced IT and Change Transformation delivery partner - define a delivery
model enabled by external transformation expertise whilst building POL’s internal capability
Agree delivery method, organisation and governance - with clear business sponsorship and
streamlined forums
Re-plan and re-cost the programme tonext logical stage - including a t-shirt sized estimate
based on the chosen delivery model and method
Embed data-driven management and decisioning - from GE, through SteerCo and delegated
to lower levels to allow the programme to move at pace
Re-energise your teams and stakeholders - cascade a consistent vision and plan, address
ways of working, and maintain comms across and beyond the programme
Implement tech remediation plan - with consistent standards across environments, security
and modern engineering approaches
Embed business change and support into programme - empower teams to identify, design
and deliver the right interventions for stakeholders and BAU
Copyright © 2023 Accenture. All rights reserved. 6
POL00458014
POL00458014
WORKING DRAFT
SUMMARY RECOMMENDATIONS I EXECUTIVE SUMMARY I
THE KEY RECOMMENDATIONS ARE AN AGGREGATION OF SPECIFIC ACTIVITIES
& SUMMARY RECOMMENDATIONS @
(8) Clarify Horizon \(4) Communicate
) Setup Reset 2) Develop Scope HIpaniacement Final Build vs. Buy
revalidate scope [ie Guiding Principles 1B
U *}\scope Decision
bac cdaivee 5) Evaluate Prog. )'6) Select & 17) Refine Vendor
ahucrite Me IDelivery & Support I:Onboard Delivery !IManagement
: Model" ____)iPartner** ZNapproach___)
(y MMMMMRREEREEE Wrote” _sPatney
2 a 6) Operationalise FiO) Review fil) Redefine (i3) Rationalise (14) Improve (iS) Re-establish
© pepeitduanieell [Programme Org I{9)DefinerAc! I [Delivery Workforce 12) Embed Forums & Technology & Solution Change
$< org & governance . Processes & Tools , .
= Structure Methodologies _}IStrategy Ceremonies Change Planning _}IControls
a .
ao @& y : (7) Re-baseline _ (18) Re-baseline
z Rerplan Brose tO) Revise Ee Programme Benefits & Future
w Prog! 9 Delivery Costs TCO
= Data-driven 19) Embed Data- 20) Test & Iterate }(21) Establish
o¥a management & led Insights & Assurance Benefits & Cost
[Sym decisioning Reporting Approach Management
Ww
a G =
ERR [oe Sg (23) Programme
Til & stakeholders ‘d gran Kick-off
u Ways of Working
(24) Estimate & 25) Deliver (26) Establish the
Implement tech ionic Remediation Platform 27) Introduce
balibeeliebaneblaealal (Remediation Plant )\ltemst Engineering Team 9 SP
eT eRe we (28) Consolidate & (29) Reset Comms ») 31) integrate
CEL rettgme [Refresh Change II& Engagement —_II30) Design TOM __IIDeployment
eee (Strategy & Plan _ J (Delivery Support Approach
“Delivery Model decision impacts subsequent recommendations. “*if applicable. *Some of these activities are currently progressing as part of ‘Build Better’ initiative.
> @ ActionsKey I I Action TBC Copyright © 2023 Accenture. All rights reserved. 7
POL00458014
POL00458014
WORKING DRAFT
SUMMARY RECOMMENDATIONS EXECUTIVE SUMMARY
THE KEY RECOMMENDATIONS ARE AN AGGREGATION OF SPECIFIC ACTIVITIES
© SUMMARY RECOMMENDATIONS @
2) Develop Scope Guicling Principles: Re-
establish strategic direction (incl. success
metrics) and reset scope guiding principles
3) Clarify Horizon Replacement Scope: Identify and communicate'like- (4) Communicate Final Build vs. Buy Decision:
for-like’ vs. process improvement scope for horizon replacement, I Agree path forward for Build vs. Buy decision and
ensuring clear traceability from vision to implementation (e.g., HU/CHJ) _) I_ establish auditable documentation as necessary
Clarify vision & 1) Set up Reset Team: Formation
of programme team to own and
embed the programme reset
5) Evaluate Programme Delivery & Support Model*: Agree suitability and
approach to onboarding a 3" party delivery partner to substitute and/or expand
existing capabilities. Includes designing TOM principles
Engage delivery
partner selection process and onboard relevant delivery partner. Ensure clear vendor management process (e.g., include contract
6) Select & Onboard Delivery Partner’; Complete partner I 7) Refine Vendor Management Approach: Re-establish
that they inform overall delivery approach clauses to ensure knowledge transfer)
8) Operationatise \ (9) DefineRACI: \( 10)Review Delivery) (11) Redefine ) (12) Embed Processes & (13) Rationalise Forums) (14) improve 15) Re-establish
Programme Org Agree RACland II Methodologies: I Workforce Strategy: II Tools: Agree, adapt and I & Ceremonies: Refine Technology & Change Solution Change
wo Structure: ensure I Agree programme II Understand existing II embed appropriate I forums and Planning: Revise Controls: Re
Fm Delivery Complete on accountabilitie II wide delivery II programme II processes and supporting II ceremonies in line integrated tech and establish
Foye method. oras going sareadhered II methodology(e.g.. II capability, mapto II toolsto manage I with agreed delivery change planning programme change
$< governance programme org toacrossthe II _ version of Agile) and I programme II programme delivery and I approach, approach (incl. clear management
E structure programme II howitwillbeadapted II requirementsand II solution development I programme estimation, processes (2.9., TDA,
a discussions and (e.g., structures I} forprogrammeneeds II define resource II consistently and effectively II processes, org, forecasting and including refinement
a set up roles of escalation) _) I &POL(eg., waterfall) _} I management plan _} \_across delivery lifecycle (( structure and RACI dependency mapping) _} I_of low-level designs)
é Re-plan & re- 16) Revise E2E Programme Plan: Revise, estimate and 17) Re-baseline Programme Delivery Costs: Re-baseline 18) Re-baseline Benefits & Future TCO: Calculate holistic benefits (e.g., efficiency
costthe integrate tech and change plans across scope, timeline, programme costs, based on scope, E2E programme plan and gains, CSAT etc.), link at high level to delivery stage gates and re-estimate future
FAME programme delivery stage gates etc. agreed delivery methodology total cost ownership
= ; arr
Fo Data-driven 19} Embed Data-fed Insights & Reporting: Agree and embed (20) Test & iterate Assurance Approach: Review and update KPIs & 21) Establish Benefits & Cost Management: Re-establish
PEPE management & proposed programme Assurance approach (e.g., Assurance I processes to consistently track and report delivery progress in line with programme cost monitoring and extend/embed ongoing
ri decisioning Universe). Iterate and refine as needed (programme vision benefits management
4
> 22) identify & Agree Programme Ways of Working: Identify and agree desired top-line programme behaviours and ways of I { 23) Programme Kick-off: Kick-off programme (e.g., through an away day) with relevant
if working to be embedded and enforced within teams e.g., to encourage transparency, collaboration and empowerment I I_ stakeholders to energise and motivate for programme restart
x
implement took 24) Estimate & Prioritise Remediation Plant: 25) Deliver Rernediation Iterns*: Deliver the Build Better I 26) Establish the Platform Engineering Team: Setup a \ (— 27) Introduce Harcening Sprints:
eee Develop a prioritised plan to address identified remediation recommendations, plus newly identified I I team that oreates, standardises and maintains the Include ongoing effort (& budget) to
“i issues by estimating required resources, costs, II recommendations, in a consistent, mandated way across all_II underlying platform and tooling that supports I I stabilise the code base at regular
Pt and timeframes delivery squads } \ engineering intervals
Embed business 28) Consolidate & Refresh Change Strategy & Plan: Validate} (29) Reset Comms & Engagement Delivery: (30) Design TOM: Complete } (31) integrate Deployment Support Approa
change & and update change strategy for the E2E programme and Re-define programme comms and I development of holistic and integrated I I Integrate current business and tech related
supportinto ‘execute activities in line with revised tech delivery ‘engagement strategy for all impacted II BaU target operating model, including deployment support plans and teams e.g., ROC ~
programme timelines incl. change impact, comms, learning stakeholders (in and outside the programme) _) \ Horizon transition state planning } \. Retail Operations Centre - previously defined in RTP
*Delivery Model decision impacts subsequent recommendations. **If applicable. tSome of these activities are currently progressing as part of ‘Build Better’ initiative.
> @ Copyright © 2023 Accenture. All rights reserved. 8
POL00458014
POL00458014
WORKING DRAFT
ILLUSTRATIVE ROADMAP I EXECUTIVESUMMARY I
ESTABLISH A DEDICATED “RESET TEAM” TO DRIVE THE RECOMMENDATIONS AND RELAUNCH BY MARCH ‘24
@ RELAUNCH PROGRAMME
Complete NOW (by 15 Dec '23) Complete NEXT (by 15 Feb ‘24) Complete LATER (by 31 Mar ‘24)
oS —
Clarify vision & 2) Develop Scope 3) Clarify Horizon fgs
revalidate scope Guiding Principles Replacement Scope 833
5
6) Evaluat ESS, Seeeeesseses ,t (7) Refine Vend
valuate 3 H ‘efine Vendor
Engage delivery Programme Delivery 3 Ea 16) elect & Onboard H Management
partner, (& Support Model” iy yr 4 Approach
o 8) Operationalise
Zz Programme Org 19) Define RACI wy Redefine
fq Delivery method, Structure jorkforce Strategy
Pall org & governance — - —
> HO) Review Delivery 12) Embed Processes} {'3) Rationalise x I [4 Improve 15) Re-establish
q £ I IMethodologies la Tools Forums & 6 I [Technology & Solution Change
a § aI (Ceremonies % I (change Planning Controls
2 © 3
wi Saint &re-cost 3 ig) Revise EE >) (i7) Re-baseline ® (18) Re-baseline
Pi the programme & Programme Plan Programme Delivery E I [Benefits & Future
Ss 2 Costs s I {co
oJy Data-driven & 3
foyq management & o 19) Embed Data-led_I I20) Test & Iterate = I I21) Establish Benefits
iil decisioning = Insights & Reporting I [Assurance Approach @ I I& Cost Management
4
bell Re-energise teams (22) Identify & Agree
lvl & stakeholders Programme Ways of
Working
Implement tech 4) Estimate & ; 6) Establish the
diation pl Prioritise Remediation 25) Deliver Platform 27) Introduce
remediation plan Remediation Itemst Hardening Sprints
Plant Engineering Team N
Embed business (28) Consolidate & ) (29) Reset Comms & ; 31) Integrate
change & support Refresh Change Engagement 30) Design TOM Deployment Support,
into programme (Strategy & Plan Delivery 4 Approach
*Delivery Model decision impact
> @ Actions Key
subsequent recommendations. **if applicable. Some of these activities are currently progressing as part of ‘Build Better’ initiative.
Action TBC Copyright © 2023 Accenture. All rights reserved. 9
POL00458014
4
02 I CONTEXT
> Gos Copyright © 2023 Accenture. All rights reserved. 10
POL00458014
POL00458014
WORKING DRAFT
INTRODUCTION
BACKGROUND
* Post Office Limited (POL) commissioned an independent diagnostic review of its Strategic Platform Modernisation (SPM) Programme, given
significant delays and cost overruns, which have led to a recent ramp down across the Programme
* Accenture has conducted this programme diagnostic review over seven weeks, providing an end-to-end view of positive features and
challenges, as well as tangible recommendations to set the programme back on track
* This report summarises the outputs of Accenture’s programme diagnostic findings and recommendations
CONTEXT
* This diagnostic has been conducted by an Accenture review team that is independent to those Accenture resources engaged in the SPM
programme delivery
+ The diagnostic review has been completed over a relatively short time frame (seven weeks), with additional focus on the areas requiring
significant intervention and recommendations that will best position the programme for success
+ Five Level 1 capabilities or ‘Towers’ have been assessed to provide a holistic programme view: Strategy, Governance, People, Solution and
Implementation. Against each Level 1, a set of Level 2 and Level 3 capabilities were defined to guide this diagnostic review based on
Accenture or industry standard frameworks
* Observations and diagnostic RAGs - indicating the level of intervention required - have been derived through stakeholder interviews and
artefact review, based on materials made available to the review team by POL
+ Key decisions have been made in parallel to this diagnostic review (e.g., RTP brought back together with STP in week 5). Where possible the
diagnostic team has accurately reflected the changing state of the programme
+ Many of the recommendations outlined in this document require further decisions to be made by POL (e.g. delivery model, methodology)
before they can be fully implemented within the programme
> @ Copyright © 2023 Accenture. All rights reserved "
POL00458014
POL00458014
WORKING DRAFT
SCOPE & APPROACH
OVER SEVEN WEEKS, WE HAVE INTERVIEWED A CROSS SECTION OF THE SPM POPULATION AND ASSESSED A
WIDE RANGE OF ARTEFACTS TO INFORM THIS DIAGNOSTIC REVIEW
Mobilise: 1 week
Fieldwork: 4 weeks Reporting: 2 weeks
_ MOBILISE
+ Stakeholder Interviews (Phase 2) : Ay
+ Gather Artefacts + Artefact Review + Tooling Access & Data Analysis feyeeck ndings &
oa ; at 7 Recommendations
Confirm Stakeholders & Plan Initial Interviews (Phase 1) Ding: Benen + Produce Final Output
STRATEGY
GOVERNANCE
a 166 89 c.500 91
Interviews Individuals Artefacts Survey
SOLUTION Conducted
IMPLEMENTATION
Engaged* Reviewed** Responses
*Across GE, STP/RTP leadership, business change, 3rd parties, and technical delivery. **Includes artefacts provided by POL, additional interviewee material, and live content within programme tools, e.g., JIRA, Confluence and ServiceNow,
> @ Copyright © 2023 Accenture. All rights reserved
12
SOURCE LIST
DETAILED VIEW OF STAKEHOLDERS ENGAGED AND ARTEFACTS REVIEWED THROUGH THE DIAGNOSTIC REVIEW
We have engaged a
broad group of
stakeholders of all
levels working
across the SPM
Programme
This includes:
General Executive
Programme Leadership
Programme Management
Technical Delivery
Engineering
Architecture
Product Management
Stakeholder Engagement
Change Management
Assurance
Security
Retail Operations
89 INTERVIEWEES*
Abigail McGeever
Ajay Patel
Amit Dandekar
Andrew Kingham
Andy McAllister
Anne-Marie Hearne
Barry Johns
Ben Marsh
Ben Owens
Brian Jones
Chris Darriet-Jones
Christo Caratossidis
Claire Hurrell
Clare Mapes
Colin Moore
Dan Perrin
Daniel Wood
David Gemmell
David Steed
Davyd Nash
Dipesh Chandegra
Ed Harris
Ed Spencer
Emily Robinson
Emma Jones
Fiona Burns
Gareth Clark
George Cross
Greg Lewis
Hema Kanani
lan Bilclough
Jane Kidd
Jeff Mak
Karen Cleary
Kate Kay
Kathryn Sherratt
Kathryn Wearne
Kelly Goodwin
Kelly Metcalfe
Lauren Brogden
Lee Hosford
Liam Carroll
Luke Bailey
Mark Elmslie
Mark Nash
Marnus Marx
Martin Roberts .
Matt Walton .
Mayuresh Sane .
Mel Park .
Melissa Gribben .
Michelle Stainsby .
Mike Braithwaite .
Natalie Cross .
Natasha Gowardun +
Nick Ravenscroft .
Nicola Marriott .
Nik Gill .
Nikki Savekar .
Nirmal Radhakrishnan +
Owen Woodley .
Paul Minchell .
Pete Marsh .
Phil Newton .
Praveen Bhujade .
Reuan Williams .
Rob Guest
Rob Wilkins
Ryan Allan
Ryan Jones
Richard James
Rob Fry
Sam Jeyakumar
Samantha Swann
Sarah Gray
Shelley Genery
Simon Pearson
Sophie Drury
Steve Hepburn
Steve McFarlane
Steve Young
Stuart Banfield
Sue Saikia
Thomas Maddern
Tim McInnes
Vinay Swali
will Jenkins
Yogesha Ramanna
Zdravko Mladenov
POL00458014
POL00458014
WORKING DRAFT
500
ARTEFACTS
Alongside
interviews, an
extensive list of
artefacts were
provided by Post
Office for review as
part of the
engagement. The
review has
additionally
included live
content captured
within programme
tools such as
Confluence, Jira,
and Service Now
“Interviewees based on a list provided by POL, following a role-based ask from the diagnostic team. Also includes additional interviewees identified during the diagnostic review. Every effort has been made to engage the appropriate
subject-matter experts and gather insights from a representative group across all areas and levels but, due to timescales, it was not feasible to interview every stakeholder across STP/RTP within SPM.
>@
Copyright © 2023 Accenture. All rights reserved. 13
POL00458014
POL00458014
03 I SUMMARY
OBSERVATIONS &
RECOMMENDATIONS
Copyright © 2023 Accenture. Allrightsreserved. 14
DIAGNOSTIC METHODOLOGY
AN END-TO-END REVIEW ACROSS THE FIVE MAJOR CAPABILITIES REQUIRED FOR SUCCESSFUL DELIVERY
POL00458014
POL00458014
WORKING DRAFT
> Using a Level 1-3 framework, detailed > Each Level 3 has received a
observations have been captured following diagnostic RAG from which an
quantitative (artefact and data analysis) and overall Level 2 diagnostic RAG
qualitative review (interviews, surveys) has been derived
> Where a capability requires intervention,
recommendations, have been captured (see
appendix) and form the basis for the summary
recommendations outlined
GOVERNANCE PEOPLE SOLUTION IMPLEMENTATION
STRATEGY
LEVEL2 CAPABILITY
1.1 Strategic Intent
1.2 Business Case
Economics
1.3 Stakeholder Alignment
1.4 Scope & Requirements
1.5 Sequencing &
Prioritisation
1.6 Delivery Model
1.7 Target Operating Model
LEVEL 2 CAPABILITY
2.1 Planning
2.2 Reporting, KPIs &
Metrics
2.3 Prog Organisation,
Authorities & Forums
2.4 Change Control
2.5 Commercial & Contract
Management
2.6 Resource Management
2.7 Vendor Management
NOTE: See Appendix for further detail on the diagnostic methodology.
>@
LEVEL 2 CAPABILITY
3.1 Change Strategy
3.2 Change Execution
3.3 Stakeholder
Engagement & Comms
3.4 Culture & Behaviours
3.5 Skills & Competencies
3.6 Learning & Training
LEVEL 2 CAPABILITY
4.1 Operations Capability
4.2 Solution Architecture
4.3 DevSecOps &
Environments
4.4 Non-Functional
Requirements
4.5 Data
4.6 Code
4.7 Infrastructure
LEVEL 2 CAPABILITY
5.1 Design
5.2 Build
5.3 Testing
5.4 Release Mgmt. &
Deployment
5.5 Conversion
5.6 Post Go Live Support
5.7 Service Introduction
Copyright © 2023 Accenture. All rights reserved. 15
POL00458014
POL00458014
WORKING DRAFT
SUMMARY OBSERVATIONS RAG RATING
14 “LEVEL 2” CAPABILITIES ASSESSED AS RED - WHERE SIGNIFICANT INTERVENTION IS RECOMMENDED
LEVEL 2 CAPABILITY RAG RATING
STRATEGY GOVERNANCE
LEVEL2 CAPABILITY LEVEL 2CAPABILITY
2.1 Planning
2.2 Reporti
1.1 Strategic Intent
1.2 Busines:
Economics Met
2.3 Prog Organisation,
Authorities & Forums
NOTE: See Appendix for observations per Level 1 capability and the diagnostic methodology.
> @ RAG Definitions i I Significant interventions recommended
Moderate interventions recommended
PEOPLE
LEVEL2 CAPABILITY
3.3 Stakeholder
Engagement & Comms
SOLUTION IMPLEMENTATION
LEVEL 2 CAPABILITY LEVEL 2 CAPABILITY
Deployment
4.3 DevSecOps &
Environments
4.4 Non-Functional
Requirements
imited or no interventions recommended —_ Copyright © 2023 Accenture. Alll rights reserved. 16
POL00458014
POL00458014
WORKING DRAFT
FROM SUMMARY TO KEY OBSERVATIONS
THESE LEVEL 2 CAPABILITY “RED” RATINGS ARE EXPLAINED THROUGH NINE KEY OBSERVATIONS
KEY OBSERVATIONS OF LEVEL 2 CAPABILITY RED RATING Robust scope guiding principles are not in
A place leading to inconsistent scope translation
from the vision
Post Office is playing the ‘integrator’ role
B__ internally despite limited complex IT delivery
capability
Delivery methodology is not fit-for-purpose
C constraining ability to deliver solution and
manage business change with confidence
Governance has been ineffective given some
D_ unclear accountabilities and inconsistent
adherence to RACI
Frequent amendments to timelines and cost
E forecasts have led to concerns around delivery
a4 Non Functi confidence
Requirements A i Limited data-driven reporting on programme
F progress has prevented the ability to detect
issues early
Culture has been a key blocker for overall
G success impacting team morale and impeding
collaboration
Tech solution has been built on a modern and
H_ stable arch. but requires some critical
remediation and consistent rollout
Change and deployment teams have been
evosgnsengpu vex cenoneaygvengn yn] gy eevee yrregvOnETURLPTUSUPOT EL IOTHETOnORUOREROTaERETOE NEO ENA HET TESETD PUES PEENRETTOSSROOEL AUPE POT OEP ONOOLERIOLET RHETT 1 brought together but it is not yet clear how they
seeaeen seen en : will be embedded into delivery
NOTE: See Appendix for observations per Level 1 capability and the diagnostic methodology.
> @ RAG & Observation Definition Ez
ignificant interventions recommended oO Key observation Copyright © 2023 Accenture. All rights reserved. ”
POL00458014
POLO0458014
WORKING DRAFT
KEY OBSERVATIONS & RECOMMENDATIONS
OUR KEY RECOMMENDATIONS DIRECTLY ADDRESS THE KEY OBSERVATIONS
KEY OBSERVATIONS
A
Robust scope guiding principles are not in place leading to inconsistent
scope translation from the vision
Post Office is playing the ‘integrator’ role internally despite limited
complex IT delivery capability
Delivery methodology is not fit-for-purpose constraining ability to
deliver solution and manage business change with confidence
Governance has been ineffective given some unclear accountabilities
and inconsistent adherence to RACI
Frequent amendments to timelines and cost forecasts have led to
concerns around delivery confidence
Limited data-driven reporting on programme progress has prevented
the ability to detect issues early
Culture has been a key blocker for overall success impacting team
morale and impeding collaboration
Tech solution has been built on a modern and stable architecture but
requires some critical remediation and consistent rollout
Change and deployment teams have been brought together but it is not
yet clear how they will be embedded into delivery
>@
KEY RECOMMENDATIONS
Clarify vision and revalidate current scope - through scope guiding principles clearly linked
back to the overall programme vision
Engage an experienced IT and Change Transformation delivery partner - define a delivery
model enabled by external transformation expertise whilst building POL’s internal capability
Agree delivery method, organisation and governance - with clear business sponsorship and
streamlined forums
Re-plan and re-cost the programme tonext logical stage - including a t-shirt sized estimate
based on the chosen delivery model and method
Embed data-driven management and decisioning - from GE, through SteerCo and delegated
to lower levels to allow the programme to move at pace
Re-energise your teams and stakeholders - cascade a consistent vision and plan, address
ways of working, and maintain comms across and beyond the programme
Implement tech remediation plan - with consistent standards across environments, security
and modern engineering approaches
Embed business change and support into programme - empower teams to identify, design
and deliver the right interventions for stakeholders and BAU
Copyright © 2023 Accenture. All rights reserved. 18
POL00458014
POL00458014
WORKING DRAFT
THE KEY RECOMMENDATIONS ARE AN AGGREGATION OF SPECIFIC ACTIVITIES
& SUMMARY RECOMMENDATIONS @
(3) Clarify Horizon \(4) Communicate
) Setup Reset 2) Develop Scope HIpaniacement Final Build vs. Buy
revalidate scope [ie Guiding Principles II 1B
U *}\scope Decision
bac cdaivee 5) Evaluate Prog. )'6) Select® 17) Refine Vendor
ahucrite Bae I Delivery & Support ItOnboard Delivery 1]Management
Lis Model* \Partner** 1\Approach
o Model? ____sPartner“* eapproach____)
2 a 6) Operationalise FiO) Review fil) Redefine (i3) Rationalise (14) Improve (iS) Re-establish
© pepeitduanieell [Programme Org I{9)DefinerAc! I [Delivery Workforce 12) Embed Forums & Technology & Solution Change
IM org & governance Ii . Processes & Tools , .
= tructure Methodologies _}IStrategy Ceremonies Change Planning _}IControls
a .
F} Re-plan&re-cost [[OReueeaa Posen’ Be) Re-aseline
iu the programme Programme Plan Delivery Costs TCO
bm Data-driven 9) Embed Data-}{20) Test &Iterate (21) Establish
o¥a management & led Insights & Assurance Benefits & Cost
[Sym decisioning Reporting Approach Management
Ww
G =
= Re-energise teams I haaaatn em I OLR
Til & stakeholders We gran Kick-off
u ays of Working
(24) Estimate & 25) Deliver (26) Establish the
Implomenttech Hgaaues Remediation Platform 27) Introduce
bhalineeiahbellmeailel (Remediation Plant }\ltemst Engineering Team J ((arcening Spr
eT Tee eM (28) Consolidate & (29) Reset Comms ») 31) integrate
CEE retical [Refresh Change II& Engagement —_II30) Design TOM __IIDeployment
eee (Strategy & Plan _ J (Delivery Support Approach
“Delivery Model decision impacts subsequent recommendations. *“*if applicable. *Some of these activities are currently progressing as part of ‘Build Better’ initiative.
> @ ActionsKey I I Action TBC Copyright © 2023 Accenture. All rights reserved. 19
POL00458014
POL00458014
WORKING DRAFT
RECOMMENDATIONS SUMMARY DETAIL
THE KEY RECOMMENDATIONS ARE AN AGGREGATION OF SPECIFIC ACTIVITIES
e SUMMARY RECOMMENDATIONS @
Clarify vision & 4) Set up Reset Team: Formation) {- 2) Develop Scope Guiding Principles: Re- 3) Clarify Horizon Replacement Scope: Identify and communicate ‘like-) (4) Communicate Final Build vs. Buy Decision
of programmeteamto ownand II establish strategic direction (incl. success for-like’ vs. process improvement scope for horizon replacement, Agree path forward for Build vs. Buy decision and
embed the programme reset, (metrics) and reset scope guiding principles} I_ ensuring clear traceability from vision to implementation (e.g., HL/CL)) _} I_ establish auditable documentation as necessary
a dot 5) Evaluate Programme Delivery & Support Model": Agree suitability and 6) Select & Onioard Delivery Partner**: Complete partner { 7) Refine Vendor Management Approach: Re-establish
arttier ” approach to onboarding a 3" party delivery partner to substitute and/or expand selection process and onboard relevant delivery partner. Ensure clear venclor management process (e.g., include contract
lg existing capabilities. Includes designing TOM principles that they inform overall delivery approach Clauses to ensure knowledge transfer)
8) Operationatise \ (9) DefineRACI: \( 10)Review Delivery) (11) Redefine ) (12) Embed Processes & (73) Rationalise Forums ) (14) improve 15) Re-establish
Programme Org Agree RACland II Methodologies: Workforce Strategy: II Tools: Agree, adapt and I & Ceremonies: Refine Technology & Change Solution Change
wo Structure: ensure I Agree programme Understand existing II embed appropriate I forums and Planning: Revise Controls: Re
Fm Delivery Complete on accountabilitie II wide delivery II programme II processes and supporting II ceremonies in line integrated tech and establish
Loy method ora going sareadhered II methodology(e.g.. II capability, mapto II tools tomanage I with agreed delivery change planning programme change
$< governance programme org toacrossthe II _ version of Agile) and I programme II programme delivery and I approach, approach (incl. clear management
E structure programme II howitwillbeadapted II requirementsand II solution development I programme estimation, processes (2.9., TDA,
a discussions and (eg, structures II forprogrammeneeds II define resource II consistently and effectively II processes, org, forecasting and including refinement
a set up roles of escalation) _) I &POL(eg., waterfall) _} I management plan _} \_across delivery lifecycle (( structure and RACI dependency mapping) _} I_of low-level designs)
é Re-plan&re- 16) Revise E2E Programme Plan: Revise, estimate and 17) Re-baseline Programme Delivery Costs: Re-baseline 18) Re-baseline Benefits & Future TCO: Calculate holistic benefits (e.g., efficiency
costthe integrate tech and change plans across scope, timeline, programme costs, based on scope, E2E programme plan and gains, CSAT etc.), link at high level to delivery stage gates and re-estimate future
FAME programme delivery stage gates etc. agreed delivery methodology total cost ownership
Fo Data-driven 19} Embed Data-fed Insights & Reporting: Agree and embed (20) Test & Iterate Assurance Approach: Review and update KPIs & 21) Establish Benefits & Cost Management: Re-establish
PEPE management & proposed programme Assurance approach (e.g.,. Assurance I processes to consistently track and report delivery progress in line with programme cost monitoring and extend/embed ongoing
ri decisioning Universe). Iterate and refine as needed (programme vision benefits management
= if
> 22) identify & Agree Programme Ways of Working: Identify and agree desired top-line programme behaviours and ways of I { 23) Programme Kick-off: Kick-off programme (e.g., through an away day) with relevant
working to be embedded and enforced within teams e.g., to encourage transparency, collaboration and empowerment stakeholders to energise and motivate for programme restart
I IE stakeholders {
t4
ey 24) Estimate & Prioritise Remediation Plant: 25} Deliver Remediation Items": Deliver the Build Better 26) Establish the Platform Engineering Team: Setup a \ (— 27) Introduce Harcening Sprints:
eee Develop a prioritised plan to address identified I} remediation recommendations, plus newly identified team that creates, standardises and maintains the Include ongoing effort (& budget) to
“i issues by estimating required resources, costs, II recommendations, in a consistent, mandated way across all_II underlying platform and tooling that supports stabilise the code base at regular
Pt and timeframes delivery squads } \ engineering intervals
Embed business 28) Consolidate & Refresh Change Strategy & Plan: Validate} (- 29) Reset Comms & Engagement Delivery: I {- 30) Design TOM: Complete 31) Integrate Deployment Support Approa
change& and update change strategy for the E2E programme and Re-define programme comms and I development of holistic and integrated I I Integrate current business and tech related
aupportinto execute activities in ine with revised tech delivery engagement strategy for all impacted I} BaU target operating model, including deployment support plans and teams e.g., ROC ~
programme timelines incl. change impact, comms, learning stakeholders (in and outside the programme) _) \_ Horizon transition state planning Retail Operations Centre - previously defined in RTP
“Delivery Model decision impacts subsequent recommendations. **If applicable. *Some of these activities are currently progressing as part of ‘Build Better’ initiative.
> @ Copyright © 2023 Accenture. All rights reserved. 20
POL00458014
POL00458014
WORKING DRAFT
SUMMARY RECOMMENDATION (1/8)
CLARIFY VISION & REVALIDATE SCOPE
KEY OBSERVATION KEY RECOMMENDATION
Clarify vision and revalidate current scope - through scope guiding principles clearly linked
back to the overall programme vision
Robust scope guiding principles are not in place leading to inconsistent
A. scope translation from the vision
Summary Recommendation High-level Description Complete Strategy Gov. People Solution Impl.
Formation of programme team to own and embed the programme
1) Set up Reset Team roast Now - - . - .
2) Develop Scope Guiding _ Re-establish strategic direction (incl. success metrics) and reset scope
Principles guiding principles Now x x x x
Identify and communicate ‘like-for-like’ vs. process improvement
scope for horizon replacement, ensuring clear traceability from vision Now x x x
to implementation (e.g., HIJ/CU)
3) Clarify Horizon
Replacement Scope
4) Communicate Final Build Agree path forward for Build vs. Buy decision and establish auditable
vs. Buy Decision documentation as necessary Now - - - - .
NOTE: See Appendix for detailed recommendations per Level 1 capability and how these map back to summary recommendations.
> @ Complete Definitions Now Complete by 15 Dec ‘23 Next Complete by 15 Feb ‘24 Later Complete by 31 Mar ‘24 Copyright © 2023 Accenture. All rights reserved. a
POL00458014
POL00458014
WORKING DRAFT
SUMMARY RECOMMENDATION (2/8)
ENGAGE DELIVERY PARTNER
KEY OBSERVATION
Post Office is playing the ‘integrator’ role internally despite limited
B complex 't delivery capability
Summary Recommendation
5) Evaluate Programme
Delivery & Support Model*
6) Select & Onboard Delivery
Partner**
7) Refine Vendor
Management Approach
KEY RECOMMENDATION
High-level Description
Agree suitability and approach to onboarding a 3 party delivery
partner to substitute and/or expand existing capabilities. Includes
designing TOM principles
Complete partner selection process and onboard relevant delivery
partner. Ensure that they inform overall delivery approach
Re-establish clear vendor management process (e.g. include contract
clauses to ensure knowledge transfer)
Complete
Now
Next
Later
Engage an experienced IT and Change Transformation delivery partner - define a delivery
model enabled by external transformation expertise whilst building POL’s internal capability
Strategy Gov. People Solution Impl.
x x
x
x
NOTE: See Appendix for detailed recommendations per Level 1 capability and how these map back to summary recommendations. *Delivery Model decision impacts subsequent recommendations. “If applicable.
> ED compleredetiniions Now Complete by 15 Dec ‘23 Next Complete by 15 Feb ‘24 Later Complet
31 Mar ‘24
Copyright © 2023 Accenture. All rights reserved 22
POL00458014
POLO0458014
WORKING DRAFT
SUMMARY RECOMMENDATION (3/8)
DELIVERY METHOD, ORGANISATION & GOVERNANCE
KEY OBSERVATION
C__ Delivery methodology is not fit-for-purpose constraining ability to
deliver solution and manage business change with confidence
KEY RECOMMENDATION
D Governance has been ineffective given some unclear accountabilities
and inconsistent adherence to RACI
Summary Recommendation
8) Operationalise
Programme Org Structure
9) Define RACI
10) Review Delivery
Methodologies
11) Redefine Workforce
Strategy
12) Embed Processes & Tools
13) Rationalise Forums &
Ceremonies
14) Improve Technology &
Change Planning
15) Re-establish Solution
Change Controls
High-level Description
Complete on-going programme org structure discussions and set up
roles
Agree RACI and ensure accountabilities are adhered to across the
programme (e.g., structures of escalation)
Agree programme wide delivery methodology (e.g., version of Agile)
and how it will be adapted for programme needs & POL (e.g., waterfall)
Understand existing programme capability, map to programme
requirements and define resource management plan
Agree, adapt and embed appropriate processes and supporting tools
to manage programme delivery and solution development consistently Next
and effectively across delivery lifecycle
Refine forums and ceremonies in line with agreed delivery approach,
programme processes, org structure and RACI
Revise integrated tech and change planning approach (incl. clear
estimation, forecasting and dependency mapping)
Re-establish programme change management processes (e.g., TDA,
including refinement of low-level designs)
Complete
Now
Now
low
Next
Next
Later
Later
NOTE: See Appendix for detailed recommendations per Level 1 capability and how these map back to summary recommendations.
> @ Complete Definitions Now Complete by 15 Dec ‘23 Next
Complete by 15 Feb ‘24
Later Complete by 31 Mar ‘24
Strategy Gov. People Solution Impl.
x x
x I x iF aa x
x x x
x x x
x x x x
x x x
x x
x x
Copyright © 2023 Accenture. All rights reserved
Agree delivery method, organisation and governance - with clear business sponsorship and
streamlined forums
POL00458014
POL00458014
WORKING DRAFT
SUMMARY RECOMMENDATION (4/8)
RE-PLAN & RE-COST THE PROGRAMME
KEY OBSERVATION
E Frequent amendments to timelines and cost forecasts have led to
concerns around delivery confidence
KEY RECOMMENDATION
Summary Recommendation High-level Description
16) Revise E2E Programme
Plan
17) Re-baseline Programme
Delivery Costs
18) Re-baseline Benefits &
Future TCO
NOTE: See Appendix for detailed recommendations per Level 1 capability and how these map back to summary recommendations.
> @ Complete Definitions Now Complete by 15 Dec ‘23 Next Complete by 15 Feb ‘24
Revise, estimate and integrate tech and change plans across scope,
timeline, delivery stage gates etc.
Re-baseline programme costs, based on scope, E2E programme plan
and agreed delivery methodology
Calculate holistic benefits (e.g., efficiency gains, CSAT etc.), link at
high level to delivery stage gates and re-estimate future total cost
ownership
Complete
Next
Next
Later
Later Complete by 31 Mar ‘24
Re-plan and re-cost the programme to next logical stage - including a t-shirt sized estimate
based on the chosen delivery model and method
Strategy Gov. People Solution Impl.
x x x
x x
x x x x
Copyright © 2023 Accenture. All rights reserved 24
POL00458014
POL00458014
WORKING DRAFT
SUMMARY RECOMMENDATION (5/8)
DATA-DRIVEN MANAGEMENT & DECISIONING
KEY OBSERVATION KEY RECOMMENDATION
Embed data-driven management and decisioning - from GE, through SteerCo and delegated
Limited data-driven reporting on programme progress has prevented
F to lower levels to allow the programme to move at pace
the ability to detect issues early
Summary Recommendation High-level Description Complete Strategy Gov. People Solution Impl.
19) Embed Data-led Insights Agree and embed proposed Assurance approach (e.g., Assurance
4 seh " Next x x x
& Reporting Universe), within programme. Iterate and refine as needed
20) Test & Iterate Assurance _ Review and update KPIs & processes to consistently track and report
‘ in It a "i Next x x
Approach delivery progress in line with programme vision
21) Establish Benefits & Cost Re-establish programme cost monitoring and extend/embed ongoing
Later x x x x
Management benefits management
NOTE: See Appendix for detailed recommendations per Level 1 capability and how these map back to summary recommendations.
> @ Complete Definitions Now Complete by 15 Dec ‘23 Next Complete by 15 Feb ‘24 Later Complete by 31 Mar ‘24 Copyright © 2023 Accenture. All rights reserved.
8
POL00458014
POL00458014
WORKING DRAFT
SUMMARY RECOMMENDATION (6/8)
RE-ENERGISE TEAMS & STAKEHOLDERS
KEY OBSERVATION KEY RECOMMENDATION
Re-energise your teams and stakeholders - cascade a consistent vision and plan, address
Culture has been a key blocker for overall success impacting team
G ways of working, and maintain comms across and beyond the programme
morale and impeding collaboration
Summary Recommendation High-level Description Complete Strategy Gov. People Solution Impl.
Identify and agree desired top-line programme behaviours and ways of
working to be embedded and enforced within teams e.g., to encourage Now x x x x
transparency, collaboration and empowerment
22) Identify & Agree
Programme Ways of Working
Kick-off programme (e.g., through an away day) with relevant
23) Programme Kick-off stakeholders to energise and motivate for programme restart
Later x
NOTE: See Appendix for detailed recommendations per Level 1 capability and how these map back to summary recommendations.
> @ Complete Definitions Now Complete by 15 Dec ‘23 Next Complete by 15 Feb ‘24 Later Complete by 31 Mar ‘24 Copyright © 2023 Accenture. All rights reserved. 26
SUMMARY RECOMMENDATION (7/8)
IMPLEMENT TECH REMEDIATION PLAN
KEY OBSERVATION
Tech solution has been built on a modern and stable architecture but
H__ requires some critical remediation and consistent rollout
Action
24) Estimate & Prioriti:
Remediation Plan*
25) Deliver Remediation
Items*
26) Establish the Platform
Engineering Team
27) Introduce Hardening
Sprints
NoTI
> ED complerevetinitions Now Complete by 15 Dec ‘23 Next Complete by 15 Feb ‘24 Later Complete by 31 Mar ‘24
KEY RECOMMENDATION
High-level Description
Develop a prioritised plan to address identified issues by estimating
required resources, costs, and timeframes
Deliver the Build Better remediation recommendations, plus newly
identified recommendations, in a consistent, mandated way across all
delivery squads
Setup a team that creates, standardises and maintains the underlying
platform and tooling that supports engineering
Include ongoing effort (& budget) to stabilise the code base at regular
intervals
Complete
Now
Next
Next
Later
Strategy
Gov.
POL00458014
POL00458014
WORKING DRAFT
Implement tech remediation plan - with consistent standards across environments, security
and modern engineering approaches
People _ Solution Impl.
x x
x x
x
x
Appendix for detailed recommendations per Level 1 capability and how these map back to summary recommendations. *Some of these activities are currently being progressed as part of ‘Build Better’ initiative.
Copyright © 2023 Accenture. All rights reserved 2
POL00458014
POL00458014
WORKING DRAFT
SUMMARY RECOMMENDATION (8/8)
EMBED BUSINESS CHANGE & SUPPORT INTO PROGRAMME
KEY OBSERVATION
I__ Change and deployment teams have been brought together but its not
yet clear how they will be embedded into delivery
Summary Recommendation High-level Description
28) Consolidate & Refresh__ Validate and update change strategy for the E2E programme and
execute activities in line with revised tech delivery timelines incl. Next
change impact, comms, learning
Change Strategy & Plan
29) Reset Comms & Re-define programme comms and engagement strategy for all Next
Engagement Delivery impacted stakeholders (in and outside the programme)
30) Design TOM Complete development of holistic and integrated BAU target operating sea,
KEY RECOMMENDATION
model, including Horizon transition state planning
31) Integrate Deployment
Support Approach RIP
NOTE: See Appendix for detailed recommendations per Level 1 capability and how these map back to actions.
> @ Complete Definitions Now Complete by 15 Dec ‘23
Integrate current business and tech related deployment support plans
and teams e.g., ROC - Retail Operations Centre - previously defined in Later
Complete by 15 Feb ‘24
Embed business change and support into programme - empower teams to identify, design
and deliver the right interventions for stakeholders and BAU
Complete
Later Complete by 31 Mar ‘24
Strategy Gov. People Solution Impl.
x
x
x x
x
Copyright © 2023 Accenture. All rights reserved 28
POL00458014
04 I APPENDIX
I Methodology
Il Survey Results
Ill Review Detail (Per Tower)
IV Additional Supporting Evidence
Copyright © 2023 Accenture. Allrightsreserved. 29
POL00458014
POL00458014
WORKING DRAFT
II METHODOLOGY
> oot Copyright © 2023 Accenture. All rights reserved. 30
POL00458014
POL00458014
WORKING DRAFT
DETAILED APPROACH
METHODOLOGY, PROCESS, AND DELIVERABLES
METHODOLOGY
+ We have leveraged Accenture’s Programme Diagnostic Accelerator to conduct the diagnostic review, supported by Accenture’s Delivery Methodology
and informed by several tools, e.g., DevSecOps Maturity Framework, Agile Delivery Quality Assurance, as well as AWS Well-Architected Reviews
+ The Accelerator structures the diagnostic review into Level 1, Level 2, and Level 3 capabilities that are required for successful programme delivery
+ Detailed observations were identified through documentation review, data analysis, and qualitative data collection (e.g., interviews, surveys)
+ Each Level 3 capability received a diagnostic RAG rating based on the observations. This included identification of key areas for intervention. An overall
Level 2 diagnostic RAG has been derived based on the RAG and detailed observations within each of its Level 3 capabilities
+ Recommendations have been highlighted, and prioritisation suggested, for any Level 2 or Level 3 requiring intervention
Documentation
STEP 3- REPORT
PROCESS
We have followed these steps to Mobilisation & Information of Observations RAG for each Level Recommendations ‘Summary of
gather information, complete Pret ‘aration Gathering & for each Level 3 3 Capability, incl. for Mitigating Observations &
analysis, capture insights, and P Interviews Capability + Risk Identification Identified Risks Recommendations
identify recommendations: SMA input +SMA reviews
DELIVERABLES RECOMMENDATIONS
+ Asnapshot of observations & + Anexecutive summary,
recommendations
+ Detailed observations and
recommendations to reduce
overall risk by tower
>@
outlining key cross-cutting
themes and critical
recommendations to bring
the programme back on track
+ Where a Level 2 or Level 3 capability requires intervention, we
have prioritised recommendations by anticipated impact
+ Our recommendations bring industry expertise together with
insights from the team on the ground to provide clear options
that get to the heart of the challenges facing SPM
Copyright © 2023 Accenture. All rights reserved.
a
POL00458014
POL00458014
WORKING DRAFT
DIAGNOSTIC METHODOLOGY
AN END-TO-END REVIEW ACROSS THE FIVE MAJOR CAPABILITIES REQUIRED FOR SUCCESSFUL DELIVERY
> Using a Level 1-3 framework, detailed
observations have been captured following
quantitative (artefact and data analysis) and
qualitative review (interviews, surveys)
> Each Level 3 has received a
diagnostic RAG from which an
overall Level 2 diagnostic RAG
has been derived
> Where a capability requires intervention,
recommendations, prioritised by anticipated impact,
have been captured (see appendix) and form the
basis for the summary recommendations outlined
STRATEGY
LEVEL2 CAPABILITY
1.1 Strategic Intent
1.2 Business Case
Economics
1.3 Stakeholder Alignment
1.4 Scope & Requirements
1.5 Sequencing &
Prioritisation
1.6 Delivery Model
1.7 Target Operating Model
GOVERNANCE
LEVEL 2 CAPABILITY
2.1 Planning
2.2 Reporting, KPIs &
Metrics
2.3 Prog Organisation,
Authorities & Forums
2.4 Change Control
2.5 Commercial & Contract
Management
2.6 Resource Management
2.7 Vendor Management
PEOPLE
LEVEL 2 CAPABILITY
3.1 Change Strategy
3.2 Change Execution
3.3 Stakeholder
Engagement & Comms
3.4 Culture & Behaviours
3.5 Skills & Competencies
3.6 Learning & Training
SOLUTION
LEVEL 2 CAPABILITY
4.1 Operations Capability
4.2 Solution Architecture
4.3 DevSecOps &
Environments
4.4 Non-Functional
Requirements
4.5 Data
4.6 Code
4.7 Infrastructure
IMPLEMENTATION
LEVEL 2 CAPABILITY
5.1 Design
5.2 Build
5.3 Testing
5.4 Release Mgmt. &
Deployment
5.5 Conversion
5.6 Post Go Live Support
5.7 Service Introduction
Copyright © 2023 Accenture. All rights reserved 32
POL00458014
POL00458014
WORKING DRAFT
IlI SURVEY RESULTS
> & Copyright © 2028 Accenture. All rights reserved. 33
POL00458014
POL00458014
WORKING DRAFT
SPM DIAGNOSTIC REVIEW SURVEY
Background
As part of the independent diagnostic review of the Strategic Platform Modernisation (SPM) Programme, we conducted a survey to
gather more information and data that would feed into the final report.
Key information
* The survey was launched on Thursday 28 September 2023 and closed on 3 October 2023
* 91 participants completed the survey after being issued to a sample size of 200
* The responses collected remained intentionally anonymous to ensure confidentiality and to enable people to share their thoughts
and insights freely
* The survey enabled us to collect further quantitative as well as qualitative data from across all teams and levels within the
Programme
Participants responded to
1 the survey from a sample
size of 200
> @ Copyright © 2023 Accenture. All rights reserved. 34
POL00458014
POL00458014
WORKING DRAFT
Surve
SECTION 1: OBJECTIVE, VISION & DELIVERY Y
Responses
To what extent do you 2/1 4.5/1 1
agree with the 6. / 0 5/ 0 6.8/ 0
following statements? lam clear about what the The programme is effective lam proud of what the
programme objective is and at translating its vision and programme has delivered so
1 is completely disagree, 10 what that means for my team scope into delivery far
is completely agree
4 KEY QUOTES
If you scored any of the questions in this section at 3 or below, please explain why...
“The programme keeps changing its vision and “Incredibly proud of what my team has achieved in “In recent months the vision, direction,
scope on a whim so it would be disingenuous to say the time we have had and the issues we have had to communication and leadership of programme has
that it has translated any of that into proper deal with. Can't comment on other teams as their been confused and completely opaque. We all
delivery” activities are not shared across the programme” understand there have been uncertainties, but
leadership is about taking those uncertainties and
still providing the team with a clarity on vision and
direction together with clear communication”
“The vision is presented as to get rid of Horizon “I'm faced with almost weekly changes to direction
whilst not providing actual steps of how we are which do not feel like are roadmapped at all”
going to do that and when someone asks for that or
tries to help with this then it is discarded”
*Source: SPM Diagnostic Review Survey (28 September 2023)
> @ Copyright © 2023 Accenture. All rights reserved. 35
SURVEY RESULTS SUMMARY
POL00458014
POL00458014
WORKING DRAFT
91
SECTION 2: CULTURE Reanonves
To what extent do you
agree with the 6.2/ 10
following statements?
1 is completely disagree, 10
is completely agree
People across the
programme go out of their
way to help one another
4 KEY QUOTES
What do you like and what could be better about the culture of the SPM Programme?
“I think at an individual personal level, people
in the Programme are nice and good to
engage with. But I think so many pillar leads
seem to be ‘kings of their own kingdom’ and
are not really willing to align/collaborate well
with other areas”
“Like - my workstream working as a team
supporting each other to achieve milestones
Could be better - Cross working across
workstreams, less silo working”
*Source: SPM Diagnostic Review Survey (28 September 2023)
>@
“The culture within the programme is reflective of
the culture within the Post Office, there is an air of
cautiousness potentially driven by the enquiry
which leads to colleagues not taking accountability
or responsibility for tasks, decisions, sign offs etc.”
“I'd love to see more joined up calls where teams are
talking about how things can be delivered together,
how certain decisions/activities impact other areas and
need to be aligned for overall benefit (not just what's
best for one pillar)”
“Across the programme, collaboration has been good.
Between the business and the programme collaboration
has been extremely poor. At times I have felt that the
business has expected or wanted the programme to fail”
Copyright © 2023 Accenture. All rights reserved 36
SURVEY RESULTS SUMMARY
SECTION 3: LEADERSHIP AND COMMUNICATION
POL00458014
POL00458014
WORKING DRAFT
91
Survey
Responses
To what extent do you
agree with the
following statements?
1 is completely disagree, 10
is completely agree
4.5/10
I feel the programme is fully
supported and sponsored by
Post Office leadership
4.5/10
Ihave / my team has been
informed about programme
updates, timelines and status
ina timely manner
4 4 KEY QUOTES
If you scored any of the questions in this section at 3 or below, please explain why...
“My team still do not know how the changes will
impact us and how the team will look going forward. I
feel like the business is not keeping colleagues or
postmasters informed as to what is happening. As a
business it has been promised to be open and
transparent with us and Postmasters and I simply do
not feel this is happening”
“Leadership is not visible above the pillar leads”
*Source: SPM Diagnostic Review Survey (28 September 2023)
>@
“POL SLT are not behind this project
and this impacts on their teams
supporting it”
“It does not seem like there is a comms and engagement
plan for the programme, the timeliness and scheduling of
programme wide communication often seems ad-hoc in
nature”
“Poor comms around the downscaling, leaving my team
feeling excluded and undervalued”
Copyright © 2023 Accenture. All rights reserved a7
POL00458014
POL00458014
WORKING DRAFT
SURVEY RESULTS SUMMARY 91
SECTION 4: GENERAL FEEDBACK
Survey
Responses
KEY QUOTES
What works well and what could be better on the SPM Programme?
“The programme would benefit from increased
“There are pockets of real knowledge being applied logically communications, clarity around responsibilities and less
and for the good of the objective, but this is surrounded by bureaucratic Post Office processes”
vast resources that are not harnessed effectively and so
wasting time and money”
“Postmasters need to be more included,
and new opportunities to liaise with them
need to be identified. Communications are
becoming corporate replacing an approach . ;
“Things that could be better are culture, ways of working, based on strong trusting relationships” "Going forward I would suggest having away day /
messaging, collaboration, one team, one vision, one SPM” showcases / offsites to help build back the teams both
business and Tech to bring the programme together”
4 4 KEY QUOTES
What tools would help you to achieve success on the programme and what impact would they have on your role?
“Clear communication of release plans (including minor ; ; “Wellness or mental health tools would be of fantastic
releases). Open and honest communications throughout, "We don't need more tools. Potentially benefit during such an uncertain time. Having better
Programme org structure with clear ownership and within the engineering community specific management support too”
accountability” software / licenses may help. What we do
need is a change in the culture and WoW -
empowerment and trust of people to
deliver’ “I don't think tools are the problem, I think it's people,
“Collaboration tools - Miro, Monday, Lucid Chart” attitudes and communication issues that are the main
blockers”
*Source: SPM Diagnostic Review Survey (28 September 2023)
> @ Copyright © 2023 Accenture. All rights reserved. 38
POL00458014
POL00458014
WORKING DRAFT
Ill I REVIEW DETAIL (PER
TOWER)
> & Copyright © 2028 Accenture. All rights reserved. 39
POL00458014
POL00458014
WORKING DRAFT
11.1I STRATEGY REVIEW
DETAIL
Copyright © 2023 Accenture. Allrightsreserved. 40
SUMMARY OF OBSERVATIONS
STRATEGY LEVEL 2 AND LEVEL 3 CAPABILITY RAG RATINGS.
LEVEL 2 CAPABILITY
1.1 Strategic Inte
1.2 Business Case
Economics
> @ RAG Definitions i I Significant interventions recommended
Moderate interventions recommended
1.1.4 Programme Vision &
Strategic Pillars
1.2.1 Business Case
1.31 Strategy Alignment
I 1.4.1 Scope Definition &
I Refinement
I 15.1 Scope Prioritisation
POL00458014
POL00458014
WORKING DRAFT
STRATEGY
LEVEL 3 CAPABILITY
1.2 Success Metrics
efinition
2.2 Value Management
esponsibility Alignment +5 Delivery Alignment
4.2 Requirements 1.4.3 Requirements
1.4.4 Business
Traceability
Requirements Ownership
5.2 Delivery Sequer
1.6.1 Delivery
Methodology
1.6.2 Methodology
1.6.3 Methodology
Alignment
Execution
I 1.7.1 Target Operating
M
imited or no interventions recommended —_ Copyright © 2023 Accenture. Alll rights reserved. 4
OBSERVATIONS (1/5)
1.1 STRATEGIC INTENT, 1.2 BUSINESS CASE ECONOMICS
Level2
1.4 Strategic
Intent
1.2. Business
Case Economics
> @ RAG Definitions [Bf sioniicantincerventions recommended Moderate interventions recommended
Level 3
1.1.1 Programme
ision &
Strategic Pillars
1.2.2 Business
Case
Observation
Differing interpretations of the SPM
programme vision and lack of clear business
sponsorship has led to confusion at all levels
particularly around scope.
No clear articulation of success metrics tied to
delivery stage gate, preventing early
identification of issues and diagnosis of root
causes.
Programme cost forecasts have increased
significantly in the last 12 months (4.5x) raising
concerns around cost estimation robustness.
Benefits have not been tracked or managed
regularly preventing ability to assess value
delivery progress.
POL00458014
POL00458014
WORKING DRAFT
STRATEGY
Evidence (what we have seen and heard)
Differing interpretations of the programme vision have developed across stakeholders within the STP & RTP
programmes, and across the POL exec team. These range from like-for-like Horizon replacement to full retail
transformation.
RTP’s set up and naming (Retail “Transformation” Programme) has further propagated this confusion, as some
stakeholders have at times seen RTP as a wider transformation vehicle.
No single business sponsor across RTP & STP programme (until very recently when the programmes have been
brought together) hence no single source of truth and accountability when it comes to scope and vision
clarification.
Primary success metrics of the programme are related to number of sites and timelines i.e., to transition all
retail sites off Horizon by March 2025. No additional success metrics have been sized (e.g., efficiency
improvement, post-master CSAT, customer CSAT, etc.).
Missed opportunity to link releases (RI, R2...) to measurable outcomes through these success metrics, limiting
ability to provide interim confidence that solution will deliver stated benefits.
Cost forecasts have steeply increased from c.£180m (Sep’22) to c.£400m (Mar’23) and to
c. £850m (Jun’23). This is driven by - Tech Delivery (resource, timeline, scope increase), Horizon Extension, &
RTP. In comparison Horizon was delivered for c.£800m in 1990s.
Instances of ineffective resourcing assumptions exist (e.g., tech teams resource planning in R3 does not fully
address periods of inactivity which would be expected as teams await dependencies). c.£53m in additional
STP resource extension costs have been forecasted in latest Jun’23 cost forecasts.
Some scope trade-off / re-prioritisation decisions have been made (e.g., in R2) however overall scope de-
prioritisation has been limited (full Horizon capability required before roll-out).
Only IT-run and IT-change cost related benefits sized as part of the Sept’22 business case (up to c. £25m
reduction). This can only be assessed once full-scale deployment commences.
‘Benefits Register’ - which was defined as part of the programme and intended to track a broad range of
benefits beyond just IT cost ~ has not been regularly maintained or prioritised.
Limited or no interventions recommended —_ Copyright © 2023 Accenture. All rights reserved, 42
POL00458014
POL00458014
WORKING DRAFT
>
o
wi
=
C4
a
e
n
OBSERVATIONS (2/5)
1.3 STAKEHOLDER ALIGNMENT
Evidence (what we have seen and heard)
Observation
Level 3
Level2
Per 1.1, differing interpretations of the programme vision have developed across stakeholders - from like-for-
like Horizon replacement to full retail transformation.
The intent to merge RTP into STP had been originally stated within RTP’s vision documents, but not all
stakeholders are aware of this intent (across both RTP & STP), the timelines and the practicality of it merging
Inconsistent strategy & scope cascaded to
teams as a consequence of different
the two’
>
5
F
£
a
=
Multiple acronyms exists for the core platform (NBIT / SPM), and the programme /sub-programmes (SPMP, STP,
RTP) - further confusing definition articulation.
stakeholder interpretations of the vision.
lignment
Updates provided to POL leadership teams (outside the programme) have not been able to consistently surface
critical items (e.
., criticality of R2 delays only clear until H2’23).
Split accountability has created a lack of clarity on where decision-making authority sits.
Limited collaboration between STP and RTP as teams have not had the opportunity to engage with their
Accountability, roles and responsibilities
across STP and RTP unclear leading to
counterparts. Further, programme leadership comms have also fractured over recent months (e.g., only a
limited number of steering meetings attended by all key stakeholders) leading to a degree of divergence.
inconsistent decision making and duplication
Lack of engagement and collaboration has also led to duplication of effort in some instances with no clear
demarcation of roles and responsibilities between the two e.g., within training.
Within STP, processes have been established for the Postmaster Engagement team and some business SMEs to
provide input. However, processes for ongoing engagement have not been adequately adhered to leading to
delivery outputs that are misaligned with business intent, e.g., additional journey step introduced on
Postmasters stamps screen between R2 and R3.
Across STP and RTP, a SteerCo was set up for leadership teams to attend, however this has been sparingly
attended leading to limited collaboration and alignment (per 1.3.2).
collaborating effectively within and between
Business and technology stakeholders not
STP and RTP, leading to risk of delivery
misalignment
Limited collaboration with wider POL teams (e.g., limited resource and knowledge sharing between Horizon
and NBIT teams).
*The consolidation of RTP/STP into a single programme was announced w/c 18 Sep 2023 which was in parallel to this review. Review timescales have not allowed for the assessment of this consolidation to be evaluated.
> ED rcdotinivions i I ignificant interventions recommended
43
Copyright © 2023 Accenture. All rights reserved.
___ Limited or no interventions recommended,
Moderate interventions recommended
POL00458014
POL00458014
WORKING DRAFT
>
°
wi
=
C4
a
Ss
a
OBSERVATIONS (3/5)
1.4 SCOPE & REQUIREMENTS
Horizon complexities are not well understood; no central documentation of Horizon processes. Teams ‘reverse
engineer’ these processes limiting their ability to define scope (i.e., what is like-for-like). As a result, strategic
Poor hygiene (e.g., some high-level requirements stored outside Jira) makes it difficult to link what is delivered
to signed off business ask, impeding traceability.
R2 and R3. No rationale or audit trail has been provided for this decision and Postmaster engagement team do
Skills gap within teams as requirements are refined (e.g., lack of technical BAs) means the requirements are not
not recognise this as a requirement stated by their team.
sufficiently robust or meet the definition of ready for delivery.
Technical requirements and low-level designs are not consistently produced, creating a level of uncertainty in
how delivery teams should interpret or implement the requirements captured.
For example, per 1.3.3 an additional journey step has been introduced on Postmaster Stamps screen between
Not all business processes (e.g., branch back office) and impacted stakeholder groups (e.g., upstream clients
Within delivery teams, inconsistent adherence to best practices (e.g., Jira usage), driving lack of a clarity on
like WHSmith) have accountable owners leading to missed considerations.
RTP’s scope has been derived from STP timelines. RTP team have revised scope when timelines shifted (e.g.,
scope at a lower-level.
options (e.g., "Do Minimum” in Sep’22 biz case) are not representative of effort - evidenced by 4.5x cost
‘no regrets’ activities given R2 delays) but have had limited input into reprioritisation.
increases from Sep'22 to Jun’23 (per 1.2.2).
No guiding principles exist to enable teams to make decisions on what is in scope vs. what is out of scope
STP’s scope has been derived from the wider programme vision which remains unclear (as mentioned in 1.1).
specifically around degree of ‘process definition’ in instances where it is needed.
This has led to an inconsistency in understanding what needs to be delivered.
Limited visibility of how HIJ/CUJ recommendations are reflected in the requirements.
Evidence (what we have seen and heard)
©
2
&
2
fa
@
a
8
8
€
g
a
2
8
8
£
2
>
FS
3
8
3
°
8
sz
a
<
S
S
@
=
€
2g
Business requirements not being effectively
captured (quality and detail) and monitored
through to technology delivery leading to
Inconsistent traceability of delivery outputs
back to the business requirements.
accountability for business requirements.
s
g
g
2
a
3
&€
Es
D
£&
=
3
a
2
a
8
3
3
a
g
5
Zz
Not all processes have single point
misaligned outputs.
Observation
Level 3
irements:
Requirements
Ownership
Hi
3
&
§
a
<
+
Level2
44
Copyright © 2023 Accenture. All rights reserved.
Limited or no interventions recommended
Moderate interventions recommended
> ED rcdotinivions i I ignificant interventions recommended
OBSERVATIONS (4/5)
1.5 SEQUENCING & PRIORITISATION, 1.6 DELIVERY MODEL
Level2 Level3
1.6.1 Delivery
Methodok
1.6.2
Methodology
Alignment
1.6.3
Methodology
Execution
> ED rcdotinivions [Bf sioniicantincerventions recommended -
Observation
Major increase in recent scope between R2
and R3 has introduced significant delivery
and cost risk.
Agile delivery not sequenced based on
value and/or dependencies limiting re-
prioritisation ability in case of delays.
Friction in the combined agile and waterfall
delivery model has caused delivery
expectations to be missed e.g., preventing
early identification of solution quality
issues.
Overarching waterfall model driving
feature testing and limiting ability to realise
interim benefits through agile.
POL00458014
POL00458014
WORKING DRAFT
STRATEGY
Evidence (what we have seen and heard)
Moderate interventions recommended
Three primary releases stated (R1, R2, R3) which dictate the overall direction and prioritisation of scope delivery.
These are well socialised and understood across the programme.
Additional requirements have been provided by the business/retail teams recently for R3 which have contributed
to significant scope impact and ultimately cost/effort impact.
Although RTP is in the process of creating a wider deployment plan, it is unclear how this will be delivered in line
with the release schedule i.e., alongside or after R3.
No consistent scope prioritisation methodology is adopted or aligned across agile delivery teams e.g., no
indication of feature prioritisation based on value.
Dependencies across delivery teams are often not planned or managed effectively, at time only being identified
weeks or months later, leading to risk of significant delivery delays.
‘Change Excellence Framework’ not adopted instead only used as blueprint and highly customised, Multiple
delivery methods have emerged (by evolution, not by design) - started as small tech-led agile team but not
consistently reset for scaled delivery.
Overarching programme governance is waterfall.
Multiple tools (e.g., JIRA / agile / user stories and MSP / waterfall / milestone) which do not easily reconcile and
makes it logistically difficult to have full visibility.
Per 1.3 the siloed nature of STP and RTP means that although programme governance is managed using the same
methodology the execution of these differs.
A technology ‘Buy’ assessment has been conducted on multiple occasions, but there is limited documentation to
suggest that this option was completely de-prioritised in favour of ‘Build’
Even though features are delivered in an agile model, these all roll-up to a waterfall-based release model (R1, R2,
R3). Within this set up, scope items delivered in an agile fashion are all staggered until a release is ready rendering
prioritisation efforts within agile delivery to have limited purpose (per 1.5.2).
This also contributes to a risk that technology features are not appropriately tested for prolonged periods of time
(8-12 months), potentially compounding delays e.g., High number of defects noted in System Integration Testing
(SIT) and E2E testing (per 5.4.1).
Limited or no interventions recommended Copyright © 2023 Accenture. Alll rights reserved. 45
POL00458014
POL00458014
WORKING DRAFT
>
iY)
wi
=
<q
[=
=
o
OBSERVATIONS (5/5)
1.7 TARGET OPERATING MODEL
Evidence (what we have seen and heard)
Observation
Level 3
Level2
46
there isa
Copyright © 2023 Accenture. All rights reserved.
___ Limited or no interventions recommended
ATOM was not defined on the outset of the programme (typically expected as a business-led activity). This has
deployment is complete. However, these teams are exclusively comprised of independent contractors and if
they are transitioned as is, there is a risk that no explicit POL business interlock / permanent employee exists
No indication whether deployment teams (defined in both STP and RTP) will be transitioned to BAU once
within this structure.
now commenced as a separate business and IT activity. As STP and RTP are brought back together,
risk to delivery if business considerations are not prioritised appropriately.
Moderate interventions recommended
ommenced and is expected to guide future
Target operating model (TOM) definition has
rection.
c
di
> ED rcdotinivions [Bf sioniicantincerventions recommended /
RECOMMENDATIONS (1/3)
1.1 STRATEGIC INTENT, 1.2 BUSINESS CASE ECONOMICS
Level 2 Observation
1.1.1) Differing interpretations of the SPM
programme vision and lack of clear business
sponsorship has led to confusion at all levels
particularly around scope.
1.1.2) No clear articulation of success metrics tied
to delivery stage gate, preventing early
identification of issues and diagnosis of root
causes.
1.1Strategic Intent
1.2.1) Programme cost forecasts have increased
significantly in the last 12 months (4.5x) raising
concerns around cost estimation robustness.
1.2.2) Benefits have not been tracked or managed
regularly preventing ability to assess value
delivery progress.
1.2 Business Case Economics
“Vision workshop planned on October 16%
> ED rcdotinivions [Bf sioniicantincerventions recommended -
Preliminary Recommendation (for discussion)
1.1) Restate and align on the SPM Vision’: e.g., To replace Horizon, deliver
direct business benefits related to existing functionality and establish a flexible
platform for future retail transformation (to be delivered by separate programmes).
Rect.1B) Clarify long-term business sponsorship (e.g., one overarching business
sponsor).
Recl.1C) Agree scope guiding principles to translate vision into scope decisions.
Rec1.1D) Define a succinct set of high-level balance score-card KPls (delivery and
business deployment, financial, CSAT, team engagement etc.) and where possible
link to delivery stage gates.
Rec1.1E) Establish targets for KPls set and continuously track.
Rect.1F) Embed data-driven decision making across all levels e.g., through a
management information framework.
Rec1.2A) Reconfirm cost drivers across delivery, deployment and BAU/future-state.
Recf.2B) Re-baseline cost ranges (e.g., T-shirt sizes) against E2E cost drivers.
Rec1.2C) Update and confirm costs and contingencies for the next logical
programme phase (e.g., R3), to provide to relevant stakeholders (e.g., shareholders).
Rec1.2D) Re-baseline the programme business case (include non-cost related
benefits levers, link value outputs to delivery stage gates).
Rect.2E) Embed process and discipline for monitoring and tracking business case
delivery and cost.
Rec1.2F) Conduct ongoing value tracking and assurance through a Value
Management capability (e.g., set up by strengthening PMO capability).
Limited or no interventions recommended
Moderate interventions recommended
POL00458014
POL00458014
WORKING DRAFT
STRATEGY
‘Tower Proposed Mapping to
Priority Summary Rec.
Vv #2, #3,
v #9
(Underway)
v #2
#19
#19
#19
Vv #17
Vv #17
Vv #17
“8
#21
#21
Copyright © 2023 Accenture. All rights reserved 47
POL00458014
POL00458014
WORKING DRAFT
RECOMMENDATIONS (2/3)
1.3 STAKEHOLDER ALIGNMENT, 1.4 SCOPE & REQUIREMENTS
accountability for business requirements.
Level2 Observation Preliminary Recommendation (for discussion) Tower Proposed Mapping to Summary
Priority Rec.
____ 1.3.1) Inconsistent strategy & scope cascaded to. . ; Vv ‘
F 7 © I I teams.as.a consequence of different stakeholder R@Ct-3A) Combine STP / RTP under single SPM business sponsorship. (Underway) 8
_ € _ interpretations of the vision.
Bo: Rec1.3B) Define, agree and embed roles and responsibilities under a single Vv +
_ @ _ 1.3.2) Accountability, roles and responsibilities programme. (Underway)
_ @ _ across STP and RTP unclear leading to
3 _ inconsistent decision making and duplication of _ Ree1.8€) Relaunch the programme to drive buy in and energise programme #3
«£ —seeffort*. stakeholders e.g., workshops, away days, co-working sessions.
_ @ _ 1.3.3) Business and technology stakeholders not Ree1.3D) Reassess existing collaboration, communications and governance 2
oe collaborating effectively within and between STP processes to ensure ongoing alignment.
and RTP, leading to risk of delivery misalignment*.
I 4.4.4) No robust scope guiding principles are in. Ree14A) Translate and cascade revised vision to enable clear requirements and Vv +9
place leading to inconsistent scope translation scope throughout delivery.
9 __ ftom the vision.
-£ Rec1.4B) Embed Postmaster Engagement team more closely in the overall delivery wa
_ G __ 1.4.2) Business requirements not being effectively
- § _ captured (quality and detail) and monitored Rect.4C) Agree single tooling to provide traceability of scope and requirements “2
— § _ through to technology delivery leading to across the programme and to all stakeholders.
misaligned outputs.
=. tect. lentify and embed accountable business process owners to define an
5 Rec1.4D) identify and embed le bi define and Vv #9
8k monitor delivery of all applicable business requirements.
§ 1.4.3) inconsistent traceability of delivery outputs
_ @ back to the business requirements.
oe Rec1.4E) Identify and embed accountable owners for missing stakeholders if needed #9
_———s«'1,4,4) Not all processes have single point / where possible e.g., back office processes.
*The consolidation of RTP/STP into a single programme was announced w/c 18 Sep 2023 which was in parallel to this review. Review timescales have not allowed for the assessment of this consolidation to be evaluated.
> ED rcdotinivions i I
_ Limited or no interventions recommended —_ Copyright © 2023 Accenture. Alll rights reserved. 48
ignificant interventions recommended Moderate interventions recommended
POL00458014
POL00458014
WORKING DRAFT
RECOMMENDATIONS (3/3)
1.5 SEQUENCING & PRIORITISATION, 1.6 DELIVERY MODEL, 1.7 TARGET OPERATING MODEL
Level 2 Observation Preliminary Recommendation (for discussion) Tower Proposed Mapping to Summary
ae ; Rec1.5A) Evaluate the opportunity to phase releases between current R2 and R3
1.8.1) Major increase in recent scope between R2__hased on prioritised scope to drive quick wins, earlier benefits and manage delivery 14
and R3 has introduced significant delivery and ay.
cost risk.
Rec.5B) Revise the integrated SPM roadmap (both tech and deployment), linking “6
5.2) Agile delivery not sequenced based on delivery stage gates to value.
value and/or dependencies limiting re-
Prioritisation ability in case of delays. Rect.5C) Embed robust dependency management processes within delivery teams. m2
Rect.6A) Evaluate different agile methodologies and identify the most appropriate 0
1.6.1/2) Friction in the combined agile and ‘one for SPM context.
waterfall delivery model has caused delivery
expectations to be missed eS, preventing early Rec1.6B) Embed chosen agile approach consistently across SPM delivery teams. #10
identification of solution quality issues.
. it I. #
116.3) Overarching waterfall model driving feature R@&™8E) Review programme governance model based on chosen agile approach, 13
testing and limiting ability to realise interim
benefits through agile.
Rect.6D) Establish and agree structures on reconciling agile methodology with 0
wider POL portfolio requirements.
Rect.7A) Bring together existing TOM design work (across business and IT) ensuring #30
41.7.1) Target operating model (TOM) definition has _a single and integrated approach to TOM definition.
commenced and is expected to guide future
direction. Rect.7B) Reflect TOM considerations into programme design; ensure a business-led ‘s
> @ RAG Definitions i I Significant interventions recommended
approach.
Moderate interventions recommended
Limited or no interventions recommended
Copyright © 2023 Accenture. All rights reserved
POL00458014
POL00458014
WORKING DRAFT
111.2 I GOVERNANCE
REVIEW DETAIL
Copyright © 2023 Accenture. Allrightsreserved. 50
POL00458014
POL00458014
WORKING DRAFT
SUMMARY OF OBSERVATIONS I GOVERNANCE I
GOVERNANCE LEVEL 2 AND LEVEL 3 CAPABILITY RAG RATINGS.
LEVEL 3 CAPABILITY
LEVEL 2 CAPABILITY
2.4.1 Plan Definition I I 2.1.2 Programme 21.3 Tech Delivery s
: & Critical Path Pianning Pianning 21.4 Planning Tools
: 221 Status & 22.2 RAID
: 22 r e}
: Progress Processes & 22.3 Reporting 2.2.4 Reporting
i Reporting Management
H 8 sational 2.3.2 Programme 933 Assurance I 2.3.4 Design 2.3.5 RACI & H
i Srganisat Governance I Authority I [Decision-Making :
; 2.4.1 Delivery 2.4.2 Programme i
i Change Control Change
Change Contro} Management 1
: 381 :
i 25.1 Project 252 25.3 Total Cost of :
i Monscoment Subcontracting Ownership
2.6.1 Capacity 2.62 Team
Analysis Resourcing
H 2.7.1 Vendor
H Management
> @ RAG Definitions i I Significant interventions recommended Moderate interventions recommended Limited or no interventions recommended Copyright © 2023 Accenture. All rights reserved. 51
POL00458014
POL00458014
WORKING DRAFT
OBSERVATIONS (1/6) I GOVERNANCE _I
2.1 PLANNING
Level2 Level 3 Observation Evidence (what we have seen and heard)
+ Plan slipped -6 months for R2; timeline driven by immovable delivery date rather than rigorous delivery
estimates or detailed understanding of scope. Insufficient contingency to account for immaturity of POL
delivery capability.
Overly-ambitious timeline that had not been + _Lack of a constructive challenge culture in response to leadership delivery commitment - teams avoid raising
Definition & sufficiently challenged led to plan and critical concerns, pushing back on timelines, or offering an alternate timeline.
Critical Pay Path that did not reflect the delivery reality. Programme volatility; lack of confidence at working level that direction will not change again, e.g. change in
operating system, change(s) in delivery and UX partner, leadership rotation, split with RTP, and continued
investigation of the Buy option.
+ Historic disconnect between STP and RTP - while there is a programme plan for each area, a single joined-up
end-to-end plan for Horizon replacement has not yet been articulated.
There is no overarching end-to-end plan,
leading to cross-workstream dependencies
not being well-understood or managed.
+ Programme-level planning approach does not allow for flexibility in time or scope to manage for uncertainty in
delivery, creating friction between plans with cross-cutting dependencies.
+ Duplicative programme planning processes create friction with delivery team ways of working.
+ There is no consistency in team methodologies for planning, estimating, and sequencing; limited cross-team
ceremonies or forums at the working level to ensure alignment.
Inconsistent and disconnected planning
across teams, leading to a lack of clarity on
sequencing and accountability.
+ Dependencies to unlock another stream delivered after work that is less critical - historically much worse;
more recent joint planning exercises have been helpful (but are infrequent).
+ Unclear if Product Owners or Delivery Leads are the final decision-makers on sequencing.
+ Planning is labour intensive. Plans (LO, L1 milestones) are manually input into both SNOW and MSP, while
delivery is managed through JIRA; there is no tooling to bridge the gap, e.g. there is no mechanism to leverage
Tools do not support effective planning across data from work management tools to feed programme plans.
all SPM workstreams (business,
‘operations/BAU, IT). + Tools (e.g. JIRA) are used inconsistently and conventions (e.g. workflow, labelling, ticket hierarchy) are not
always enforced, creating poor quality data which limits credibility of plan.
2.1.4 Planning
Tools
> @ RAG Definitions [Bf sioniicantincerventions recommended . .
I Moderate interventions recommended —_Limited or no interventions recommended —_ Copyright © 2023 Accenture. Alll rights reserved. 52
POL00458014
POL00458014
WORKING DRAFT
OBSERVATIONS (2/6) I GOVERNANCE _I
2.2 REPORTING, KPIS, AND METRICS
Level2 Level 3 Observation Evidence (what we have seen and heard)
2.2 Reporting,
KP ls, & Metrics + Governance processes drive report production; reports are primarily narrative-based, rather than leveraging
data points and trends to derive insights and drive decision-making.
Reporting is focused on information over . .
insight which impairs swift decision-making. Labour intensive (significant dedicated capacity to produce) e.g. Board (PDB) papers 60+ pgs.
+ Siloed reporting lines (and content) expected to be addressed by activity currently underway to simplify
programme structure, governance, and reporting processes
+ Risks and issues are captured and escalated via reports, but resolution or decisions are slow.
+ Range of tools (SNOW, Excel, Confluence) used; sub-set of programme RAIDs captured in SNOW, but
RAID management is not incorporated into the
management tools are not used at a working level to manage actions or mitigations.
day-to-day management of the programme.
+ Dependency management within technical delivery has improved with use of JIRA ‘gets’ and ‘gives’ across
teams to support cross-team coordination.
+ Programme-level and working-level tools are not integrated; significant manual effort to transfer data between
systems, detracting capacity from delivery and problem resolution.
+ No investment in tools to extract programme-level data from management tools in an automated way, e.g. to
Tools do not support effective coordination or produce dashboards, though activity now in progress to mitigate.
data-driven decision-making across SPM
2.2.3 Reporting
Tools workstreams (business, operations/BAU, IT). + Fragmentation in initial set-up has led to inconsistent use of JIRA fields. Furthermore, gaps in JIRA skills mean
some could struggle to leverage metrics for actionable insight if data existed.
+ Inconsistent tooling between SPM Programme, SPM Tech Delivery, and RTP. While RTP aligned their tooling
and metrics (e.g. ERM) with CEF/SPO, SPM remains misaligned.
Data quality within JIRA is unreliable, making it difficult to measure progress or identify trends (e.g. limited use
4 of story points, inconsistent use of issue types, copying/cloning of tickets, linking of defects to epics). Some
Pee ets Meaningful KPis not consistently tracked over metrics exist, but are not consistent across teams and do not provide sufficient insight to consistently drive
Metrics time preventing early identification of issues. decision-making.
+ Reports reflect a ‘point in time’ narrative as robust data to identify trends is lacking.
> @ RAG Definitions [Bf sioniicantincerventions recommended -
I Moderate interventions recommended —_Limited or no interventions recommended —_ Copyright © 2023 Accenture. Alll rights reserved. 53
POL00458014
POL00458014
WORKING DRAFT
OBSERVATIONS (3/6) I _GoveRNANcE I
2.3 PROGRAMME ORGANISATION, AUTHORITIES, AND FORUMS
Level2 Level 3 Observation Evidence (what we have seen and heard)
2.3 Programme + Programme and tech delivery operated in parallel - rooted in technology-led history; siloes at the working level
Organisation, exacerbated gaps and duplication of roles across teams. A simplified programme structure is being developed
paedien] « 2.34 Structural issues with programme delivery to address many of the core challenges in this area.
Organisational organisation driving duplication of roles, high
aiicuire management vs delivery ratios and high costs. *_ ‘Historic “invisible wall’ between RTP and STP; no / very limited visibility of each other's work.
(continues on
next page)
+ There is a lack of regular cross-team ceremonies (e.g. scrum of scrums or ‘delivery sync’) for working-level
decisions; teams follow their own ways of working even within delivery
Historically, governance filled diaries (e.g. Programme Delivery Board 4+ hours) yet decision-making slow,
issues escalated to highest level, and governance replicated siloes seen in ways of working, e.g. programme
and technical delivery operating in parallel using different tooling.
‘Swing from previous overly-heavy siloed + Uncertainty during programme ramp down, but refreshed governance (e.g. reinstatement of SteerCo) is in the
PRR eetr a governance to insufficient levels (while process of being established.
Governance programme ramped down) which is still
perceived to be opaque.
Limited transparency; environment where governance is relied on for information-cascade, blurring the
objectives and purpose of the sessions and leading to over-attendance.
Cross-cutting forums (e.g. programme-level go/no go taking into account both technical readiness criteria and
business readiness criteria) do not appear to be in place.
Historically, internal assurance have had limited access to the programme. External reviews have been
completed (e.g. Deloitte, KPMG, Credera), though the majority of recommendations have not been
implemented into the programme.
This reflects wider gaps in group-level assurance; but a POL group-level integrated assurance approach is now
Insufficient internal and external assurance in being developed with immediate focus on SPM assurance universe.
place to monitor delivery progress & quality.
Limited visibility of how HlJ/CUJ findings are considered as not centrally tracked, e.g. ClJ findings referenced
ad hoc across supporting epic-level detail for Back Office.
+ While quality standards (e.g. engineering, architectural principles, requirements) are documented,
enforcement is limited. Technical initiatives (e.g. Build Better) are in place, but gaps in metrics and data quality
make it difficult to measure progress or confirm efficacy.
> @ RAG Definitions [Bf sioniicantincerventions recommended -
I Moderate interventions recommended —_Limited or no interventions recommended —_ Copyright © 2023 Accenture. Alll rights reserved. 54
POL00458014
POL00458014
WORKING DRAFT
OBSERVATIONS (4/6) I _ GOVERNANCE
2.3 PROGRAMME ORGANISATION, AUTHORITIES, AND FORUMS
Level2 Level 3 Observation Evidence (what we have seen and heard)
2.3 Programme
Organisation,
Authorities, &
Forums
(eonehided : + Asingle owner is not accountable for the overall functional and technical solution creating a gap between BDA
: and TDA; forums to feed the design boards are ad hoc / vary across streams.
BDA and TDA forums are in place, but
decision-making is disjointed without
sufficient buy-in.
+ TDA attendance inconsistent; at times decisions based on expediency (e.g. achieve milestone) rather than best
practice, leading to policy exception notes and a build-up of technical debt
+ BDAis the only forum for product-level conversations making it the only route for wider business visibility of
SPM which can create friction / detract from focus of this forum.
+ Programme-level RACI not defined nor reinforced by RACI at working level to make it clear who must be
consulted or engaged at each stage of the project lifecycle.
a + Limited empowerment pushes issues up management chain. Leads are confident resolving team-specific
Unclear accountabilities and lack of top-down issues, but cross-cutting issues are pushed into programme governance where individuals lack the technical
support impacting confidence and slowing expertise to make key decisions.
decision-making and issue resolution.
2.3.5 RACI &
Decision-Mal
+ Flat structure and ‘decision by committee’ made it difficult to reach consensus quickly.
+ If decisions made within delegated authority are reinforced by leadership, the right-sized programme structure
(activity underway) should simplify and clarify accountabilities.
o
&
__ Moderate interventions recommended
> @ RAG Definitions [Bf sioniicantincerventions recommended -
Limited or no interventions recommended Copyright © 2023 Accenture. All rights reserved.
POL00458014
POL00458014
WORKING DRAFT
Copyright © 2023 Accenture. All rights reserved.
Limited or no interventions recommended
reliance on external resources in key roles; this risks decisions being made that are not in long-term interests of
Fixed milestones and reactive approach to resourcing has accelerated depletion of funds against the original
POL and creating future continuity challenges.
business case.
Limited strategy for the future operation of the platform (approach to tooling, technical implementation, etc.)
technical decisions have not always been made with consideration to impact on ongoing maintenance of
‘simple’ changes being added directly to the backlog or made in flight, leading to breaking changes or delivery
system once programme is complete.
Granular technical design / platform scope decisions are not overtly part of change process, which can lead to
which is perceived to misalign to original business ask.
Change process incorporates delivery change impacting but tools for accurately and easily estimating impact
on delivery capacity remain immature (see 2.6).
Contractors not contractually incentivised to deliver successful programme outcomes despite availability of
Resourcing strategy (10% permanent, 25% subcontractor, 65% third party). Timeline pressure has increased
facility to contract on outcome-basis.
Change impact assessments conducted ad hoc and in fragmented way across STP and RTP; linked to limited
Relationship between change control within tech delivery and wider business is unclear, e.g. the impacts of
integration between wider POL business units and programme delivery.
Demand funnel used to manage change in tech delivery (based on June 2021 Horizon baseline).
milestone shifts or changes in functionality on downstream business units.
Cost forecasts have steeply increased from c.£180m (Sep’22) to c.£400m (Mar’23) and to
c. £850m (Jun’23). Driven by Tech Delivery (resource, timeline, scope increase) and RTP.
No FinOps capability to manage the variable spend model of the cloud solution.
Cost of future service is a secondary consideration in TDA decisions.
Evidence (what we have seen and heard)
ro
z
uw
3
<x
Zz
S
3)
a
5
ro) cB > © 36
$8 2 ce gg <
LS) B38 3 38 ce 2
2 D> cQ o> 2s
a2 gest P= 2 58
am ge Bee ae 5S 20
oe Sao 5D oe 28
- 85 338, 52 Zé
33 Sees x ge ou
3s 2£ESes 2 25 £3
es gE erse 5 52 cs
£ §ss £
1S) Fed ss2g 22 32 25
LO = 32 8555 22 8s ee
rT) 53 gree os es ze
“—s cr gse5 88 8 ge
338 gese as SE So
ze Ese . z25
“a 3 3% ogee £8 53 gee
2 e8s cE £3 ess
e 3 § on) ge Eo raz
Pd ro) 2 28 gsce ges ga £e
s go tel Bo Or ofe
1p Fa ot QEog gee ae 5g
2 3 gz eos ges a5 533
A 3 $3 SEs=s 86S 53 B28
33 EEfz 858 23 858
ne 3° 2s S565 z2s zs S35
oe) 2
4 E 3
2 8
gt a & § CE
2 e & Be
fo £05 3s
° & So Ee
3 3§ 9
[a4 1] 3 S35 Bo
[Fe a aO= as
2
=<
Mo «
t s
a 7
Moderate interventions recommended
> ED rcdotinivions i I ignificant interventions recommended
POL00458014
POL00458014
WORKING DRAFT
©
~
2
2)
z
o
_
<x
=
[4
Li
no
a
ie)
—_
2
i
=
Wi
e}
9
Zz
<
=
[a4
°
Qa
z
wi
>
Ss
N
E
2
i
=
ui
°
4
z
<x
=
uu
[S)
a
=]
°
n
ul
4
e
Nn
lence (what we have seen and heard)
€
s
$
6
F
°
Level 3
Level2
Mechanism for accurately sizing effort against delivery team capacity does not exist; estimates are a best
guess.
+ Weekly reviews in place to understand capacity at the team-level, but these are manual and not rooted in data
(e.g. lack of story points make it difficult to quantitatively measure velocity).
Limited mechanism for accurately estimating
delivery effort or team capacity leading to
z
Fe
3
BS
A
é
s
a
inaccurate plans.
Analysis
Singular focus on achieving committed timeline has impacted capacity for improvements; retrospectives not
consistently completed to refine and evolve estimating model (done ad hoc).
Reactive approach to resourcing in response to milestone pressure.
Historically delivery leads have (relatively easily) secured additional resource, with insufficient focus on blend
of teams or skill ratios (e.g. increasing developers without increasing QA) - created downstream issues and led
to over-sized teams which have been difficult to manage.
Historic rapid uncontrolled expansion strained
team capacity by creating a reactive
Programme has recently contracted; indicating a focus on controlling the resourcing position.
Composition of teams is a challenge - concentration of skilled / experienced resource in certain teams; Leads.
environment that was hard to manage.
are protective and made it difficult to repurpose resources to share knowledge and best practice in areas that
are struggling.
Inaccurate delivery estimates mean new teams previously stood up before key dependencies met (e.g. trying
to produce training before a training environment available).
& materials-based resource augmentation contracts. This could allow third party suppliers to passively accept
poorly defined requirements into delivery without concern for commercial impacts.
onshore/offshore split. However, this clear demarcation of responsibilities can also support risk management
Although there was a facility for outcome-based vendor contracts, the programme has primarily adopted time
by holding suppliers to account for what is fully within their control.
Limited experience within POL of delivering large scale technology programmes. Yet POL playing the
“integrator” role with various third parties which operate independently.
Concentrating suppliers in particular areas has reinforced siloes, particularly where there is an
Vendors not held to account for outcomes in
line with programme objectives or metrics.
87
Copyright © 2023 Accenture. All rights reserved.
Limited or no interventions recommended
Moderate interventions recommended
> ED rcdotinivions i I ignificant interventions recommended
RECOMMENDATIONS (1/5)
2.1 PLANNING
Level 2
> @ RAG Definitions [Bf sioniicantincerventions recommended -
Observation
2.1.1) Overly-ambitious timeline that has not
been sufficiently challenged led to plan and
critical path that did not reflect the delivery
reality.
2.1.2) There is no overarching end-to-end plan,
leading to cross-workstream dependencies not
being well-understood or managed.
2.1.3) Inconsistent and disconnected planning
across teams, leading to a lack of clarity on
sequencing and accountability.
2.1.4) Tools do not support effective planning
across all SPM workstreams (business,
operations/BAU, IT).
POL00458014
POL00458014
WORKING DRAFT
ji Tower Proposed Mapping to
Recommendation Priority Summary Rec.
Rec2.1A) Revise current plans to develop an integrated plan covering all activities for the next {
phase of programme delivery, e.g. realistic delivery timelines, scope and dependencies (per #16
Rect.2A, Rect.5B). (Underway)
Rec2.1B) Align & embed processes and function for managing ongoing integrated planning to
support the agreed delivery and governance model (including team-level planning), e.g., cadence, Vv #12
value metrics, representation, iterations through lessons learned.
Rec2.1C) Drive consistent adoption of refreshed planning processes by clearly documenting team
expectations, enforcing ways of working, and ensuring consistent comms to drive awareness and #22
adoption.
Rec2.1D) Agree, adapt, and embed appropriate planning tooling into the programme that is ne
consistent with the agreed delivery model (per Rec1.6D) and POL portfolio requirements.
I Moderate interventions recommended _Limited or no interventions recommended Copyright © 2023 Accenture. Alll rights reserved. 58
POL00458014
POL00458014
WORKING DRAFT
RECOMMENDATIONS (2/5) I _GoveRNANcE I
2.2 REPORTING
Tower Proposed Mapping to
Level2 Observation Recommendation Priority Summary Rec.
Rec2.2A) Agree clear detailed KPls and KRIs, aligned to the strategic vision, thresholds, and
delivery model (per Recl.1D, Recl.1E, Recl.6C), to track delivery and drive insights at all levels from Vv #20
leadership through to delivery teams.
2.2.1) Reporting is focused on information over
insight which impairs swift decision-making.
Rec2.2B) Remediate existing data (e.g. within JIRA) to align with agreed metrics (per Rec2.2A) so Vv #0
8 that progress can be consistently measured against the thresholds and any issues escalated.
3 2.2.2) RAID management is not incorporated
= into the day-to-day management of the
3 programme.
2
g Rec2.2C) Embed measurement against agreed KPls and KRis into reporting processes and #0
3 2.2.3) Tools do not support effective escalation routes in line with agreed governance model (per Rec2.3B, Rec2.3C).
§ coordination or data-driven decision-making
S across SPM workstreams (business,
= operations/BAU, IT).
a
a Rec2.2D) Agree, adapt, and embed appropriate reporting tooling into programme that is #12
2.2.4) Meaningful KPis not consistently tracked
over time preventing early identification of
issues.
consistent with the agreed delivery model (per Recl.6D) and POL portfolio requirements.
Rec2.2E) Drive consistent adoption and a data-driven decision culture by clearly documenting
team expectations, enforcing ways of working, e.g. RAID management, and ensuring consistent #22
comms to drive awareness and adoption.
I Moderate interventions recommended —_Limited or no interventions recommended —_ Copyright © 2023 Accenture. Alll rights reserved. 59
> @ RAG Definitions [Bf sioniicantincerventions recommended -
POL00458014
POL00458014
WORKING DRAFT
RECOMMENDATIONS (3/5) I _GoveRNANcE I
2.3 PROGRAMME ORGANISATION, AUTHORITIES, & FORUMS
i Tower Proposed Mapping to
Level 2 Observation Recommendation Priority Summary Rec.
v
Rec2.3A) Review and right-size programme org structure to support revised delivery model. #8
‘Underwa'
2.3.1) Structural issues with programme ( ”)
delivery organisation driving duplication of
roles, high management vs delivery ratios and Rec2.3B) Review, rationalise, and embed E2E cross-programme governance forums (including a
high costs. within delivery teams), e.g., cadence, inputs, representation, number of attendees.
2.3.2) Swing from previous overly-heavy
Governance to insufficient levels today but Rec2.3C) Review, rarlonalie, and embed cross-POL governance forums to support the Vv 3
remains siloed and perceived tobe opaque. PFOS"aMme delivery model,
2.3.3) insufficient internal and external Rec2.3D) Re-establish and embed a clear programme RACI, including delegated decision-making Vv #9
assurance in place to monitor delivery structures and escalation routes, under new single SPM programme.
progress & quality.
Vv
Rec2.3E) Create an integrated assurance universe for the programme aligned to central POL 9
2.3.4) BDA and TDA forums are in place, bute ctrance processes.
decision-making is disjointed without
sufficient buy-in.
(Underway)
Rec2.3F) Execute an integrated assurance plan, with outcomes reviewed by POL governance #19
2.3.5) Unclear accountabilities and lack of top- bodies as appropriate.
down support impacting confidence and
slowing decision-making and issue resolution.
2.3 Programme Organisation, Authorities, & Forums
Rec2.36) Drive consistent adoption and transparent culture by clearly documenting governance
processes and accountabilities (e.g., decision and escalation routes), embedding a consistent #22
leadership culture, and ensuring consistent comms to drive awareness and adoption.
_ Moderate interventions recommended
> @ RAG Definitions [Bf sioniicantincerventions recommended -
Limited or no interventions recommended —_ Copyright © 2023 Accenture. All rights reserved, 60
RECOMMENDATIONS (4/5)
2.4 CHANGE CONTROL, 2.5 COMMERCIAL & CONTRACT MANAGEMENT
Level2
Observation
2.4.1) Technical delivery change process has
been clearly documented but is limited in its
scope.
2.4.2) Change management is focused
primarily on technical delivery leading to
incomplete understanding of change.
2.8.1) Processes are in place, but rapid
expansion of teams to hit timelines has led to
significant overspend.
2.5.2) High proportion of contractor resource
in key leadership roles introducing continuity
risks.
2.5.3) Cost or effort required to run the future
__ service in BAU are not prioritised as part of
decision-making.
> @ RAG Definitions i I Significant interventions recommended
POL00458014
POL00458014
WORKING DRAFT
Recommendation Tower Proposed Mapping to
Priority Summary Rec.
Rec2.4A) Agree and re-establish appropriate programme-level change management (e.g. change
impact assessments, change governance), which includes engagement with cross-POL #15
stakeholders and appropriate assessment, consideration, and sign off of risk profiles.
Rec2.4B) Align programme-level change management with existing tech delivery change control a5
processes.
Rec2.4€) Improve processes, e.g. design authority by product area for managing detailed
technical changes within delivery, e.g. alignment of low-level design (LLD) and implementation to #12
high-level solution design (HLD) (per Rec4.2D).
Rec2.4D) Agree, adapt, and embed consistent use of tooling (e.g. JIRA & Confluence) and
ceremonies in line with agreed delivery methodology for traceability from requirements to lower- #12
level design (per Rec1.4C).
Rec2.5A) Embed processes for ongoing cost tracking and financial assurance (Rec1.2C). Vv #21
Rec2.5B) Agree suitability of current delivery model and uplift resourcing strategy, e.g. Pr
consideration of 3rd party delivery partner to substitute and/or expand existing capabilities.
Rec2.5C) Establish clear processes and guardrails to guide key technical decisions that impact
t #18
the total cost of ownership (TCO) for the future service.
Rec2.5D) Agree, adapt, and embed appropriate tooling or processes to capture data for
management and estimation of total cost of ownership, e.g., establishing FinOps, empowering #21
PMO to engage in TCO management.
Moderate interventions recommended Limited or no interventions recommended Copyright © 2023 Accenture. All rights reserved. 61
RECOMMENDATIONS (5/5)
2.6 RESOURCE MANAGEMENT, 2.7 VENDOR MANAGEMENT
POL00458014
POL00458014
WORKING DRAFT
Level2 Observation Tower Proposed Mapping to
Priority Summary Rec.
Rec2.6A) Agree and re-establish clear delivery estimation and forecasting mechanisms, e.g., Vv “7
based on time, skills, resource cost, capacity, dependencies.
2.6.1) Limited mechanism for accurately
estimating delivery effort or team capacity
leading to inaccurate plans.
2.6.2) Historic rapid uncontrolled expansion
strained team capacity by creating a reactive
environment that was hard to manage.
Rec2.6B) Review, agree, and embed approach to effective cross-programme resource Ho
management to support delivery model.
2.7.4) Venciore not held to account for ives or REC2-7A) Use existing facility for outcome-based contracting with 3" party vendors within agile ”
nettles Pros) 2 construct, e.g. based on very clear requirements and deliverables within their control.
Moderate interventions recommended Limited or no interventions recommended Copyright © 2023 Accenture. All rights reserved. 62
> @ RAG Definitions i I Significant interventions recommended
POL00458014
POL00458014
WORKING DRAFT
111.3 IPEOPLE REVIEW
DETAIL
Copyright © 2023 Accenture. Allrightsreserved. 63
POL00458014
POL00458014
WORKING DRAFT
SUMMARY OF OBSERVATIONS
PEOPLE LEVEL 2 AND LEVEL 3 CAPABILITY RAG RATINGS.
LEVEL 2 CAPABILITY ~ LEVEL3 CAPABILITY I
3.1.3. Change
Governance &
Accountability
i I 3.1.4 Change Vision & 3.1.2 Change Strategy &
H Sponsorship Approach
i . , II 3.2.2. Change
hange Impact Implementation & 3.2.3 Change Capability
2.4 Change Champions
ment (CIA) Adoption Plan
letwork
3.3 Stakeholder Engagement I I 331 Stakeholder II 3.32 stakeholder '[333 comms
H Engagement & Comms se Stakeholder Engagement
& Comms Strategy Mapping & Analysis Delivery :
° H 3.4.1 Leadership 3.4.2 Culture & AA Wave :
3.4 Culture & Behaviours I I Alignment Behaviours 3.43 Ways of Working
3.5.1 Skills & II 35.2 Knowledge 3.5.3 Roles &
Competency Needs _I Retention Responsibilities
H 3.6.1 Learning Strategy & 3.6.2 Learning Needs 3.6.3 Learning Design & 6.4 Learning Delivery,
H Approach II Analysis (LNA) Development Deployment & Evaluation
Moderate interventions recommended Limited or no interventions recommended Copyright © 2023 Accenture. Alll rights reserved. 64
> @ RAG Definitions i I Significant interventions recommended
POL00458014
POL00458014
WORKING DRAFT
w
al
a
°
wi
a
OBSERVATIONS (1/6)
3.1 CHANGE STRATEGY
Evidence (what we have seen and heard)
Observation
Level 3
Level2
The programme has not established a consistent and compelling Change vision that can generate excitement
and commitment among internal and external stakeholders
@
F
e
§
£
o
o
Unclear programme-wide understanding or
ownership of change vision across all
Vision &
inconsistent engagement with the wider business and inability to take people along on the journey effectively
Differing interpretations of the vision (e.g., business transformation or tech replacement) has led to
impacted stakeholders despite formation of
RTP*
Sponsorship
No single business or change sponsor (until very recently) hence no single source of truth and accountability
when it comes to business change and vision clarification
A lot of work has gone into producing Business Change related artefacts and documents incl. a Change
Strategy. However, there does not appear to be a consistent approach to the change journey for internal and
external stakeholders across these documents, or enough detail around how the different business change
activities (e.g., Comms, Training) will underpin the programme and help enable its objectives
The above is not helped by the lack of alignment on the vision for the programme or lack of clarity on progress
which make it difficult to identify the right interventions for stakeholders
includes considerations for all impacted
No overarching change approach that
stakeholders will lead to adoption risk
Any business change-related assets developed prior to the merging of STP and RTP would need to be revisited
to ensure they incorporate the holistic view required for a programme of this size and impact with input from
the appropriate stakeholders (e.g., tech delivery)
In recent weeks, steps have been taken to bring Business Change under one roof which should help address
some of the above issues
There is a lack of clear Change Governance and RAC! for the programme overall which has led to confusion
around who should be owning what for Business Change
Change accountabilities unclear leading to
There is not a single point of accountability for the programme (e.g., Business Change Lead)
65
Copyright © 2023 Accenture. All rights reserved.
Limited or no interventions recommended
Change-related roles and responsibilities have not been clearly defined or guided by a unified strategy and
approach
In recent weeks, steps have been taken to address this gap
Moderate interventions recommended
inconsistent decision making and duplication
“The consolidation of RTP and STP into a single programme was announced w/c 18 Sep 2023 which was in parallel to this review.
> ED rcdotinivions i I ignificant interventions recommended
POL00458014
POL00458014
WORKING DRAFT
w
al
a
°
wi
a
information (e.g., what capabilities would be in place by when, tech roadmap) and therefore lack a complete
and holistic view
There is a plan and an updated template to conduct CIAs once this activity resumes which should help address
some of the above issues
inconsistencies and duplication of effort. These plans have also been developed without sufficient input from
all key stakeholders (e.g., products, tech delivery)
support the programme from a Business Change perspective (e.g., to cascade comms, generate excitement,
Different teams (e.g., products, scope) had to produce their own CiAs to ensure they understand the change
secure buy-in from teams)
impact and the audiences affected (e.g., for changes to requirements) which led to duplication of effort and
Change Impact Assessments were previously conducted without sufficient access to the right stakeholders or
inconsistencies
Business Change has historically not been embedded into the programme which has had an impact on the
Other than the postmaster working group, there isn’t a Change Champions network that has been set up to
There has been an inconsistent approach to the wider journey people (internal and external) will need to be
change journey for internal and external stakeholders
ClAs have been halted due to delays to R3 and will be picked up once R3 materials are finalised, A high-level
taken on (e.g., change related activities for postmasters or senior stakeholders)
POL wide CIA has taken place to capture the level of impact across functions
There are different versions of plans across teams capturing business change activities which has led to
There has not been one Business Change Lead for the overall programme to champion the importance of
Business Change and provide clear steer
Following the downsizing of Business Change resources, there are concerns about the level of Change
Steps have been taken recently to ensure change execution is consolidated and consistent across the
capability for the programme
Evidence (what we have seen and heard)
programme going forward
holistic way given limited representation of all
impacted stakeholders and missing business
process owners*
No formalised change champions network
that can ensure representation across all
programme have been disjointed leading to
impacted stakeholder groups
inconsistencies and duplication
recent downsizing of the team will lead to
adoption risk
iS
Bd
2
a
3
3
€
S
3
6
<
=
3
2
>
g
a
2
o
3
=<
i)
Change plans and activities across the
Lack of a Business Change Lead and the
OBSERVATIONS (2/6)
3.2 CHANGE EXECUTION
Level 3
“As per the Strategy tower finding 1.4.4.
Level2
66
Copyright © 2023 Accenture. All rights reserved.
Limited or no interventions recommended
> @ RAG Definitions i I Significant interventions recommended Moderate interventions recommended
OBSERVATIONS (3/6)
3.3 STAKEHOLDER ENGAGEMENT & COMMS
Level2
3.3 Stakeholder
Engagement &
Comms
3.3.3
Stakeholder
Engagement &
Comms Delivery
> @ RAG Definitions [Bf sioniicantincerventions recommended Moderate interventions recommended
Observation
The stakeholder engagement and comms
strategy & plan require input from a wider
group of key stakeholders to ensure a more
holistic and consistent view
The stakeholder map and analysis require
input from a wider group of key stakeholders
__ to ensure a more holistic and consistent view
Fragmented, reactive and inconsistent internal
and external stakeholder engagement and
comms has led to limited transparency both
within and beyond the programme
POL00458014
POL00458014
WORKING DRAFT
PEOPLE
Evidence (what we have seen and heard)
+ Acomprehensive comms & engagement strategy & plan have been produced by RTP with involvement from
the POL Comms team and the SPM Engagement team
+ However, to ensure a holistic and complete view, the team should aim to get input from all key stakeholders
eg., in tech delivery (tech roadmap), esp. since colleagues in what was previously STP were not aware that a
comms & stakeholder engagement strategy and plan existed
+ Comprehensive work has taken place to create a stakeholder map, matrix and grid to capture the stakeholder
landscape for the programme from RTP. To ensure a more holistic and complete view, the programme will
need to involve and get input from key stakeholders in tech delivery as well as leadership
+ There still appears to be insufficient clarity on who should be contacted (e.g., teams are not sure who is the
right contact for Compliance), when or how
+ Different teams have had to develop their own stakeholder maps (e.g., technology delivery, RTP) duplicating
effort
+ Steps have recently been taken to address inconsistencies and duplications in this space
+ There is lack of transparency and consistency when engaging with the various stakeholders (e.g.., in relation to
delays, defects). This has not helped build trust in the programme
+ Comms were halted due to uncertainty around the direction of the programme and the delays which caused
confusion and frustration among key stakeholders incl. postmasters
+ Wider engagement with the postmaster community has been put on hold. However, a sub-set of the PM
Working Group has been engaged as part of ongoing solution refinement within tech delivery (e.g., user testing
to support R2) which has been positive
+ There is not a single and easy way to reach out to all Postmasters (e.g., single contact database) which is
further impeding the two-way engagement required
+ Some updates have been provided to external stakeholders (e.g., postmasters, strategic partners) following
complaints and escalations but they have mostly been informal
Limited or no interventions recommended —_ Copyright © 2023 Accenture. All rights reserved, 67
POL00458014
POL00458014
WORKING DRAFT
OBSERVATIONS (4/6)
3.4 CULTURE & BEHAVIOURS
Level 2 Level3 Observation Evidence (what we have seen and heard)
3.4 Culture &
Behaviours + There is lack of alignment among leadership in terms of the vision, the strategic objectives and what “replacing
Lack of vision and objectives alignment Horizon” meant for the programme, the teams within it and POL
within programme and senior leadership + _This is also cascaded across teams who contribute to the programme with different goals in mind (e.g. like-for-like
cascading into misalignment within teams replacement of Horizon, full retail transformation)
3.4.1 Leadership
Alignment
+ There are pockets of positive and collaborative culture but that is not ultimately underpinning the transformation as
the “one team” mindset does not exist for the programme
+ Interviews have surfaced several instances of unprofessional behaviours and friction between teams and
individuals
Wider programme and organisational
factors have exacerbated programme
team culture and morale challenges
+ There is a fear to make decisions and take accountability (e.g., who should own certain risks) which people have
3.4.2 Culture & attributed to the tight timelines and the nervousness around a potential future inquiry
Behaviours + The high employee turnover esp. at leadership level, the splitting of the programme and the high number of
contractors are seen as factors that have prevented the programme from establishing a stable culture and a
consistent vision
+ Participants spoke of generalised demotivation which can be attributed to recent uncertainty around the significant
downsizing of teams, the negative attention the programme is receiving and the fact that the programme has
stopped celebrating successes (e.g., recent releases)
Fragmentation and silos exist atall levels * Lack of appetite to collaborate with certain teams (e.g., security, assurance) as a result of the pressing timelines
3.4.3 Waysof leading to limited collaboration and This could present the programme with bigger issues (incl. legal and security ones) in the future
Working suboptimal outcomes for the programme —._Following the merging of STP and RTP, participants have reported feeling like they still operate in an “awkward”
environment
Limited or no interventions recommended Copyright © 2023 Accenture. Alll rights reserved. 68
> @ RAG Definitions i I Significant interventions recommended
_ Moderate interventions recommended
POL00458014
POL00458014
WORKING DRAFT
w
al
a
°
wi
a
OBSERVATIONS (5/6)
3.5 SKILLS & COMPETENCIES
Evidence (what we have seen and heard)
Observation
Level 3
Attracting the right people to the programme (externally and from POL) has been a challenge due to high
costs, HR processes, the niche skills required and the stigma of the Horizon inquiry. As a result, there have
been competency gaps in key areas (incl. large complex transformation, reporting, programme management,
agile, deep technical expertise to challenge the direction of the programme). Those competency gaps have
partially been addressed by third parties
There are concerns around knowledge retention within POL considering the high proportion of contractors and
does not always align with work packages; more people were brought in in recent months despite there being
the downsizing of the programme
Workforce planning for the programme has been insufficient and inconsistent. E.g., contractor resource count
indications the programme would slow down
Insufficient knowledge and experience within POL in relation to Horizon, its processes, requirements and
functionalities led to lack of clarity around skills & competency needs
Participants have indicated they feel demotivated and would be looking for opportunities elsewhere
The recent downsizing of teams is likely to exacerbate skills and competency needs in certain areas
Handovers will be conducted over a limited period of time and to a small number of people
programme are often not met which has had
an impact on delivery
High contractor ratio and transience within
roles is presenting a knowledge retention
Skills and competency needs of the
challenge
°
3
3
;
“
%
8
cH
Retention
There is not a RACI for the overall programme, which has made it harder for people to understand who should
be involved in the various activities and initiatives (e.g., demos, ClAs) or who to contact to get input for certain
activities (e.g., Compliance)
Unclear roles and responsibilities slowing
down decision making and issue resolution*
ATOMis currently being developed which should help address these challenges
“As per the Governance tower finding 2.3.5.
> ED rcdotinivions i I ignificant interventions recommended
69
Copyright © 2023 Accenture. All rights reserved.
Limited or no interventions recommended
Moderate interventions recommended
POL00458014
POL00458014
WORKING DRAFT
w
al
a
°
wi
a
OBSERVATIONS (6/6)
3.6 LEARNING & TRAINING
Evidence (what we have seen and heard)
Observation
Level 3
Level2
The NBIT Training and Information Strategy hinges around a digital based approach to learning and is based on
a number of assumptions (e.g., access to LMS) that cannot be fulfilled considering the current circumstances
(e.g., budget and resource constraints)
More clarity is needed around the future
There is lack of clarity around the right direction of travel for learning, the learning interventions needed (e.g.,
for Postmasters - tech or soft skills) and who should be providing the training (e.g.,
providers)
direction of travel for learning for all impacted
stakeholders considering funding and
postmasters, external
resourcing challenges
The budget constraints and the downsizing of the team are likely to have an adverse impact on the
programme’s ability to use learning as a lever for adoption
Work is underway to bring training under one roof which should address some of these issues
Comprehensive LNAs were conducted by both RTP and STP. However, those were completed separately
without representation or input from all impacted teams
The LNA conducted by RTP identified a wide range of audiences that will need to be trained on the new
Learning needs of impacted stakeholders will
not be met due to gaps in training scope
solution (e.g., service support, BAU teams). These audiences are not covered in anyone’s scope and the
relevant BAU teams do not have capacity to deliver training to them
The scope for learning design and development mostly covers conversion training for specific audiences (e.g.,
postmasters). Therefore, there are gaps in terms of learning interventions that will be needed for various
audiences (e.g., new joiners, Head Office, help desk people)
A comprehensive end-to-end training deployment plan was produced by RTP which was validated by the POL
Comms & Engagement team. However, this was completed without sufficient input from all relevant
stakeholders from STP (e.g., training material created, when it would be available)
There are not enough licences for all postmasters to access the current LMS (-7500 licences for 55000
people). The current LMS is also not considered user friendly or engaging enough
constraints will limit successful learning
Lack of modern LMS tool and funding
delivery
Due to funding constraints, a decision to introduce a new Learning Management System (LMS) has been put on
hold. This is likely to impact the ability of the programme to upskill people and digitalise learning instead of
relying on more costly and time-consuming methods of learning
70
Copyright © 2023 Accenture. All rights reserved.
Limited or no interventions recommended
Moderate interventions recommended
> @ RAG Definitions i I Significant interventions recommended
POL00458014
POL00458014
WORKING DRAFT
RECOMMENDATIONS (1/5)
3.1 CHANGE STRATEGY
Tower Proposed Mapping to
Level2 Observation Recommendation Priority Summary Rec.
v
Rec3.1A) Revisit and relaunch the Change vision to drive buy-in and energise stakeholders both
I #
I internal and external to programme, e.g., workshops, comms, away days 2
3.1.1) Unclear programme-wide understanding
_ or ownership of change vision across all Rec3.1B) Define, agree, and embed change roles and responsibilities under a single Business #9
_ impacted stakeholders despite formation of Change workstream led by a single point of accountability (e.g., individual with deep expertise in Vv
I RTP’ delivering business change as part of a complex transformation programme)
3.1.2) No overarching change strategy that
_ includes considerations for all impacted
I stakeholders will lead to adoption risk
I] Rec3.1C) Revisit existing change strategies and consolidate those to have one integrated Business v #28
I 3.1.3) Change accountabilities across STP and Change strategy for the overall programme that covers all related activities holistically for all
_ RTP unclear leading to inconsistent decision _ impacted stakeholders based on a consistent methodology (e.g., ADKAR)
_ making and duplication of effort
I Rec3.1D) Socialise the Business Change strategy with key stakeholders (incl. GE, retail). Engage 498
I them in shaping it to secure buy-in, and to act as advocates
“The consolidation of RTP and STP into a single programme was announced w/c 18 Sep 2023 which was in parallel to this review.
> @ RAG Definitions i I Significant interventions recommended Moderate interventions recommended —_Limited or no interventions recommended Copyright © 2023 Accenture. All rights reserved. n
RECOMMENDATIONS (2/5)
3.2 CHANGE EXECUTION
Level 2 Observation
- 3.2.1) CIAs were previously not conducted in a
_ holistic way given limited representation of all
_ impacted stakeholders and missing business
_ process owners*
3.2.2) Change plans and activities across the
_ programme have been disjointed leading to
inconsistencies and duplication
3.2.3) Lack of a Business Change Lead and the
"recent downsizing of the team will lead to
adoption risk
3.2.4) No formalised change champions
_ network that can ensure representation across
_ all impacted stakeholder groups
__andissue resolution
“As per the Strategy tower finding 1.4.4
> ED rcdotinivions i I
POL00458014
POL00458014
WORKING DRAFT
PEOPLE
Tower Proposed Mapping to
Recommendation Priority Summary Rec.
Rec3.2A) Embed consolidated business change capability into the programme to ensure the v #28
change journey is looked at holistically and consistently for all impacted stakeholders, with the
business change team working closely with tech delivery (Underway)
Vv #22
Rec3.2B) Empower the Business Change team to drive Business Change for the programme by
identifying, designing and delivering the right interventions for internal and external stakeholders
Rec3.2C) Consolidate change impact assessments to ensure the impact of change on all #28
stakeholders within and outside the programme is understood and considered as part of change Vv
management
Rec3.2D) Agree, adapt and embed one unified change implementation plan that captures all #28
business change related activities needed for the programme with clear owners and one Business
Change team executing this
#28
Rec3.2E) Map out the change journey for the key stakeholder groups impacted and explain how
they will be taken along on the journey and the experience will be like (e.g., through personas)
. #28
Rec3.2F) Introduce a change champions network for the programme to ensure representation
and involvement from all impacted stakeholder groups
nificant interventions recommended Moderate interventions recommended —_Limited or no interventions recommended Copyright © 2023 Accenture. Alll rights reserved 2
POL00458014
POL00458014
WORKING DRAFT
RECOMMENDATIONS (3/5)
3.3 STAKEHOLDER ENGAGEMENT & COMMS
" ‘ Tower Proposed Mapping to
Level2 Observation Recommendation Priority Summary Rec.
Vv #28
Rec3.3A) Revisit and refine the comms and engagement strategy and plan for all audiences
{internal and external) in collaboration with representatives from all teams within the programme
(Underway)
A 3.3.1) The stakeholder engagement and 429
4 comms strategy & Plan require input froma Ree3.3B) Socialise the comms & engagement strategy and plan with the programme and key v
8 wider group of key stakeholders to ensure 2 stakeholders to raise awareness and secure buy-in
C) more holistic and consistent view
cI
; A
‘ 3.3.2) The stakeholder map and analysis,
§ require input from a wider group of key V #28
@ stakeholders to ensure a more holistic and Rec3.3C) Consolidate and refine stakeholder map & analysis to ensure all impacted stakeholders
z consistent view and their needs are captured
a (Underway)
3 3.3.3) Fragmented, reactive and inconsistent
4 internal and external stakeholder engagement
and comms has led to limited transparency
a both within and beyond the programme Y — Rec3.3D) Reset and restart comms & engagement in collaboration with Leadership and make a Vv #29
S point of providing frequent and transparent updates to internal and external stakeholders to
3 rebuild trust in the Programme
#29
Rec3.3E) Revisit and refresh or establish mechanisms for engagement with key stakeholders (incl.
GE, postmasters)
> @ RAG Definitions i I Significant interventions recommended Moderate interventions recommended __Limited or no interventions recommended Copyright © 2023 Accenture. All rights reserved. 73
RECOMMENDATIONS (4/5)
3.4 CULTURE & BEHAVIOURS
Level2 Observation
3.4.1) Lack of vision and objectives alignment
within programme and senior leadership
cascading into misalignment within teams
3.4.2) Wider programme and organisational
factors have exacerbated programme team
culture and morale challenges
3.4.3) Fragmentation and silos exist at all
levels leading to limited collaboration and
suboptimal outcomes for the programme
g
g
2
A
2
$
8
es
:
2
A
oO
¢
a
> @ RAG Definitions [Bf sioniicantincerventions recommended -
Recommendation
Rec3.4A) Run a leadership alignment session to revisit and revalidate the vision to make it
compelling and inspiring as well as provide clarity and specific objectives for each team
Rec3.4B) Socialise the vision with all teams within the programme as well as external stakeholders
to raise awareness, gain commitment and mobilise advocates
Rec3.4¢) Identify desired behaviours and ways of working, with involvement from leadership as
well as input from people within the programme
POL00458014
POL00458014
WORKING DRAFT
PEOPLE
Tower Proposed Mapping to
Priority Summary Rec.
Vv #2
Vv #29
#22
#22
Ree3.4D) Introduce initiatives that will foster and embed a collaborative environment across the
programme (e.g., F2F or virtual events)
#22
Rec3.4E) Leadership to make a point of celebrating successes and rewarding / recognising
outstanding contributions
I Moderate interventions recommended —_Limited or no interventionsrecommended Copyright © 2023 Accenture. Alll rights reserved. 74
POL00458014
POL00458014
WORKING DRAFT
RECOMMENDATIONS (5/5)
3.5 SKILLS & COMPETENCIES, 3.6 LEARNING & TRAINING
Level2 Obser Recommendation Townes soe
3.5.1) Skills and competency needs of the Rec3.6A) Establish clear RACI, roles & bilities for th lidated Leth v #9
programme are often not met which has had R@€3-SA) Establish clear RACI, roles & responsibilities for the consolidated programme incl. the
> business change-related workstreams
an impact on delivery (Underway)
7 . . Mail
3.8.2) High contractor ratio and transience Rec3.SB) Identify competency and skills gaps across key areas of the programme in collaboration v
within roles is presenting a knowledge with Leadership and recruit against those
retention challenge
3.5.3) Unclear roles and responsibilities Ree3.5C) Where possible, bring in more POL employees to work on the project to enable bal
slowing down decision making and issue knowledge retention or introduce ways of upskilling POL staff through working with consultants or Vv
resolution* contractors
Rec3.6A) Establish one learning team for the programme that looks at the learning journey of all v #8
impacted stakeholders holisticall
3.6.1) More clarity is needed around the future "> Y (Underway)
direction of travel for learning considering
funding and resourcing challenges
Rec3.6B) Revisit and confirm objectives and scope of the consolidated Learning team Vv #28
3.6.2) Learning needs of impacted
stakeholders will not be met due to gaps in Ree3.6C) Identify gaps (e.g., where training of some stakeholders may not be covered) and v 28
training scope produce a plan to address those in collaboration with the BAU Learning team
- Rec3.6D) Consolidate and refresh the Learning Strategy and related deliverables (incl. training
3.6.3) Lack of modern LMS tool and funding deployment plan) for the programme with input from key stakeholders, taking into account the Vv #28
constraints will limit successful learning budget and resource constraints
_ delivery
Ree3.6E) Invest in digitalising learning for the programme to reduce reliance on more costly and
i } #28
time-consuming face-to-face interventions
*As per the Governance tower finding 2.3.5
> @ RAG Definitions i I Significant interventions recommended
Moderate interventions recommended Limited or no interventions recommended Copyright © 2023 Accenture. Alll rights reserved. 75
POL00458014
POL00458014
WORKING DRAFT
111.4 I SOLUTION
REVIEW DETAIL
Copyright © 2023 Accenture. Allrightsreserved. 76
POL00458014
POL00458014
WORKING DRAFT
SUMMARY OF OBSERVATIONS
SOLUTION LEVEL 2 AND LEVEL 3 CAPABILITY RAG RATINGS.
LEVEL 3 CAPABILITY
LEVEL 2 CAPABILITY
4.1.1 Operation
Priorities & Support
4.2 Prepare for
I Workloads
Principles
{Structures
! 4.21 Vision & ponies
I Roadmap I Constraints
}]431 Development I] 4.3.2 Security
i] Principles Principles
]4.4.1 NFR 4.4.2 Scalab
Management 4.4.2 Scalability
I 45. Data & 45.2 Data
4.6.1 Code
Standards/Policies
4.7.1 Network
Moderate interventions recommended
} Reporting Strategy
Architecture
I 4.6.2 Best Practices
& Patterns.
I 4.7.2 Compute
4.1.3 Operate
Workloads
4.23 Capability
Model
4.3.3 Operations
4.4.3 Security
Management
45.3 Data
Dictionaries &
Models
4.6.3 Code
4.7.3 Hardware
Limited or no interventions recommended
41.4 Evolve to
upport Workloads
2.4 Solution High
evel Design
3.4 Environment
trategy
4.4.4 Performance
I 47.4 Software
/4.25 Architecture
I4.45 Resiliency
@
torage
I I]4.26 Security &
IGovernance Model
Compliance
Copyright © 2023 Accenture. All rights reserved ”
POL00458014
POL00458014
WORKING DRAFT
2
°
=
=)
al
fe}
on
Evidence (what we have seen and heard)
é
$3
&
E
2
§
A
3
8
8
2
2
3
o
8
g
&
3
8
2
§
8
5
a
8
8
2
:
td
E
Lad
3
2
°
=
g
8
8
2
z
2
5
8
3
2
e
5
i=
5
3
8
3
3
$
°
2
5
2
=
service & transitioning service catalogue, support documentation, policies/procedures, job aids, roles/responsibilities, etc.
NBIT Service Runbooks follow a defined standard, while many are still in Draft or Review status this is expected at this stage
in the programme deliver
Service SLA's follow standard service levels within POL but are not NBIT specific
ServiceNow IT Ops Dashboard is set up to share status of incident tasks, change records, problem investigations and known
errors
Lessons are being identified after releases, but no systematic approach to evolve and incorporate feedback into service.
Defined scalability and observability approach is currently tactical (e.g. Data Dog) to support R2, therefore will need to be
updated in line with the long-term support requirements
difficult to develop and deploy - Every time NBIT has a need to deploy software there is a complex, high risk, manual process
(1) Integrate 144 technology stacks (2) Follow a 28 step release process. This is repeated 6 times across 6 out of
A number of systematic problems were captured in April ‘23, detailed in the Build Better (BB) improvement plan: "NBIT is.
syne environments.”
NBIT release management and supporting documentation is well-defined, however the deployment process that underpins
the release process has historically been complex, manually intensive and error-prone. Continuous improvements taking
place as part of the Build Better project
There is an incomplete set of automation testing and standardisation across the product domain teams. Furthermore,
incomplete non-functional testing resultant from a lack of non-functional requirements has led to the inability to fully prove
applications are performing as expected as captured in the improvement plan
Other systematic problems captured in the Build Better improvement plan: incomplete set of integration tests (Stubs/API
Unit), minimal observability, lack of clarity around feature requirements and incomplete security requirements defined
The BB improvement plan is presently in Wave 1 of 3 and tackling engineering improvements in such areas as:
requirements
capture process, developer experience, test automation, API test standardisation, observability PoV/implementation, security
issue resolution and reducing new security issues
Future continuous improvement planned includes improvement to DEV throughput, integration across workstreams,
throughput to LIVE and feature toggles
The Service Ops process of AWS access management is manually intensive and time consuming at present with 15-30 access
requests to manage per week, involving overseeing automated requests to make sure that all participants in the workflow are
actioning their steps in the process. Furthermore, manually creating Jira tickets for requests that are not automated.
Decoupling the deployment from release processes has been considered but not fully designed or implemented
78
Copyright © 2023 Accenture. All rights reserved.
Limited or no interventions recommended
2 e 6
ea oe eye £
a gs ees eee
ez. Soe gees
= & oo gs So gese
—_ g,2$> Be 32
2808 ESes Be3e
8 2522 98
SSPs8 Lessvaggs
see28 goees Sr o8
expe? Besesees
§ asgee Be bZERSES
> r4 8253 BSlS$zesee
E g Sezee BeSsarsss
~ SSS08 @52foESas
a § S2oRE BoC ESE SSE
Hy 80555 osSgutaess
= 3 BUso8 2SBESES8S
om © 3 Osese EaESSELSR
= fe -
2 a
ees: I
ms } i
3 a
= 4
ll =
O i
POL00458014
POL00458014
WORKING DRAFT
2
°
=
=)
al
fe}
on
79
Copyright © 2023 Accenture. All rights reserved.
g
5
—
&
8
2
g
5
3
g
5
3
E
standardisation and traceability across services, while this is not a concern for the limited rollout it should be remediated for
scaled rollout to 11.5k sites
Initial approach to continuous improvement was to allocate 20% of work items in engineering sprint capacity to addressing
technical debt and improvements however this was never fully realised due to time pressures and a focus on delivering
business functionality
A dedicated Continuous Improvement team (Build Better) are currently addressing 8 systemic issues with the development
processes/practices, but this initiative has yet to roll out these new practices across the various development teams
Cost is not properly tracked at a workload level, as a result there are little to no optimisation measures in place. However, it is
The programme has explicitly prioritised tech debt remediation in R2.1 and R2.2 which are currently in flight
noted that there are cost tracking policies and processes in place for individual accounts at OU level, but these are not
A strategic observability/monitoring service has been selected but has not been fully implemented by service teams limiting
implemented
the observability of the E2E solution
Guidelines for Tagging and Alerting are not defined consistently adopted by service teams resulting in a lack of
Evidence (what we have seen and heard)
transparency of the solution and
the ability to detect anomalies.
Historical challenge to dedicate
time to address technical debt
performance and cost metrics
and support continuous
Limited standardisation of
coupled with an inconsistent
alerting approach reduces the
improvement opportunities,
however the ongoing Build
Better initiative has started
making a difference in some
areas with some work to go in
the proposed plan.
Observation
Level3
OBSERVATIONS (2/14)
4.1 OPERATIONS CAPABILITY
nn eel
POL00458014
POL00458014
WORKING DRAFT
z
2
=
5
al
fe)
on
OBSERVATIONS (3/14)
4.2 SOLUTION ARCHITECTURE
80
Copyright © 2023 Accenture. All rights reserved.
Limited or no interventions recommended
Architected Security Principles to provide Architects and Developers with guidance to support good application security
There is a placeholder for NBIT specific architecture principles and policies in confluence, however no content at present
design decisions
There is no formal roadmap for the NBIT architecture however the components of the major releases have been overlayed
which solution high-level designs are presently referencing, for example: Mails Solution Design
onto the target state architecture diagram
AWS standards & guardrails captured in confluence were produced in late 2021/early 2022 and therefore
may require updating in areas to align with any later changes in standards
Cloud security design principles are suggested for the National Cyber Security Centre (NCSC) and AWS Well-
NBIT architecture guiding design principles are only in draft format and captured in confluence as NBIT is.
A vision has been defined for the programme but there is no specific technical vision for the NBIT Service
adopting existing EA and cloud design principles which is not explicitly stated
Evidence (what we have seen and heard)
Architecture patterns have been created and captured in confluence for a subset of solutions
Moderate interventions recommended
High-Level Release plans are
driving the evolution of the
technical capabilities
vision and roadmap defined for
Principles
the NBIT solution, instead the
SPM Programme Vision and
Architecture and Cloud Security
defined for NBIT in some areas,
whilst also adopted from
There is no explicit technical
existing POL Enterprise
Architecture principles,
standards and constraints/
guardrails have been newly
Observation
Level 3
Level2
> ED rcdotinivions [Bf sioniicantincerventions recommended -
POL00458014
POL00458014
WORKING DRAFT
z
2
=
5
al
fe)
on
however, the HLD file naming convention is not
81
Copyright © 2023 Accenture. All rights reserved.
Limited or no interventions recommended
collaboration from architects with delivery teams to ensure alignment of high-level to low-level design and implementation -
addressing potential design flaws and challenges in the design phases reduces the likelihood of errors and defects in the
final implementation, saving time and resources in the long run
logical structure separating them by product area in the centralised repository which makes it difficult to navigate or search
mapping out the current-state of business process, identifying strengths and weaknesses, and then designing a future-state
for a particular HLD
that addresses those weaknesses and optimises the process for better results
alignment to goals, whereas associated LLDs would ensure that developers have a detailed roadmap to follow and minimise
design documents which evolve over time as existing or new requirements are captured and design decisions approved
ambiguity and misinterpretation
There is a standardised high-level solution design template used as a baseline to produce a consistent set of high-level
design documents across the various product domains
HLDs do not currently capture the current-state architecture which would be useful for current/future-state analysis e.g.
The programme has established an architecture capability which includes defining the scope of the architecture practice,
identifying stakeholders and their roles, and establishing the necessary governance mechanisms
Architects work with various business and technical team(s), business owner(s), product owner(s) to produce high-level
Once a solution design HLD is produced for a small subset of product/solution domains there is limited visibility and
The HLD provides stakeholders with a high-level understanding of the system, facilitating clear communication and
consistent, some include version numbers in naming while others do not. Furthermore, there is no
The architecture solution designs do follow a standardised template;
Evidence (what we have seen and heard)
= . =
Beers 3o§ o 2
Z3¢5e 2 =€8 Eeues 9
Beoat @ 8s cSseoee 5
20285 Be os SZ—ESEL 3s
QESZvv5= Be B2oUss @ 2
BSR22e2e05 So B 2b ck
Se soos tec 8s Se5ere 25s
—_ Soessec8e SuEes 288
Seca lessees S8s582 8858
Sezorgeeess Beegess wsse
Sso5g8aS§5So SSSsveper es
Seeeosveexse S5>855s9o55
tad § SS5S ES a5 5s 285s e2qec aes
[4 3 Boe egcterese SBLESSIE REST
i eseeasgotes Ox2S55caeose8
> 4 aS&ZS2g8oee SoOLIsT Ee DOS
Seagstrossseo £aSac SSL Ra
im & 2d8aogls5lss 203 POTS FLS
oO 2 vo soeeaessea SCL2SVESZaqsRzat
Pgeseegegess S2eRessesees
I lu ° Feeéatovtl aaa tEa@scvEoaetao
-<z » fA
z 3 i Be
3 =z LUC
[a4 6 3 pe Sees
a) Pa
# a eG igs ce oe tas ee icreie Sia ie ti eerie ced ei
o s gf Sa eee ee ee eee eee eee
3 A —————“—t—i—‘—™™™ON—™—”—
3 gpe Bs Bee eae
N 3 ee ee
¢ FP Sas erie ea Satay eee
> @ RAG Definitions i I Significant interventions recommended Moderate interventions recommended
POL00458014
POL00458014
WORKING DRAFT
z
2
=
=
=
fe)
on
OBSERVATIONS (5/14)
4.2 SOLUTION ARCHITECTURE
Evidence (what we have seen and heard)
Observation
Level 3
Level 2
The architecture practice has established a governance model with associated processes and standards/policies
ATDA (Technical Design Authority) has been established to oversee the development and implementation of the
c
>
3
3
%
2
2
3
2
rr
2
&
S
=
governance process has been
established with controls in
programmes architecture, however attendance is not consistent with key stakeholders and at times final decisions are made
to minimise impact to delivery rather than selecting the more compliant technical decision,
being raised and a build-up of technical debt
leading to policy exception notes
place that produce architectural
artefacts, however stricter
Due to missing low-level design artefacts there is a lack of HLD-LLD collaboration among architects, developers, and
management and controls are
stakeholders, to ensure that everyone is on the same page regarding the solution architecture, design and implementation
required at the implementation
phase to ensure compliance and
traceability back to high-level
design to avoid misalignment
Previous architecture diagnostic/assurance/audit reports produced with improvement recommendations are being tracked
and prioritised in a centralised issues log in Jira e.g. AWS/ACN Well-Architected Reviews (WAR) and Credera Integrity
Assurance
Compliance with security
Whilst POL Security Compliance teams have a baseline of frameworks and controls, they are outdated and are not integrated
with the delivery teams. Team integration is key to delivering on business, functional and regulatory obligations
regulatory and best practice
requirements are not in line with
modern practices and
Roles and responsibilities of team members are not clear and has resulted in duplicated effort with non-optimal output
No role-based security training or awareness programmes exist to update skills, modern practices or frameworks e.g.
frameworks, resulting in
Current compliance scans do not scan for the same metrics as defined in frameworks at TDA . Indicating that
compliance metrics, processes and policies between HLD and engineering environments are not the same
misconfigurations, solutions that
are not fit for purpose and
increased implementation
timelines.
WAF was identified as a required control from the initiation of the programme and has yet to be delivered
82
Copyright © 2023 Accenture. All rights reserved
Limited or no interventions recommended
Moderate interventions recommended
> @ RAG Definitions i I Significant interventions recommended
POL00458014
POL00458014
WORKING DRAFT
OBSERVATIONS (6/14)
4.3 DEVSECOPS & ENVIRONMENTS
Level 2 Level 3 Observation Evidence (what we have seen and heard)
43
DevSecOps &
Environments Development principles and
processes have historically not
(continues on been standardised across the
next page) 434 various product/platform + Development principles and patterns (e.g. API contracts, Stub Modules) that support decoupling are being adopted but do
service teams which introduced not provide full coverage at present, creating hard dependencies across teams and introducing breaking changes
Development
Principles,
Standards &
Guidelines
both dependencies between
teams, increased defects, and
reduced delivery velocity,
however the ongoing ‘Build
Better’ continuous improvement
initiative is working to address
these systematic problems
+ Strategic DevSecOps Tooling that delivers Cl/CD capabilities has been selected
+ Standards and guidelines have been defined as part of the Build Better Initiative however these standards have not been
fully implemented by across product/platform service teams
+ Security principles have been defined at the TDA level however compliance to these principles are not consistently
integrated into delivered environments, monitored and/or enforced
Security principles, whilst + The programme security team make decisions with little justification or broader solution consideration. This has had a direct
defined, are not integrated or impact on the time to solution
recognised as critical within the. There is a gap between what is being designed, as LLDs are not consistently created to guide engineering efforts. This has.
43.2 solutioning phases of the resulted in Security having to perform post-delivery scans to understand how secure deployments are, resulting in little
Security programme, impacting the traceability, observability and reactive security assurance (i.e. what is being solutioned is being delivered). POL Security
Principles overall health of the solution have discovered security weaknesses by means of pen tests and T&VM scans.
with an increased attack surface
and decreased traceability or
observability
For Example:
+ NBIT InfoSec Executive Summary report has identified inconsistent identifiers between design and risk assessments,
Requirements not directly translated to engineering stories, multiple inconsistent NFR pages.
+ Vulnerability scans are complete highlighted to engineering teams and remediations remain incomplete.
__ Moderate interventions recommended
> @ RAG Definitions [Bf sioniicantincerventions recommended -
Limited or no interventions recommended Copyright © 2023 Accenture. All rights reserved. 83
POL00458014
POL00458014
WORKING DRAFT
OBSERVATIONS (7/14)
4.3 DEVSECOPS & ENVIRONMENTS
Level 2 Level 3 Observation Evidence (what we have seen and heard)
43
DevSecOps &
Environments
Cotes Standard operations metrics
have not been defined and + Focus on the programme has been on the development of the functional capabilities of the NBIT solution and there is limited
implemented consistently operational metrics and principles defined
across the NBIT solution
impacting the ability to operate
the service in line with defined
SLAs
Management and enduring maintenance processes for the NBIT service have not been fully defined
+ B&DE Service Ops KPI/Metrics not defined and still WIP
The environment strategy has
not been fully + Ahigh-level Environment Strategy has been defined however the implementation of this strategy has resulted in brittle
operationalised and does not environments underpinned by manual processes. Therefore, difficult to maintain the goal of delivering stable and secure
PRM Cre readily support a multi products and services
Strategy speed/multi-team model,
Higher environments have more rigorous controls and standards in place preventing critical errors getting through, whereas
impacting the ability to deliver
lower environments are sub-standard and teams could be more productive
stable and secure products and
services
> @ RAG Definitions [Bf sioniicantincerventions recommended I Moderate interventions recommended —_Limited or no interventions recommended Copyright © 2023 Accenture. Allrights reserved. 84
POL00458014
POL00458014
WORKING DRAFT
OBSERVATIONS (8/14)
4.4 NON-FUNCTIONAL REQUIREMENTS
Level 2 Level 3 Observation Evidence (what we have seen and heard)
44
Non-Functional
Requirements
(continues on
next page)
+ NFRs have been documented at an overarching platform level with reasonable coverage, however there
are requirements defined separately at the component or product level which could cause confusion as to which should be
aligned to solution design and lead to further issues in non-functional areas such as performance, data retention and so on
+ The 63 overarching NBIT platform NFR's captured in Confluence which are separated into the following: Core Architecture
Non-functional requirements are [13], Security Architecture [17], Reliability [2], Data Architecture [15], Monitoring & Alerting [7], Backup & Recovery [3]
captured inconsistently across and Maintainability [6]. However, there are limited product level NFRs, and neither is there a consolidated view of all NBIT
the programme, along with no NFRs captured in a single view, artefact or tool at present
Net reanagerene naneenorecentelied + Overarching NER metrics are not reflected in the technical services test cases i.e., user or transaction volumes. As a result,
ge key metrics are not validated ahead of implementation. Limited automation of NFR Metrics across NBIT introduces risk of late
traceability tool, resulting in
limited controls to ensure NFRs
are incorporated in end-to-end
identification of performance issues
+ Missing low-level design artefacts, along with no NFR requirements traceability tool means that there is no effective way to
keep track of how the project is doing at each phase of the development life-cycle. Furthermore, it does not
provide assurance to relevant stakeholders that requirements are meeting expectations
+ An NFR requirements traceability tool is lacking as an essential project management tool which would provide a methodical
way to track and monitor requirements from initiation to delivery
Limited or no interventions recommended —_ Copyright © 2023 Accenture. Alll rights reserved. 85
_ Moderate interventions recommended
> @ RAG Definitions i I Significant interventions recommended
OBSERVATIONS (9/14)
4.4 NON-FUNCTIONAL REQUIREMENTS
Level2 Level 3
44
Non-Functional
Requirements
(continued)
Observation
An integrity assurance
assessment for the NBIT
platform has highlighted a set of
recommendations to improve
the platform scalability which
should be considered before the
solution scales
Security governance
mechanisms and frameworks
are ineffective as security has
not been prioritised at the Low-
Level Design, Delivery and
Operation stages. Resulting in
spontaneous technology
procurement and security
exemptions by default. This
approach may lead to re-
engineering elements of the
solution to adequately integrate
security processes
technologies and skills
> @ RAG Definitions [Bf sioniicantincerventions recommended _
Moderate interventions recommended
POL00458014
POL00458014
WORKING DRAFT
SOLUTION
Evidence (what we have seen and heard)
NBIT transaction engine integrity assurance assessment in May '23 consisted of a scalability analysis, test output and
recommendations of which a suggestion from AWS was to leverage multiple AWS accounts per environment as best practice
to avoid hitting single account hard limits causing a future blocker to scalability
While the multi-account recommendation has been accepted it has not been actioned thus far and has a ROM estimate cost
(IMn) and effort (6-9 months) associated to remediate with support from AWS professional services (Pro Serve) which
includes a detailed AWS platform assessment & target design (2 months) and resident advisory team to assist with
implementation (4 months)
Security requirements are not standardised across the NBIT Architecture, impacting programme health and increased attack
surface
No clear security technology strategy for NBIT
Security currently operates in an advisory and reactionary way due to limited capacity, skills and North-Star
No defined Journey to Cloud strategy and aligned security vision (i.e. North-Star)
Security staffing shortage, (Example: three POL Security personnel assigned to SPM programme), forcing multiple
engineering, architectural, governance and advisory disciplines for a single resource, this compromises quality of output
and time to solution
Security resources are not always engaged at the start of the engineering process
Security tooling decisions are not controlled by Security Domain, e.g. moving from Snyk to GitHub Actions for Static Code
Scanning
CTO/TDA function owns security technology stack, resulting in non-security trained resources managing and operating
security technologies
Limited or no interventions recommended —_ Copyright © 2023 Accenture. All rights reserved, 86
POL00458014
POL00458014
WORKING DRAFT
z
2
=
=
=
fe)
on
87
Copyright © 2023 Accenture. All rights reserved
Limited or no interventions recommended
In Release 2 NFT the expectation is to have 2 branches operational, however performance testing has been conducted and
validated for 50 branches
Arecent AWS well-architected review (WAR) of the NBIT account resulted in multiple recommendations towards maturity of
workload - out of the 6 pillars in the WAR framework, Reliability pillar scored the lowest with high risks
NFRs for full scale branch rollout has been defined as 11500 branches, this will be used as a basis for performance testing
No NFT resiliency/reliability in R2 test scope
A recommendation from the NBIT Release 2 non-functional testing requests specific client-side performance monitoring
when the programme moves to a full-scale roll out
analysis be undertaken and later defined as business NFRs for upcoming releases to get full holistic view
NBIT NFT Component Test Approach has been defined and includes Resilience/Chaos testing however this has not been
All defects reviewed relating to performance and agreed none are critical for R2.0
executed or rolled out across the programme
Evidence (what we have seen and heard)
3
3
E
8
S
2
3
3
2
Testing (NFT) passed within the
agreed SLAs demonstrating
expectations without any major
issues however performance
testing should be executed
before moving to scaled roll-out
A resiliency non-functional test
strategy is captured, along with
a test approach, however the
native serverless architecture
presents challenges for testing
technical KPIs around
availability and resilience as the
systems are managed by AWS
and are elastic to load and stress.
conditions
NBIT Release 2 Non-Functional
performance in line with
Observation
Level 3
OBSERVATIONS (10/14)
4.4 NON-FUNCTIONAL REQUIREMENTS
3
52
Be
£8
as
8%
2a
Level 2
44
(continued)
POL00458014
POL00458014
WORKING DRAFT
z
2
=
5
al
fe)
on
OBSERVATIONS (11/14)
4.5 DATA
Evidence (what we have seen and heard)
Observation
Level3
Level2
Data and Reporting Strategy is.
very limited, it focuses on
Data Strategy and associated data commandments have been defined but not all NBIT services/solution adhere to these
commandments
shipping data flows from NBIT
into the legacy reporting
service. There are no specific
capabilities within the NBIT
Advanced MI/BI and Analytics use-cases have been excluded from NBIT scope, instead focus is on canned operational
reports from Legacy Systems. This approach may limit the continuous monitoring and identification of process/data
anomalies and improvement opportunities
architecture that derive insights
and value from NBIT data
NBIT Data architecture is physicalised over object storage, nosql and RDS
Data Lifecycle management
policies are not fully
Documentation on data schemas/tables across the NBIT Solution does not follow a consistent structure
implemented across the solution
which introduces risk of
Data retention principles have been defined but product/service level policies have not been defined or implemented
increased cost and potential for
performance issues
Data lifecycle management have been defined at an S3 bucket level but there are no similar policies for DynamoDB and RDS.
Data Dictionaries and Models are
Data models and entity level dictionaries have been documented for each subject/functional domain however these models
are not connected and do not readily support impact assessment of changes to data structures
the risk of data inconsistencies,
There is no central data dictionary or catalogue that provides attribute level definitions of data utilised by the NBIT solution.
This increases the risk of data inconsistency /duplication of attributes across the solution while also increasing the
dependency on functional/development teams to support data discovery and downstream data analysis
and increases the effort/reliance
on product teams to support
impact assessment of data
changes
88
Copyright © 2023 Accenture. All rights reserved.
Limited or no interventions recommended
Management of Data across environments and domains has not been standardised introducing variability across the software
delivery lifecycle. This variability makes it difficult to reproduce known errors and introduces new data related errors
While a NFR framework has been centralised for more complex testing, itis the Individual teams that are responsible for
defining and loading synthetic data
Moderate interventions recommended
environments introduces risk of
Limited Data Management
variability and increases the
brittleness of environments
Processes across the
> ED rcdotinivions i I ignificant interventions recommended
POL00458014
POL00458014
WORKING DRAFT
2
°
=
=)
al
fe}
on
OBSERVATIONS (12/14)
4.6 CODE
Evidence (what we have seen and heard)
Observation
Level 3
Code analysis services (Sonarcube etc.) are not implemented consistently within the Cl/CD pipelines which
increases the risk of security and quality issues being introduced into the codeset
The NBIT Engineering teams and Build Better Initiative have produced guidelines and made significant progress
in creating both API contracts and Stub Modules across the NBIT solution. These are key enablers to rapidly and
consistently test the integration between NBIT services and between the NBIT application and NBIT Core
services
Contract Testing solution (PACT Broker) is currently in the PoC stage and has yet to be established across all
Best Practice/Standards and Guidelines have been documented for all programming languages and specific
development teams
cloud services utilised by the solution
inconsistent Code Management and branching strategies reduces ability to standardise and automate
Development teams have moved from a MonoRepo approach to multiple repos for each functional area
build/test pipelines
roducts/services is improving due to the
reation of stub modules and API contracts
however there are gaps that need to be
3
2
8
S
4
2
zg
5
3
2
g
®
B
fo
8
2
8
3
5
a
E
8
oO
monitored or enforced resulting in reduced
code quality
dynamically allocate resources across teams
addressed and contract testing needs to be
established across the teams
development and management of code
increases the onboarding effort for new
resources and reduces the ability to
Dependency management across
Limited standardisation across the
pl
cl
ae ees
89
Copyright © 2023 Accenture. All rights reserved.
Limited or no interventions recommended
> @ RAG Definitions i I Significant interventions recommended Moderate interventions recommended
POL00458014
POL00458014
WORKING DRAFT
z
2
=
5
al
fe)
on
OBSERVATIONS (13/14)
4.7 INFRASTRUCTURE
Evidence (what we have seen and heard)
Observation
Level3
jes ongoing to resolve low bandwidth/high latency branch connectivity in
No current network strategy, vision or roadmap (Enterprise or NBIT) - The branch WAN has a 99% MPLS based transport
solution which has more than cost drawbacks associated for such a large distributed wide area network e.g., 11k+ sites
The existing branch router/device are proposed for R2 network connectivity without replacement; however, the target state
Hardware in scope of NBIT consists of in-branch devices such as EPOS counter terminal, printers, scanners, card reader and
solution is not confirmed
NBIT scalability improvements have been recommended to move workloads to an AWS multi-account strategy to support
so on that allow the services offered to be fulfilled
account segregation and to avoid hitting single account hard limits causing a future blocker to scalability
remediations) and 12 Amber risk recommendations. All findings and recommendations have management responses,
Recent AWS well-architected review of NBIT account resulted in multiple recommendations towards maturity of the
alongside fixes for classified as short and long-term fixes which are also managed through Jira tickets
workloads which are being managed through Jira tickets by the Architecture team
The recent Credera Transaction Integrity report highlighted 17 recommendations: 5 Red risk findings (prioritised
IP address management is currently managed in-house by POL utilising NetBox software tool, however there is limited
Network solution preparation and readiness for NBIT release delivery has been well planned with close collaboration
governance in place which could result in ad-hoc IP address allocation and duplicate IP conflicts as an example
with security advisory with threat models being developed to help drive out any service specific requirements
NBIT network monitoring and remediation acti
readiness for future release deployments
2 g 5
gx 2 vax SB> § oo 3
3x 2 $3
Softeze Soo 29 £8 2
BSEset sy ge 2 Sé 3
82578355 2en8 26 52
= é 3
B25C0E9 os? € 28
Se ees esa Sege af 654
e2essasg soso g Bee
ertaeeee e882 85 S88
S2So9523 S388 35 533
Esser gge Beese ge g2e
Sesuk ee Seads a
8e2eocE° Bgeese Soe
SRLEZSS Dn oes oe ee 522
Sfagnsese ZSSESES S55
Eseecesse gee Euss £88
B5Egs32R zoe S SEs 23
OeSolsess Os egrse O53
286282582 foeleas 282
90
Copyright © 2023 Accenture. All rights reserved.
Limited or no interventions recommended
Moderate interventions recommended
> ED rcdotinivions [Bf sioniicantincerventions recommended :
POL00458014
POL00458014
WORKING DRAFT
1
z
2
=
5
al
fe)
on
Copyright © 2023 Accenture. All rights reserved.
Limited or no interventions recommended
The latest transaction integrity assurance actions resulted in 11 amber status observations actions of which 6 relate to logging
and monitoring, an area of the programme that is currently behind schedule
NBIT data retention policies are captured in a variety of forms and locations in Confluence by different teams such as Service
bandwidth WAN connectivity e.g., collecting and sending logs outside of standard retails working hours to reduce impact to
Operations, Tech Platforms, Architecture and Cloud Office
The NBIT Transaction Engine is currently supporting more than 300 branches in a live production state for Drop & Collect
and Release 1. Furthermore, release 2 will be rolling-out to a maximum of 50 counters across a maximum of 50 branches
which increases the demand for observability monitoring
There is a strategic observability solution selected to help achieve NBIT observability as ‘DataDog’ currently undergoing a
POV and has not been rolled out fully across the NBIT service. DataDog has financial constraints for mass scale branch
connectivity
deployment (licensing cost) as well as network bandwidth considerations to consider for branches with low
Ata solution level the NBIT Reconcillation Service has DB Data Retention and Archival process and policy captured,
The observability capabilities available within AWS (CloudWatch, etc.) as well as some bespoke development will
whereas other solution designs do not have this captured at a product level
be deployed as a tactical solution to ensure customer journey completion can be logged
Evidence (what we have seen and heard)
Moderate interventions recommended
of
There is currently a tactical
observability solution in place
whilst live production services
are in run state which limits the
extent of performance
monitoring and effectiveness of
troubleshooting/ debugging ~ A
full observability strategy should
be in place prior to a complete
branch roll-out
imited visibility or design on
fata lifecycle, archiving and
.
.
Level3
OBSERVATIONS (14/14)
4.7 INFRASTRUCTURE
Level2
inte
(con
> ED rcdotinivions [Bf sioniicantincerventions recommended :
POL00458014
POL00458014
WORKING DRAFT
RECOMMENDATIONS (1/10)
4.1 OPERATIONS ARCHITECTURE
Tower Proposed Mapping to
Observation Recommendation Priority summary Rec.
a Rec4.1A) Operation Priorities & Support Structures - Apply automation to processes by
4.1.1) Operation priorities, frameworks and developing an Infrastructure as Code (laC) approach and establish processes to keep system #12
runbook follow a standardised template and operations people-independent. Document all aspects and keep operational runbooks updated
are stored centrally in a well-
maintained repository Rec4.1B) Prepare for Workloads - Automate the review process by introducing code scan tools
into the CI/CD process. These tools should be configured to look for coding standards, security v
4.1.2) The “Build Better” improvement plan policies, and audit controls, and fail the build process if a certain threshold of security, quality, and #24, #25
project is addressing the historical complex, compliance is not achieved. The build process should also be configured to automatically update (Underway)
error-prone and manually any enterprise asset management system or configuration management database (CMDB)
intensive development and implementation
processes however effort is required to Rec4.1C) Operate Workloads - Establish an operations baseline and setup alerting when
accelerate the execution and adoption operations outcomes are at risk or when anomalies are detected:
across the programme Identify KPIs and define workload metrics to measure the achievement of KPIs
- + Establish baselines for metrics to compare and identify under and over performing Vv #24, #25
_ 4,1.3) Limited standardisation of performance components
I and cost metrics coupled with an inconsistent + Establish expected patterns of workload activity to determine and alert when workload
"alerting approach reduce the transparency of outcomes are at risk
the solution and the ability to detect anomalies
4.1.4) Historical challenge to dedicate time to
address technical debt and support
continuous improvement opportunities,
however the ongoing Build Better initiative has
started making a difference in some areas with
some work to go in the proposed plan
Rec4.1D) Evolve to Support Workloads - Perform regular retrospective analysis
of operations metrics to later use the insights to identify opportunities for improvement
#24, #25
and potential courses of action. Allocate time to make the improvements as part of a continuous
4.1.5) No Cost Management strategy or improvement ethos
processes to support variable Cloud Costing
model
Limited or no interventions recommended Copyright © 2023 Accenture. Alll rights reserved. 92
Moderate interventions recommended
> @ RAG Definitions i I Significant interventions recommended
POL00458014
POL00458014
WORKING DRAFT
RECOMMENDATIONS (2/10)
4.1 OPERATIONS ARCHITECTURE
‘i ‘ Tower Proposed Mapping to
Observation Recommendation Priority summary Rec.
4.1.1) Operation priorities, frameworks and
runbook follow a standardised template and
are stored centrally in a well-
maintained repository
4.1.2) The “Build Better” improvement plan
project is addressing the historical complex, Rec4.1E) Cost Management - Define a FinOps approach which constitutes four major practices:
error-prone and manually identify what POL owns, optimise resources that you need, plan and track spending, and execute
intensive development and implementation _policies that align with POL's financial goals.
processes however effort is required to 1. Implement Cloud Financial Management
accelerate the execution and adoption + Create a team that is responsible for establishing and maintaining cost awareness
across the programme + Establish cloud budgets and forecasts for workload
+ Monitor cost proactively
4.1.3) Limited standardisation of performance 2. Govern Usage Vv 18,421
_ and cost metrics coupled with an inconsistent + Track project lifecycle .
alerting approach reduce the transparency of + Implement cost controls based on organisation policies and defined groups and roles
the solution and the ability to detect anomalies 3. Monitor Usage and Cost
+ Configure billing and cost management tools
4.1.4) Historical challenge to dedicate time to + Configure Cost and Usage report to provide detailed cost and usage information
address technical debt and support + Configure your workload to log entries for every business outcome
continuous improvement opportunities, + Implement billing/cost tagging across all resources to group costs and usage
however the ongoing Build Better initiative has according to organisation attributes
started making a difference in some areas with
some work to go in the proposed plan
4.1.5) No Cost Management strategy or
processes to support variable Cloud Costing
model
> @ RAG Definitions i I Significant interventions recommended Moderate interventionsrecommended —_ Limited or no interventions recommended — Copyright © 2023 Accenture. All rights reserved. 93
RECOMMENDATIONS (3/10)
4.2 SOLUTION ARCHITECTURE
Level 2 Observation
4.2.1) There is no explicit technical vision and
roadmap defined for the NBIT solution, instead
the SPM Programme vision and High-Level
Release plans are driving the evolution of
the technical capabilities
4.2.2) Architecture principles, standards and
constraints/guardrails have been newly
defined for NBIT in some areas, whilst also
adopted from existing POL Enterprise
Architecture and Cloud Security Principles
4.2.3) The NBIT architecture capability has
been built up over time with the establishment
of resources, processes, and roles to support
the programme with further opportunity to
assess and develop the capability further to
make improvements in areas that require
attention, such as architecture compliance and
_ governance at the delivery phase
> ED rcdotinivions [Bf sioniicantincerventions recommended -
POL00458014
POLO0458014
WORKING DRAFT
‘ Tower Proposed Mapping to
Recommendation Priority Summary Rec.
Rec4.2A) Vision & Roadmap - Document solution vision and roadmap which describes the
desired future state and the steps to achieve, alongside the wider SPM programme vision Vv #2, #3,
definition
Rec4.2B) Architecture Principles & Constraints - identify, review and document applicable
architecture principles and policies. Continually review and update existing architecture standards Vv #10, #12
and guardrails through the Architecture Review Board (ARB)
Rec4.2C) Technical Architecture Governance - Reevaluate TDA membership to reduce
attendance to 10 voting members, ensuring representation across the key stakeholder
groups. Input materials to the TDA Board meeting should be made available for members to #10
read at least two days in advance
Limited or no interventions recommended Copyright © 2023 Accenture. Alll rights reserved.
Moderate interventions recommended
SOLUTION
94
RECOMMENDATIONS (4/10)
4.2 SOLUTIONS ARCHITECTURE
Observation Recommendation
POL00458014
POL00458014
WORKING DRAFT
SOLUTION
Mapping to
Summary Rec.
Tower Proposed
Priority
4.2.4) Architecture solution design (HLD) exist
across various NBIT products/services and
domain lead architects are embedded within
product delivery teams; however alignment of
low-level design (LLD) and implementation is
not guaranteed nor traceable due to missing
implementation artefacts and non-continual
collaboration
4.2.5) An architecture & design governance
process has been established with controls in
place that produce architectural artefacts,
however stricter management and controls
are required at the implementation phase to
ensure compliance and traceability back to
high-level design to avoid misalignment
4.2.6) Compliance with security regulatory and
best practice requirements are not in line with
modern practices and frameworks, resulting in
misconfigurations, solutions that are not fit for
purpose and increased implementation
timelines
> @ RAG Definitions i I Significant interventions recommended
Rec4.2D) Technical Architecture Governance - Create an additional technical architecture
governance layer below TDA, namely a Design Authority (DA) in each product workstream
led by domain lead architects for improved architecture alignment and compliance with
engineering teams
Rec4.2E) Security & Compliance - Identify regulatory and industry best practices to comply with
e.g. NCSC - Cyber Assessment Framework. Vv
Develop a baseline set of control frameworks and matrixes that can be leveraged in a bespoke
manner dependent on use-case, landscape and delivery team
#10
#12
___ Moderate interventions recommended —_Limited or no interventionsrecommended Copyright © 2023 Accenture. All rights reserved. 95
RECOMMENDATIONS (5/10)
4.3 DEVSECOPS & ENVIRONMENTS
Level2
2
=
Fi
5
=
z
2
a
c
Py
2
g
é
¢
a
9
¢
> @ RAG Definitions [Bf sioniicantincerventions recommended -
Observation
4.3.1) Development principles and processes
have not been standardised across the various
product/platform service teams this introduces
both dependencies between teams, increases
defects, and reducing delivery velocity
4.3.2) Security principles, whilst defined, they
are not integrated or recognised as critical
within the solutioning phases of
the programme, impacting the overall health of
the solution with an increased attack surface
and decreased traceability or observability
4.3.3) Standard operations metrics have not
been defined and implemented consistently
across the NBIT solution impacting the ability
to operate the service in line with defined SLAs
4.3.5) The environment strategy has not been
fully operationalised and does not readily
support a multi-speed/multi-team model and is
impacting the ability to deliver stable and
secure products and services
POL00458014
POL00458014
WORKING DRAFT
SOLUTION
Recommendation Tower Proposed Mapping to
Priority Summary Rec.
Rec4.3A) Cl/CD Pipelines - Accelerate adoption of standardised Cl/CD pipelines that utilise Vv
D Pipelines ~ y #24, #25
agreed strategic tooling (GitHub Actions, Advanced Security etc.) across NBIT teams (Underway)
Rec4.3B) Resource Tagging ~ Implement consistent Resource Tagging Strategy across NBIT
4 A #24, #25
covering Functional, Operational and Cost Hierarchies
Rec4.3C) NBIT Alerting Service - Define Alerting Standards and Framework. Document rules, #2
scenarios, thresholds and recipients for key services and rollout across product/service teams
Rec4.3D) Establish new Environments - Define Environment templates and associated refresh
processes. Integrated with Cl/CD pipelines and rebuild Environments to agreed states in alignment Vv #24, #25
with a signed off environment strategy
Rec4.3E) Security Principles ~ Define and integrate a set of principles that are enforced at the Vv 424, #95
Enterprise Architecture level, ensuring secure by design and a security first approach by default ’
I" Moderate interventions recommended _Limited or no interventionsrecommended Copyright © 2023 Accenture. All rights reserved 96
RECOMMENDATIONS (6/10)
4.4 NON-FUNCTIONAL REQUIREMENTS
POL00458014
POL00458014
WORKING DRAFT
SOLUTION
‘Tower Proposed Mapping to
Level2 Observation Recommendation Priority summary Rec.
Rec4.4A) NFR Management - Appoint individual/team accountability to manage NFRs.
4.4.1) Non-functional requirements are Implement NFR traceability via linkage to associated tickets in Jira to track the relationship Vv #12, #24, #25
captured inconsistently across between requirements and associated deliverables such as HLDs, LLDs, test cases, and code
the programme, along with no individual or
; team accountable to manage nor a centralised
2 traceability tool, resulting in limited controls to
EIPRES ensure NFRs are incorporated in end-to-end
3
£ >
itt 4.4.2) An integrity assurance assessment for
Fala the NBIT platform has highlighted a set of
2 as recommendations to improve the platform
Figs scalability which should be considered before Rec4,4B) Scalability - Create a detailed plan of action and execute next steps to remediate NBIT v #24, #25
Fereee the solution scales platform scalability improvements as highlighted in the Transaction Integrity Assurance Report "
33
@ 5
: B99) 4.4.3) Security governance mechanisms and
Fafa frameworks are ineffective as the need for on
EERO time delivery outweighs a security first and
< secure by design approach. Resulting in
< spontaneous technology procurement
and security exemptions by default. This
approach may lead to re-engineering elements
of the solution to adequately integrate Rec4.4C) Security - Create a governance model, operating model, defined RACI and
security processes, technologies and skills integrational model that establishes a set of front door processes and ways of working with POL Vv #24, #25
internal and external stakeholders. Thus, standardising output, expectations and ways of working
> @ RAG Definitions i I Significant interventions recommended Moderate interventions recommended —_Limited or no interventions recommended Copyright © 2023 Accenture. All rights reserved. 97
RECOMMENDATIONS (7/10)
4.4 NON-FUNCTIONAL REQUIREMENTS
Level 2
8
=
§
5
s
3
z
g
2
3
5
3
2
5
fo
é
5
2
$
t
> @ RAG Definitions [Bf sioniicantincerventions recommended -
(continued)
Observation
4.4.4) NBIT Release 2 Non-Functional Testing
(NFT) passed within the agreed SLAs
demonstrating performance in line with
expectations without any major issues
4.4.8) A resiliency non-functional test strategy
is captured, along with a test approach,
however the native serverless architecture
presents challenges for testing technical KPIs
around availability and resilience as the
systems are managed by AWS and are elastic
to load and stress conditions
Recommendation
Rec4.4D) Performance - identify and prioritise business use scenarios and applicable
performance scenarios, which should then be mapped to each of the business-critical processes.
The scenarios should be compiled based on interviews with the business and by analysing
historical data. The scenarios should be prioritised based upon their importance and occurrence
probabilities. Finally, each of these scenarios should be mapped to a design principle that should
be implemented
Rec4.4E) Resiliency - Execute modern-day software engineering practices such as chaos
engineering to proactively identify and resolve platform issues in production before they impact
the end-users in branch. Use playbooks to investigate failures. Perform load testing to validate that
the workload meets scaling and performance requirements and conduct regular game days.
‘At a workload level RTO and RPO of the workload should be defined along with a DR strategy and
application architecture updated accordingly. Test failover to DR to ensure that RTO and RPO are
met
_ Moderate interventions recommended —_Limited or no interventions recommended
POL00458014
POLO0458014
WORKING DRAFT
SOLUTION
Mapping to
Summary Rec.
‘Tower Proposed
Priority
#24, #25
#24, #25
Copyright © 2023 Accenture. All rights reserved 98
POL00458014
POL00458014
WORKING DRAFT
z
2
=
=
=
fe)
on
RECOMMENDATIONS (8/10)
4.5 DATA
Mapping to
Summary Rec.
iori
‘Tower Proposed
ity
Recommendation
Observation
Level 2
#2
DataOps pipeline. Review scope decision regarding advanced MI/BI reporting as could deliver
Rec4.SA) Data Strategy - Review Data Strategy, Define and Build Data Assets. Define and Build
significant insight and value to POL
NBIT into the legacy reporting service. There
are no specific capabilities within the
NBIT architecture that derive insights and
4.5.1) Data and Reporting Strategy is very
value from NBIT data
_ limited, it focuses on shipping data flows from
4.8.2) Data Lifecycle managernent policies are
not fully implemented across the solution
hich introduces risk of increased cost and
"potential for performance issues
wi
#24, #25
Rec4,5B) Enhanced Data Dictionaries - Define Data Dictionaries covering the Physical Data
‘Schemas/Tables (inc. Acceptable Data Values) across the NBIT Solution
fully defined, this introduces the risk of data
4.5.3) Data Dictionaries and Models are not
inconsistencies, and increases
the effort/reliance on product teams to
support impact assessment of data changes
4.5.4) Limited Data Management Processes
across the environments introduces risk of
variability and increases the brittleness of
environments
#24, #25
Rec4.5C) Synthetic Data Management - Develop Synthetic Dataset and deployment processes
to support Environment provisioning (Data Preparation) and Test Automation
99
Copyright © 2023 Accenture. All rights reserved.
Limited or no interventions recommended
Moderate interventions recommended
> ED rcdotinivions [Bf sioniicantincerventions recommended a
RECOMMENDATIONS (9/10)
4.6 CODE
Observation
4.6.1) Compliance to code standards/policies
is not monitored or enforced resulting in
reduced code qu
4.6.2) Dependency management across
products/services is improving due to the
creation of Stub modules and API contracts
however there are gaps that need to be
addressed and contract testing needs to be
established across the teams
4.6.3) Limited standardisation across the
development and management of code
increases the onboarding effort for new
resources and reduces the ability to
dynamically allocate resources across teams
> @ RAG Definitions i I Significant interventions recommended
Recommendation
Rec4.6A) Code Quality - Establish consistent static code analysis and code quality reporting by
integrating Strategic Code Analysis tooling (SonarQube/GitHub Advanced Security) within the
CI/CD pipeline. Maintain code quality by mandating that all findings must be addressed as part of
a pull request
Rec4.6B) Stub Modules/Framework - Define Stub Framework and associated Stub Modules
across code sets. Ensure adoption of stubbing across all engineering product/ platform services
team by mandating the use of stubs within automated CI/CD pipelines
Rec4.6C) API Contracts - Continue with the creation of API contracts for all APIs, updating
central documentation in line with template
Rec4.5D) Contract Testing - Establish contract testing using PACT Broker across development
teams to improve management of dependences across development teams
__ Moderate interventions recommended —_Limited or no interventions recommended
POL00458014
POL00458014
WORKING DRAFT
SOLUTION
Tower Proposed
Priority
Mapping to
Summary Rec.
#24, #25
Vv #24, #25
v #24, #25
(Underway)
Vv #24, #25
Copyright © 2023 Accenture. All rights reserved. 100
RECOMMENDATIONS (10/10)
4.7 INFRASTRUCTURE
Observation
4.7.1) No major concerns or issues
captured related to network overall, however it
is worth noting, that the branch wide
area network service has a reliance on
expensive MPLS circuits which is not in-line
to achieving a future-proof roadmap
4.1.2) Previous solution
architecture diagnostic/assurance study
findings have provided recommendations in
various areas for NBIT platform improvement
which is underway or future planned
4.1.3) No major observations, concerns or
issues captured related to hardware
4.7.4) There is currently a tactical
observability solution in place whilst live
production services are in run state which
limits the extent of performance monitoring
and effectiveness of troubleshooting/
debugging - A full observability strategy
should be in place prior to a complete branch
roll-out
4.7.8) Limited visibility or design on data
lifecycle, archiving and data retention across
the solution
> @ RAG Definitions i I Significant interventions recommended
Recommendation
Rec4.7A) Network Vision, Strategy & Roadmap - Review network strategy and roadmap for
branch WAN and evaluate SD-WAN & SASE solutions to achieve an agile, scalable and reliable
infrastructure with cost savings
Rec4.7B) Integrity Assurance - Create a detailed plan of action and execute next steps to
remediate transaction engine platform serverless architecture scalability and performance issues
Rec4.7C) Observability Software - Define Datadog CDK construct templates. Update NBIT stacks
to include new constructs
Rec4.7D) DLM Processes - Define and Implement data lifecycle management processes (DLM)
across all data storage services ($3, RDS, DynamoDB) in NBIT
Moderate interventions recommended Limited or no interventions recommended
POL00458014
POL00458014
WORKING DRAFT
SOLUTION
‘Tower Proposed Mapping to
Priority Summary Rec.
#24, #25
Vv #24,
v #24, #25
(Underway)
#24, #25
Copyright © 2023 Accenture. All rights reserved. 101
POL00458014
POL00458014
WORKING DRAFT
111.5 I IMPLEMENTATION
REVIEW DETAIL
Copyright © 2023 Accenture. Allrightsreserved. 102
SUMMARY OF OBSERVATIONS
IMPLEMENTATION LEVEL 2 AND LEVEL 3 CAPABILITY RAG RATINGS.
LEVEL 2 CAPABILITY
> ED racootin ions [Bf sioniicantincerventions recommended
esign &
5.1.2 Design
principles
! Bomponent Arch
2.1 Demand
{ planning
2.2 WoW (JIRA
puide & quality,
erf tracking)
5.2.3 DevSecOps
ipeline/laC. SAST
5.3.1 Test
} 5.4.1 Env control &
Release strategy
5.5.1 Data &
legacy systems
strategy/
approach.
5.6.1 Post Go Live
support approach
{5.7.1 Live service
I transition strategy
iJapproach
Moderate interventions recommended
strategy/approach
3.2Test
poverage
5.3.3Test
itomation
5.4.2 Deployment
Bpproach
55.2 Data
conversion,
tooling, format &
con
5.6.2 Knowledge
transfer
5.7.2 Live Service
4.3Go Live
riteria
5.3 Data storage
f security
5.6.3 Go, No-Go
Criteria
5.7.3 Knowledge
transfer
5.14 Platform
Design
5.2.4 Dev
principles
POL00458014
POL00458014
WORKING DRAFT
IMPLEMENTATION
xecution &
3.4 Test planning]
eporting
5.4.4 Release &
deployment plan
5.5.4 Connectivity
to legacy & 3
party systems
5.6.4 Comms,
Contingency, Roll
back Plans
5.7.4 User
‘communications
& training
Limited or no interventions recommended
525 Backlog &
dependency
management
Test data
ement
5.45 Live servic
Entry criteria
555
interdependency
approach/ to
assure stability.
5.6.5 Monitoring/
Alerting /
Observability
5.7.5 1TSM
‘Manai
2.6 Environments}
3.6 Defect
ment
I 8.7.6 Performance
I Bvalue tracking
5.27 Coding
standards &
‘control
5.3.7 UAT (BVT)
Copyright © 2023 Accenture. All rights reserved.
103
OBSERVATIONS (1/15)
5.1 DESIGN
Level2 Level 3
6.1 Design
(continues on
next page)
5.1.1 Low-Level
Design &
Component Arch
> @ RAG Definitions [Bf sioniicantincerventions recommended -
I Moderate interventions recommended
Observation
Architecture high-level designs exist, and
there are embedded architects in some
delivery squads, however, there is a
disconnect in detailed technical design for
some squads due to a lack of suitably
qualified technical business analysts and
involvement from key data and security
contributors
Design Principles have been created and
captured in Confluence, however adherence
to these principles has been inconsistent
across engineering teams which leads to
fragmentation and inconsistencies in delivery
vi
POL00458014
POL00458014
WORKING DRAFT
IMPLEMENTATION
idence (what we have seen and heard)
Gaps in Low-Level Design exist (completely missing and/or poor quality as identified in the Slalom report).
Work is in progress to remediate through the Build Better initiative
Engineering capacity is diverted to remediate the design gaps as well as technical debt,
Ability to estimate the scale of remediation required is hampered by the inability to trace defects and technical
debt back to Low Level designs and associated artefacts
The historic pressure to deliver releases to set dates has resulted in additional changes being added mid-sprint
without Low Level designs reflecting these changes. The lack of updates has further inhibited the
understanding of build and low-level design impact on High level designs
Gaps identified include lack of NFRs, Security and data requirements, BI metrics ete
Inconsistency in quality of Low-Level Designs seen in Branch Management indicating that some designs follow
a templated approach that aligns to design principles, but with varied review approval evident; Some cannot
be linked to clear requirements, and some were retrospectively created or have already been deployed, other
work items in JIRA cannot be traced back to a low-level design
For example, 80% bugs in Branch Management, 36% bugs in mails (source JIRA 20230928) are a result of
inconsistent application of design principles
Evidence of non-adherence to design principles was observed for example, out of 100 UX/U! components, only
70% can be used and 30% cannot, resulting in sub-optimal experience for end users. An initial threat
analysis/impact assessment could have prevented this scale of tech debt
Limited or no interventions recommended Copyright © 2023 Accenture. All rights reserved. 104
OBSERVATIONS (2/15)
5.1 DESIGN
Level 2 Level 3 Observation
6.1 Design
(continued)
The TDA process exists and most follow the
process for re-assessment, as and when these
have been delivered without return for
6.1.3 Design approval, this results in quality control issues
etc and negatively impacts the overall
delivery due to non-alignment to high-level
architectural designs. There are initiatives in
place to help remediate some of these areas
Divergence between high-level platform
architecture design and low-level engineering
designs have caused an increase in technical
debt, quality issues resulting in slower delivery
POL00458014
POL00458014
WORKING DRAFT
IMPLEMENTATION
Evidence (what we have seen and heard)
i I Significant interventions recommended Moderate interventions recommended
A standardised TDA process exists and is mandated for the Programme and is used, however the following
issues were observed:
+ Formal standardised impact analysis is not traceable to critical SME decision makers in the TDA, this is
replicated for Low-Level Designs and impacts the wider solution. Experienced Architects embedded in
teams has mitigated some of these challenges for some squads
+ Outputs of the TDA do not consistently drive Low-Level Designs across all engineering teams. Lack of
collaboration between certain engineering teams and architecture, which results in some teams not
producing Low-Level Designs or generating designs that diverge from the architect's vision
+ Example: Basket tender low-level designs are out of sync with the LLD template. In addition, it does
not show any evidence of reviewed by the embedded architect as the process mandates. Evidence in
Confluence
Platform designed to enable Developers/Engineers to use the DevSecOps tools, but they are not used in a
consistent way resulting in mixed code quality during and at the end of build, e.g., the use of SonarQube in CI
Lack of clear vision regarding transformation or modernisation results in Low Level Designers pursuing
individual interpretation of the wider scope
From interviews with delivery teams and the Build Better team, there is a lack of alignment and traceability re
changes made to low-level designs that impact the wider platform components which results in inability to
perform adequate root cause analysis. This is being remediated and we see an upward trend in the reports for
this area
Limited or no interventions recommended Copyright © 2023 Accenture. All rights reserved. 105
OBSERVATIONS (3/15)
5.2 BUILD
Level2 Level3
5.2 Build
(continues on
next page)
5.2.1 Demand
planning
5.2.2 WoW JIRA
guide & quality,
perf tracking)
Observation
Engineering demand is not effectively
captured, estimated, planned, prioritized or
managed across teams, leading to a lack of
alignment on business priorities, inefficient
allocation of resources, and delays in
delivering capabilities. There is a business
demand process that Engineering do not
engage with
There is no Programme
methodology/approach that ties all squads
together to work in a mature Agile way.
Inconsistent capture of key data points,
results in a lack of clear status across the
programme, hindering data driven decision
making
POL00458014
POLO0458014
WORKING DRAFT
IMPLEMENTATION
Evidence (what we have seen and heard)
__ Moderate interventions recommended
> @ RAG Definitions [Bf sioniicantincerventions recommended -
Requirements sit in backlogs outside of JIRA, reducing ability for clear prioritisation and traceability into build
A demand approach at the squad level does not adhere to agile principles; key areas missed include:
+ Requirements in the delivery backlogs do not provide consistent clarity, e.g., include a definition of
done and NFRs
+ Sprint planning includes stories to be worked on, but changes are added mid sprint and squads are
unable to maintain velocity
+ Limited T-shirt sizing or use of story points to enable measurement of performance vs. capacity of
team
+ Standard agile approach of demand pull does not exist impacting ability to clear a sprint backlog
+ Refer to 2.1 (Governance) challenges e.g., heavy up front right to left planning
Historically engineering team resource numbers were increased in the expectation that an increased head
count would enable teams to deliver faster, the lack of estimation and velocity measurement meant the
effectiveness was unquantifiable
A cross-programme maturity and understanding of Agile ways of working including leveraging the tools and
processes does not exist. There are pockets of best practice but no alignment to a programme framework
Incentives for delivery to a set date have negatively disrupted the focus on consistent quality that assure the
future scalability of the platform
The initial setup of JIRA allowed squads to interpret how to use it, leading to inconsistent use of data fields and
items within the tool, e.g.:
+ Two squads using one project in Jira,
+ Incorrect use of Epics, i.e., used to deliver functionality as opposed to a logical grouping of related
stories
+ NERs initially not captured by all, or centralised, and teams use the cloning feature to create NFR as
items in JIRA
+ Some Epics/user stories/issues and defects not linked to releases in JIRA
+ Story points not used so there is no effective way to measure velocity burndown charts and other
widgets in JIRA
+ Defects and dependencies have been created from cloning, resulting in some duplication.
Not all delivery managers are trained on the tool and are unable to leverage metrics for actionable insight
The JIRA instance purchased includes additional functionality for reporting that is not currently used
Additional manual effort required to supplement the limited JIRA generated reports. e.g., performance metrics,
dependency and planning
Limited or no interventions recommended Copyright © 2023 Accenture. All rights reserved. 106
OBSERVATIONS (4/15)
5.2 BUILD
Level 2
5.2 Build
Level 3
(continued)
5.2.3 DevSecOps
pipeline/lac.
SAST
> @ RAG Definitions [Bf sioniicantincerventions recommended I Moderate interventions recommended
Observation
This area is red trending amber; while
remediation is in place, capacity is not
prioritised for this. Inconsistent use, by squads
of CD pipeline and tools is evident through
poor code quality and is reflected by the
number of defects raised
Development principles exist but are not
consistently applied, including; secure by
design (see 5.1.4) definition of
ready/done, following code quality standards
etc result in scope creep and increased
number of defects once code is promoted to
higher environments
Delivery backlogs are not prioritised or linked
to higher level requirements or high-level
designs therefore itis difficult to trace
backlogs back to source or manage
dependencies
POL00458014
POL00458014
WORKING DRAFT
IMPLEMENTATION
Evidence (what we have seen and heard)
+ The Build Better initiative is in progress to address issues, gaps and problems identified in DevSecOps and
engineering space and is not prioritised
+ Improved SAST and DAST automation are in process of being delivered
+ 781 defects raised in E2E testing across releases indicates a high level of defects (feedback from E2E test; it has
estimated that around 10% of these defects are change requests ( i.e., they could not be traced to
requirements), impacting Root Cause Analysis and solutioning timelines)
+ Autornated regression test pack are available for squads to use, but ongoing indications in E2E testing is that
these are not being used
+ As part of the Continuous Improvement (Cl) process the R3 teams were trained up on tools, ways of working,
etc, however teams now disbanded removing the benefits of this effort
+ The current R2.1 teams are not yet fully onboard into the Cl process - at the time of interviews 6 /16 squads had
been trained. This is a work in progress
+ Software Engineering Principles exist including testing standards for Go, React and AWS best practices and
CDK (Cloud Dev Kit)
+ Historical prioritisation of meeting deadlines has resulted in a reduction in quality, with increased risk
exceptions approved
+ Dev principles state that “a thorough understanding of the requirements to be built is required”. However clear
requirements/user stories are lacking in many areas. Therefore, additional Engineering capacity is used to
generate “definitions of done” and “ready” to mitigate this. This is part of the Build Better initiative
+ Pressure on Engineering teams has resulted in shortcuts being taken to achieve deadlines, this is evident in the
high level of tech debt and remediation identified in E2E testing. The root cause for these challenges relates to
code quality assurance through the pipeline
+ Some levels of automation are applied throughout the pipelines. There are still manual steps that resulting in
errors, defects and delays
JIRA epics and user stories exist but are not consistently generated or prioritised (see 5.2.2). Requirements sit
outside of the tool making traceability harder. Prioritisation of delivery work is not clear nor aligned across
workstreams
+ Significant effort put in to collate dependencies, however evidence that non-delivery of dependencies are
resulting in schedule shifts. Dependencies are not effectively tracked in JIRA
+ Dependencies across projects works well in some engineering teams and is personality led
Limited or no interventions recommended Copyright © 2023 Accenture. All rights reserved. 107
OBSERVATIONS (5/15)
5.2 BUILD
Level 2 Level 3
5.2 Build
(continued)
Observation
Environment management is immature as a
capability, issues caused by poor environment
hygiene have led to suboptimal code and
security issues have increased delivery
timelines
Coding standards and controls are insufficient
to assure the quality of code in Production,
placing POL at financial risk due to lack of
effectiveness of the platform and reputational
risk due to data and security risks
POL00458014
POL00458014
WORKING DRAFT
IMPLEMENTATION
Evidence (what we have seen and heard)
+ Development, testing, and production environments are not configured for maximised automated deployment
and integration Evidence shared; 80% of regression testing is now automated, but back office is only 30%
autornated; mails and banking are fully automated
291 Security vulnerabilities have been promoted into higher environments
+ The number of defects seen in SIT indicates poor environment management as developers have highlighted
that deployments have been over-written in this environment
+ Approach and documentation is not up to date, Confluence has multiple pages at varying levels of
completeness
+ Improvements to coding standards have been made in some areas and the Build Better initiative is leveraging
best practice such as 4 eyes assurance behaviours become routine and can prove the efficacy of good
practice
+ Across the Programme, lack of streamlined GIT workflow and effective Cl/CD pipeline combined with poor
coding behaviours (e.g., too many repos created in an unstructured way, lack of code coverage insight) has
resulted in the following:
Code merges in the past have introduced defects and slowed down release velocity
+ An incomplete picture of the risk being carried forward (20230926 IRAM 2 revised framework being stood up
to mitigate)
+ Quality issues with deployments, increasing time and cost to remediate (In production currently there are 300+
critical, over 2000+ high vulnerabilities (Source 20230926 Security assurance); not always clear who
accountable owners are for remediation
+ Security, data and tech debt remediation is not holistic, this has resulted in:
+ Immediate hot fix remediation that generates additional tech debt
+ Security and data siloed fixes increasing risk
> @ RAG Definitions [Bf sioniicantincerventions recommended " Moderate interventions recommended __ Limited or no interventions recommended Copyright © 2023 Accenture. All rights reserved. 108
OBSERVATIONS (6/15)
5.3 TESTING
Level2
5.3 Testing
(continues on
next page)
5.3.2 Test
coverage
> @ RAG Definitions i I Significant interventions recommended
Observation
Test strategy and approach
exist. The principles that the test
strategy refer to are not always
followed
Test coverage metrics are not
consistently available nor
traceable to requirements in
JIRA and therefore there is no
ability to assess coverage across
the programme with
confidence. There is work in
progress to remediate this
Limited test automation in Cl/CD
pipeline used consistently;
although tools are available,
resulting in sub-optimal code
quality
POL00458014
POLO0458014
WORKING DRAFT
IMPLEMENTATION
Evidence (what we have seen and heard)
Moderate interventions recommended
Good quality “living” documentation approved through TDA
There is a continuous improvement initiative in place to address already identified issues
While not all teams apply the guidance provided, the strategy provides a clear approach to test and expectations, the key
gap is behaviours and policing compliance with mandated activities
Improvements to testing are in progress however yet to have a tangible impact on E2E testing. E.g. lack of use of
automated regressions packs by squads (defect remediation in E2E has exceeded 6 months)
Behaviours were impacted due to the drive to hit timeline, if momentum in this area is lost, the teams will slip back into
these behaviours.
Focus on unit test coverage and baselining has been initiated (Source QE report Oct 2023)
Coverage of NFTs (identified as a significant gap across the programme) has moved from 0% to 27%
Evidence of varied shift left testing is reflected in backlog insights (examples PUDO 84% completion with 9% bugs, mails
57% completion, 36% bugs (source JIRA 2230928)
Delays to the dev lifecycle; at System Integration Test (E2E), the number of defects, identified reflects inconsistent test
coverage in lower environments. (e.g., BM E2E testing has 196 code identified issues)
The first integration of major code occurs in System Integration Tests (SIT) environments, a significant number of issues
are then identified indicating less than 80% code coverage
Maximised automation from E2E through Pre-Prod to Prod is missing, Cl/CD tools exist to support Engineers to test E2E
Inconsistent use of automated tools in lower environments and several issues in SIT reflect systemic test challenges in
lower environments
Continuous Improvement initiative to address the gaps; first quarterly report draft indicates some gradual progress
Limited or no interventions recommended —_ Copyright © 2023 Accenture. All rights reserved. 109
109
POL00458014
POL00458014
WORKING DRAFT
OBSERVATIONS (7/15)
5.3 TESTING
Level 2 Level 3 Observation Evidence (what we have seen and heard)
5.3 Testing
(continued) + Availability of device simulators impacts the ability to test teams to test at pace
Test planning for code releases + Test planning for entry into E2E is the first higher environment that integrated code is tested. High levels of defects
into higher environments are reflect lack of rigour in testing in the lower-level environments. In addition, E2E testing has also experienced high levels of
5.3.4 Test gated which provides a level of defects indicating defects move between environments without remediation
planning assurance and insight, with + Inhigher environments, release leads advise that hard code fixes and work arounds have been implemented to remediate
execution & reports available in JIRA. Lower bugs found in £2, increasing tech debt and longer-term risk to the platform
environment testing and + NFRs were not consistently captured across the programme, which resulted in a lack of insight for the generation of NFTs,
reporting has not been creating delays as additional effort was required to remediate these gaps
rigorously applied + Historically, challenges to poor code entry has not been enforceable due to a focus on delivering against milestones. To
remediate this, regression testing packs have been shared with squads, evidence of this uptake has yet to be proven
Test data is generated by each
project, resulting in duplication + Some squads were unclear about who the data controllers are and whom to approach for test data, some generated their
of effort and multiple test data own test data, others spent additional time identifying who to contact, adding time to development stream
sets being used
Limited or no interventions recommended Copyright © 2023 Accenture. Allrights reserved. 110110
i I Significant interventions recommended Moderate interventions recommended
POL00458014
POLO0458014
WORKING DRAFT
IMPLEMENTATION
OBSERVATIONS (8/15)
5.3 TESTING
Evidence (what we have seen and heard)
Observation
Level3
Level 2
2
3
uy
2
3
(continued)
Currently 90+ people attend defect management calls
Duplicated defects have been generated through cloning rather than linking in JIRA therefore hard to track actual status
Root cause analysis is not consistently performed (latest QA data indicates a reduction from 92%
lack RCA to 72%)
Defects and test management in JIRA is inconsistent (some teams reporting defects as bugs, and issues)
Closure of defects using hard code/workarounds, compounding tech debt
S
Bc 2
25
2802
Bees
SBSea
BEB
Bog
oe
22E8
ES=s3
SEDS
852
ese
g2a8
2Sse
3 S2E
asset
Clear and consistent defect terminology and management is not enforced. Severity 1 issues are raised with loosely based
criteria often from BVT
of automation
Evidence of deployments into Prod with defects, and security risk exceptions that are documented
Business Verification Testing has been conducted in parallel with End-to-end testing. Discussions are in progress to
understand what the future UAT approach will be
Training feedback indicates that the system differences from a user perspective are limited at branch level
Unhappy paths are not covered in UAT
BVT runs in parallel with E2E
Testing. Current UAT approach
is in draft. Changes in UAT are
not driven by data insights
Accessibility testing is currently out of scope for testing due to component and build issues in UI/UX
Feedback from those engaged in BVT indicated that work packages are driven by committee not quantifiable evidence
m
m
Copyright © 2023 Accenture. All rights reserved
Limited or no interventions recommended
3
3
E
8
S
2
3
3
2
OBSERVATIONS (9/15)
5.4 RELEASE MANAGEMENT AND DEPLOYMENT
Level2
5.4Release
Management &
Deployment
(continues on
next page)
5.4.3Go Live
Criteria
> @ RAG Definitions [Bf sioniicantincerventions recommended I Moderate interventions recommended
Observation
There is no standard release strategy, it is
currently manual and repeatable but carries
the risk of poor code quality. While
automation tools and controls are being
implemented through to higher environments,
lower environments lack consistency in using
and leveraging these tools to maintain code
quality and developer productivity
Repeatable deployment approach exists, it
involves manual interventions that delay
deployment cycles and limit continuous
delivery capabilities
Go Live criteria are standardised in CAB for
release, however while the process is secure,
effective challenge is not present in the
current decision-making forums. This may
have major repercussions when a release is
deployed to several branches
POL00458014
POLO0458014
WORKING DRAFT
IMPLEMENTATION
Evidence (what we have seen and heard)
Environment Management strategy incomplete and not following best practice thus project faces risk of
defects, delay and failed deployments into Environments. Release managers and developers have advised that
rollbacks in environments are difficult and hot fixes applied to mitigate
Environments prior to E2E test are not effectively controlled evidenced by the high number of defects seen in
£2E testing
Lack of an automated CI/CD pipeline increases the risk of deployment with human errors for manual
configurations. WIP to onboard DataDog to track dependencies in deployment
The current approach to release management is cumbersome and difficult to roll back partially due to the
significant size of the release and environment challenges
Release details are captured in Confluence with a good level of detail including links to designs, where
available, through to open issues in JIRA where projects
Each release has a deployment approach that is repeatable for specific project requirements
There are technical release schedules and evidence of releases completed with supporting documentation
See 5.1.4 - the varied interpretation of scope impacts the potential for non-alignment at Go, No-Go calls for
releases
Go, No-Go decisions have been based on a desire to meet a predetermined date, which resulted in significant
Tech Debt that then has to be remediated rather than incentivising the delivery of a high-quality product
The quality of Go Live is tied back to systemic challenges in the Development lifecycle, i.e., lack of “definition
of done” for requirements and technology standards not being consistently met
The current deployment plan is recognised by POL as immature but has been sufficient for 2 branches.
Lessons identified in the Pilot will inform decisions for the future deployment to other branches
Limited or no interventions recommended Copyright © 2023 Accenture. Allrights reserved. 112
POL00458014
POL00458014
WORKING DRAFT
OBSERVATIONS (10/15)
5.4 RELEASE MANAGEMENT AND DEPLOYMENT
Level 2 Level 3 Observation Evidence (what we have seen and heard)
5.4 Release j
Management &
Deployment
(continued)
Releases into Production have been - I
completed and include a high number of + Release plans for previous releases have included detailed cutover plans
sues and vulnerabilities that have been + Release schedules exist but are not built on estimated effort required; they are built on right to left planning
called out. The plans and schedule are + The next release will pilot into 2 Post Offices and then ramp up to 50. The key question is how this would scale
available, the confidence that scope is up to 50, and in turn 11,500 Post Offices. That has not yet been answered
achievable is an open question
+ Confluence Route to Live checklist and release management documents indicate they are WIP and/or out of
date. It is assumed that these were initially generated for previous releases but not used as NBIT aligned to POL
policy for Live entry
POL provides Live Service entry criteria for all releases and SPM aligns with this, however NBIT success criteria
are poorly defined
Releases into live have followed POL guidance
with the project providing Hypercare and POL
service support shadowing initiated, while this
area is immature, steps to remediate are in
progress and including a TOM that draws the +The first Pilot and subsequent deployments are planned to be used to inform future scaling across all branches
NBIT and POL teams together to achieve an + Hypercare will need to transition to POL service support, there is a recognised risk that without this transition
enduring process the Project team's capacity will be impacted with the increase in branches that the platform serves
+ Training plans for postmasters and other end users has been prepared
_ Moderate interventionsrecommended —_Limited or no interventionsrecommended — Copyright © 2023 Accenture. Alll rights reserved. 13
> @ RAG Definitions [Bf sioniicantincerventions recommended -
POL00458014
POL00458014
WORKING DRAFT
OBSERVATIONS (11/15)
5.5 CONVERSION
IMPLEMENTATION
Level 3 Observation Evidence (what we have seen and heard)
Level2
+ No overarching data strategy for the programme exists, resulting in duplication of effort for some programme
areas and lack of guidance for wider data/information management for the future. This has been accepted by
Lack of a data strategy has been accepted as a ; A
oY P the Programme Leadership as there is a wider POL stream of work in progress
gap across the programme. Most data
> @ RAG Definitions [Bf sioniicantincerventions recommended -
requirements are maintained through
individual business workstream areas.
Duplication of work is not considered
extensive. Gaps in data requirements are not
consistently managed
Data requirements have been captured, but
most data is handled by 3’ party systems
Limited evidence of a joined-up
understanding of data and security
requirements driving risks to POL and 3" party
stakeholders
3rd party connectivity is currently managed
ona case-by-case basis with development
teams.
The programme approach is to use the dual
running phase with the legacy system to
assure and remediate any residual
interdependencies. No data is shared.
_ Moderate interventions recommended
+ High level arch includes data management requirements. Ad hoc low-level design includes data management
rigour however this is inconsistent, and it is not clear how this is assured (high level designs are approved by
data manager at TDA), limited evidence that this is replicated at low-level design, and assurance provided
The high-level architecture reflects the touch points with the main legacy system (including key data
repositories)
Other third-party systems are considered on a case-by-case basis
Most data is handled by 3" party systems and no requirement therefore to convert, format or configure data
POL data requirements were completed at the start of the Programme
Currently areas such as "test data use” have already seen duplication of effort and is accepted by the
programme
Architecture high-level designs include information about data storage
In R2, due to gaps in logging and monitoring there is no proactive use of data captured through monitoring
(e.g., zombie services running in AWS/rogue security groups etc.)
Assurance of data in transit and at rest validation is required
High level design for arch reflects the connectivity required to 3" party systems and LLDs have been generated
to support connectivity
To date, connectivity has been tested with stubs as most 3 parties do not have lower test environments. This
drives integrated test activities to the right where defects may be identified, increasing delivery risk
During the Pilots and until all branches go live, the legacy system will continue to run. This provides POL with
the opportunity to rigorously assess the effectiveness of data use, storage and accuracy through the pilot
branches prior to full roll out
Demand is currently coordinated through the central demand management funnel and this needs to be
maintained to ensure features from Horizon are effectively mapped into NBIT
Limited or no interventions recommended — Copyright © 2023 Accenture. All rights reserved.
POL00458014
POL00458014
WORKING DRAFT
IMPLEMENTATION
Copyright © 2023 Accenture. All rights reserved.
Limited or no interventions recommended
improve the experience once in Live. Workarounds that remain must be updated and remediation steps shared
KT for Postmasters has been developed and training (including current workarounds and operations
Current planning indicates an aspiration by POL to be more engaged in-service support including a technical
manuals) have been generated
first line capability. A wider POL decision is pending to drive the required outcomes and further planning
Planning for post go live support has been initiated with placeholders generated for user group training, ITSM
and KT transfer. Not all areas are populated or proven, however wider POL Enterprise approaches exist, and
the intent is that the approach will be matured in due course
Previous releases include defects and issues which at scale will be untenable. Exception notes have been
POL Operational support teams have been identified and WIP to ensure that tools used are aligned to track IT
raised by security
There are a high number of technical workarounds that training has identified that have been requested to
service management
A period of hypercare from the project teams has been anticipated, but it is unclear when this starts and ends
be remediated prior to Go-Live to assure the operational manual guidance
and when activity transfers to BAU, a plan is being progressed for this
Collaborating cross-functionally on an enduring solution for operational support aligned with the product
roadmap
As per 5.6.1 there are a high number of workaround areas that should be remediated prior to Go Live to
Technical Go,No-Go criteria (5.4.3) remediation will assure future Go,No-Go decisions
The Go,No-Go criteria is in place and has been used for previous releases
Evidence (what we have seen and heard)
Challenge for Go, No-Go is limited
and knowledge transfer have been identified.
However, this current level of support is not
viable long-term as NBIT is rolled out to all
larger programme of KT is being considered
Knowledge transfer was initiated following
Release 1 and POL operations teams have
been identified for the interim transition. A
criteria for Go Live that need to be aligned.
challenge is not present in the current GNG
2
S
8
£
8
2
©
5
a
3
a
&
a
2
&
o
hd
8
Ey
°
2
=
sustainable model. Dedicated engineering
resources time for initial technical support
2
&
£53
ba oon
8
a Ese
3 Eee
s & e
Fa g
3 225
2 EfBze
2 SeSee
> EE°3s
= oee
g 2 5e2e5
é 2 Cee ae
Fa = 85
z % EI8seE
§ 5 z zeges
& 3 § EOsfes
s Ps 3 Sso08
3 x 5 é
fa 3 2 ° Qete2s
g = a 2 Seoss
3 8 S 4 S2Es9
5 § 5 8
3 3 5 & Bose
3 eke lc Gt a
OBSERVATIONS (12/15)
5.6 POST GO LIVE SUPPORT
Level2
POL00458014
POL00458014
WORKING DRAFT
IMPLEMENTATION
OBSERVATIONS (13/15)
5.6 POST GO LIVE SUPPORT
Evidence (what we have seen and heard)
Observation
Level 3
Level2
Monitoring conducted by 3" party on devices
AWS monitoring and alerting in place and in use
Limited to no BI considered
Defender logs in place and in use
Centralised process for backup and restore NBIT and NFR capture on the Programme has been suboptimal with
Pre-Prod testing on R2 generating 10-12 defects to be remediated prior to entry to Live
Roll back plans are light and are under review with service operations
Chaos testing has not been conducted but planned for R2
Monitoring approach plan evolving, time available to remediate and POV in progress. POL and NBIT decision is
required
Monitoring currently in use includes instances as indicated below, a single pane of glass view is the target state
Itis recognised that interventions are required to build robust contingency and roll back capability. This is
iterative work in progress, alongside the 2 branch pilot
The Delivery status of Datadog is Work in Progress; it is an off the shelf version and does not include the full
POL standardised guidance is provided for contingency planning for Horizon (BAU) and NBIT
tool functionality
Ability to recover full system is unknown; chaos testing is to be conducted in the Pilots
Integration with POL ITSM tool,
immature and require additional testing and
_ Service Now is in progress
Contingency planning for roll backs are
assurance
observability tools across the
16
Copyright © 2023 Accenture. All rights reserved.
Limited or no interventions recommended
Moderate interventions recommended
> ED rcdotinivions [Bf sioniicantincerventions recommended /
POL00458014
POL00458014
WORKING DRAFT
IMPLEMENTATION
OBSERVATIONS (14/15)
5.7 SERVICE INTRODUCTION
Evidence (what we have seen and heard)
Observation
Level3
Level2
POL Enterprise service operations engaged recently, identified need for TOM and interlock between NBIT and
wider organisation to facilitate transition
ws
8
g
3
=
8
2
2
Pa
S
a
3
g
Fa
=
é
2
Service readiness criteria are defined for POL, and it remains a WIP to understand how this will be implemented
in Live.
Communications on Programme exist for patching/version updates, but not clear how this will be promulgated
in Live
z
2
Fs
8
>
£
£
3
2
£
2
5
2
3
£
2
5
Fs
5
3
2
5
2
5
&
8
Es
é
&
£
3
2
5
3
2
2
5
3
2
3
3
2
5
3B
£
8
2
§
5
2
3
£
g
3
3
8
®
3
8
5
&
¢
§
3
3
@
g
£
2
5
®
o
E
§
£
3
%
8
§
£
@
£
3
r-7
&
3
£
2
@
3
3
Communications strategy focussed on Postmasters in branches, limited evidence of communications required
maturity is developing. Ongoing support from the project team on its current scale will become untenable with
by others impacted once in Live
Project team advise that most issues are resolved by them and POL are mainly responding to business queries,
deployment to target state branches
TOM interlock between POL and NBIT is a WIP, aspiration to leverage existing POL capability and where gaps
exist, identify novel ways to remediate that the Enterprise can benefit from (e.g., DataDog)
During interviews, it was recognised that the move from a vendor led approach will include a change in
upskilling technical knowledge and expertise. This will be included in the strategy
Current live service support for R1 is provided through the project engineering team and POL Ops team
Alignment on monitoring alerting and reporting is being worked on at the operational level
(performance metrics are tracked in JIRA), and some issues are tracked by e-mail
Significant analysis of training requirements for Postmaster end users has been conducted.
processes are not compromised additional training may be required if identified in pilots
Operational manuals exist, not clear how much knowledge of this has been transferred
Gap in current training requirement for backend POL users has been identifie
Remediation of workarounds required to mitigate time spent on routine operations
Incident management environment in place however not tested
Risk challenge at Service Readiness Boards is not rigorous
coherence between remediations (in JIRA) and
its automated updates into the Enterprise
ITSM tool (ServiceNow)
User communications strategy in progress but
recognised training gaps exist across user
support for incidents/issues raised in Prod).
groups, additional work in progress
However operational guidance has been
platform is rolled out at scale, however there
Tech KT limited (Project teams remain 1* line
generated and integration is planned
with support from existing POL standard
practices in Live service support
There is work in progress to prepare the
ground for Live Service readiness once the
is currently limited engagement and
Evolving strategy and transition approach in
progress and handed over to a new owner
Ww
Copyright © 2023 Accenture. All rights reserved.
Limited or no interventions recommended
POL00458014
POL00458014
WORKING DRAFT
IMPLEMENTATION
OBSERVATIONS (15/15)
5.7 SERVICE INTRODUCTION
Evidence (what we have seen and heard)
Observation
Level 3
Level2
18
Copyright © 2023 Accenture. All rights reserved.
Limited or no interventions recommended
Observability toolsets are identified coordination of analytics into POL BI and MI dashboards is a WIP (Data Dog
Lack of data strategy impacts the ability to baseline and capture Ml (Management Information) and Bl (Business
in process of being onboarded)
Intelligence)
Lack of understanding of POL “value”, no evidence of this in product journey requirements therefore KPIs are
Workarounds from R2 require service management level interventions, this is not sustainable in the longer term
not clearly articulated. Tools are available to support the generation of actionable insights
Service Management recognise that ownership of L1 and L2 for platform requires a behavioural shift to move
into a different way of managing/owning the platform compared to full delegation (as experienced with the
Enterprise Service Now in place, but not integrated with JIRA. Work is underway to remediate this, currently
previous platform)
only tracked in JIRA
POL service management teams are in the process of being stood up, issues currently sent to project team,
shadow POL service management team in KT
No clear understanding of the level of training required and ability to move with evolving technology to
maintain platform relevance - POL have recognised this risk
Evidence of security responsiveness to performance issues remains a work in progress and needs to be
Device Management is monitored through 3" party. A target state solution owned by POL is in WIP
matured and aligned to ITSM
Enterprise-wide ITSM is established, and work
is in progress to align software engineering
teams to the POL tools and processes that
govern this, The level of technical knowledge
required to support transfer into the new
system, this remains a work in progress
Value definition during requirements
jeneration is not captured and products are
‘ot prioritised within releases, Metrics for KPIs
and value not defined
gi
ne
> @ RAG Definitions i I Significant interventions recommended Moderate interventions recommended
RECOMMENDATIONS (1/12)
5.1 DESIGN
Level2
5.1 Design
ry
$
:
&
H
H
5
5
8
3
$
=
=
5
&
Observation
6.1.1) Architecture high-level designs exist, and there
are embedded architects in some delivery squads,
however, there is a disconnect in detailed technical
design for some squads due to a lack of suitably
qualified technical business analysts and
involvement from key data and security contributors
5.1.2) Design Principles have been created and
captured in Confluence, however adherence to
these principles has been inconsistent across
engineering teams which leads to fragmentation and
inconsistencies in delivery
5.1.3) The TDA process exists and most follow the
process for re-assessment, as and when these have
been delivered without return for approval, tl
results in quality control issues and negatively
impacts the overall delivery due to non-alignment to
high-level architectural designs. There are initiatives
in place to help remediate some of these areas
5.1.4) Divergence between high-level platform
architecture design and low-level engineering
designs have caused an increase in technical debt,
quality issues resulting in slower delivery
> @ RAG Definitions i I Significant interventions recommended
POL00458014
POL00458014
WORKING DRAFT
IMPLEMENTATION
Recommendation Tower Proposed Mapping to
Priority Summary Rec.
RecS.1A) Low level design remediation work has been completed as side of desk by Vv
technical BAs, architects and Engineers . With the scale of remaining work, it is #2, #3, #9
recommended to add skilled technical BA resources to remediate this as a priority (Underway)
RecS.1B) Remediate the gap between high level and low-level designs through mandating a
standardised template for low-level designs, formalising alignment and approval by subject Vv #2, #3, #12, #25
matter experts
RecS.1C) To assure design principles are consistently adhered to, TDAs and low-level Vv $2.93, "2
designs should include an effective initial threat analysis VBS
Rec5.1D) Mandate Developer/Engineer compliance with the Cl/CD Pipeline through the Vv #25, #12
capture of metrics from the pipelines "
RecS.1E) In order to align and assure the linkage between high-level and low-level designs, v
workflows in confluence and JIRA should mandate linkage between them; leveraging #25, #12
assurance metrics generated to police compliance (Underway)
Moderate interventions recommended __Limited or no interventions recommended Copyright © 2023 Accenture. All rights reserved. 119
RECOMMENDATIONS (2/12)
5.1 DESIGN
Level2
5.1 Design
> @ RAG Definitions [Bf sioniicantincerventions recommended
i}
a
$
€
=
3
£
Observation
5.1.1) Architecture high-level designs exist, and there
are embedded architects in some delivery squads,
however, there is a disconnect in detailed technical
design for some squads due to a lack of suitably
qualified technical business analysts and
involvement from key data and security contributors
5.1.2) Design Principles have been created and
captured in Confluence, however adherence to
these principles has been inconsistent across
engineering teams which leads to fragmentation and
inconsistencies in delivery
5.1.3) The TDA process exists and most follow the
process for re-assessment, as and when these have
been delivered without return for approval, tI
results in quality control issues and negatively
impacts the overall delivery due to non-alignment to
high-level architectural designs. There are initiatives
in place to help remediate some of these areas
5.1.4) Divergence between high-level platform
architecture design and low-level engineering
designs have caused an increase in technical debt,
quality issues resulting in slower delivery
Recommendation
RecS.1F) Configure the Cl/CD pipeline to assure development releases are all tested and are
fully immutable, build once deploy many
Rec5.1G) Amend the Platform design to enable developers to create, use and destroy
environments for experiments and to test spikes
Moderate interventions recommended —_Limited or no interventions recommended
POL00458014
POL00458014
WORKING DRAFT
IMPLEMENTATION
‘Tower Proposed Mapping to
Priority Summary Rec.
#25, #12
#25, #12
Copyright © 2023 Accenture. All rights reserved. 120
RECOMMENDATIONS (3/12)
5.2 BUILD
Level2
?
3
H
a
.
5
g
=
:
:
z
=
:
$
Observation
5.2.1) Engineering demand is not effectively
captured, estimated, planned, prioritized or
managed across teams, leading to a lack of
alignment on business priorities, inefficient
allocation of resources, and delays in delivering
capabilities. There is a business demand process
that Engineering do not engage with
6.2.2) There is no Programme
methodology/approach that ties all squads together
to work in a mature Agile way. Inconsistent capture
of key data points, results in a lack of clear
status across the programme, hindering data driven
decision making
5.2.3) This area is red trending amber; while
remediation is in place, capacity is not prioritised for
this. Inconsistent use, by squads of CD pipeline and
tools is evident through poor code quality and is
reflected by the number of defects raised
5.2.4) Development Principles exist but are not
consistently applied, including definition of
ready/done, ultimately resulting in scope creep and
increased number of defects once code
is promoted to higher environments
> @ RAG Definitions i I Significant interventions recommended
POL00458014
POL00458014
WORKING DRAFT
IMPLEMENTATION
Recommendation Tower Proposed Mapping to
Priority Summary Rec.
RecS.2A) Adopt agile principles to support effective demand management on the basis an +
‘ 3 30, #31, #12
agile methodology is selected, to then enforce Story Point estimation
RecS.2B) Standardise JIRA processes across all squads by defining and enforcing an v
#24, #25, #12
approach and rolling out to different teams (Underway)
RecS.2C) Staff and contractors must attain or be recruited with the appropriate skill levels Vv #30, #31, #11, #5, #8
ReeS.2D) Pivot to a DevSecOps-centric culture that follows defined agile practices by the
Vv #30, #31, #22
introduction of a maturity assessment in the DevSecOps space
ReeS.2E) implement standardised ways of working, aligned to the agile approaches in v #30, #31, #12
development, to ensure effective insights are captured and provide data driven results us
I Moderate interventions recommended _Limited or nointerventionsrecommended Copyright © 2023 Accenture. Alll rights reserved. 121
POL00458014
POL00458014
WORKING DRAFT
RECOMMENDATIONS (4/12)
5.2 BUILD
‘Tower Proposed Mapping to
Level2 Observation Recommendation ae
Priority Summary Rec.
Rec5.2F) Improve environment controls to assure code quality and the security of the
deployment and the platform, including least privileged access between environments, v #30, #31, #12
hardened security practices between pre-prod and prod and standardisation of automated Vash
code release into environments
5.2.8) Delivery backlogs are not prioritised or linked
to higher level requirements or high-level designs
therefore it is difficult to trace backlogs back to
source or manage dependencies
5.2.6) Environment management is immature as a
capability, issues caused by poor environment
hygiene have led to suboptimal code and security
issues have increased delivery timelines
Rec5.2G) Improve knowledge management and traceability to reduce confusion and
increase pace by configuring and using Confluence, SharePoint and JIRA in a consistent and #30, #31
standard way
(continued)
5.2.7) Coding standards and controls are insufficient
to assure the quality of code in Production, placing
POL at financial risk due to lack of effectiveness of
the platform and reputational risk due to data and
security risks
Rec5.2H) Embrace a modern engineering approach, including but not limited to CICD,
Monitoring, Automation, data-driven decisions, re-usable components etc. to leverage the
h #30, #
best outcomes from the resources and tools available to engineering teams to increase code 30, #31
quality and velocity. This is in progress
> @ RAG Definitions [Bf sioniicantincerventions recommended I Moderate interventions recommended —_Limited or no interventions recommended Copyright © 2023 Accenture. Allrights reserved. 122
RECOMMENDATIONS (5/12)
5.3 TESTING
Level2
6.3 Testing
2
2
a
%
3
&
5
6
8
3
3
&
=
5
€
Observation
5.3.1) Test strategy and approach exist. The
principles that the test strategy refer to are not
always followed
5.3.2) Test coverage metrics are not consistently
available nor traceable to requirements in JIRA and
therefore there is no ability to assess coverage
across the programme with confidence. There is
work in progress to remediate this
5.3.3) Limited test automation in CICD pipeline used
consistently; although tools are available, resulting
in sub-optimal code quality
5.3.4) Test planning for code releases into higher
environments are gated which provides a level of
assurance and insight, with reports available in JIRA.
Lower environment testing and reporting has not
been rigorously applied
5.3.5) Test data management is generated by each
project, resulting in duplication of effort and
multiple test data sets being used
5.3.6) Defect reporting is captured inconsistently,
remediation takes a long time due to immature
processes and a lack of automation
5.3.7) BVT runs in parallel with E2E Testing. Current
UAT approach is in draft. Changes in UAT are not
driven by data insights
> @ RAG Definitions i I Significant interventions recommended
Recommendation
RecS.3A) Assure adherence to Programme compliance from Day 1 by providing clear
engineering onboarding runbook and ways of working
ReeS.3B) Ensure test coverage by applying DevSecOps principles and following the test
strategy and approach to assure code quality and reduce effort required in E2E testing
through monitoring of data from pipelines and JIRA
Rec5.3C) Mandate a level of test automation to increase code quality and reduce threats and
vulnerabilities
ReeS.3D) Capture NFT requirements in JIRA during solutioning and prepare for associated
testing early in t ycles
Rec5.3E) Centralise test data and enable re-use and more effective validation for expected
testing results
_ Moderate interventions recommended —_Limited or no interventions recommended
Copyright © 2023 Accenture. All rights reserved
POL00458014
POL00458014
WORKING DRAFT
IMPLEMENTATION
‘Tower Proposed Mapping to
Priority Summary Rec.
Vv #24, #31, #28
v #24, #25, #12
(Underway)
Vv #24, #25
v #24, #25
(Underway)
Vv #24, #31
POL00458014
POL00458014
WORKING DRAFT
RECOMMENDATIONS (6/12)
5.3 TESTING
‘Tower Proposed Mapping to
Level2 Observation Recommendation ue
Priority Summary Rec.
5.3.1) Test strategy and approach exist. The
principles that the test strategy refer to are not
always followed
5.3.2) Test coverage metrics are not consistently Rec&.3F) Improve defect management to enable effective actionable insight to be captured
available nor traceable to requirements in JIRA and _ and implemented, reducing the burden on the resolver teams
therefore there is no ability to assess coverage
across the programme with confidence. There is
work in progress to remediate this
Vv #24, #31
5.3.3) Limited test automation in CICD pipeline used
consistently; although tools are available, resulting
in sub-optimal code quality
Rec&.3G) Remediate existing tech debt to enable future velocity and code quality. By
5.3.4) Test planning for code releases into higher prioritising and allocating capacity within teams to focus on remediation delivered to v
environments are gated which provides alevel of modern engineering standards. This enables secure and accelerated development. A DORA (Underway) #24, #25
assurance and insight, with reports available in JIRA. metrics approach is currently used to measure and report on this through the Cl and Build
Lower environment testing and reporting has not Better initiative
been rigorously applied
3
3
s
§
<
6.3 Testing
5.3.5) Test data management is generated by each
project, resulting in duplication of effort and
multiple test data sets being used
5.3.6) Defect reporting is captured inconsistently,
remediation takes a long time due to immature Rec5.3H) Make improvements to support accelerated UAT by introducing testing of unhappy
kK #24, #25
processes and a lack of automation paths, capturing lessons identified and allocating to accountable owners ’
5.3.7) BVT runs in parallel with E2E Testing. Current
UAT approach is in draft. Changes in UAT are not
driven by data insights
> @ RAG Definitions [Bf sioniicantincerventions recommended " Moderate interventions recommended __ Limited or no interventions recommended Copyright © 2023 Accenture. All rights reserved. 124
POL00458014
POL00458014
WORKING DRAFT
RECOMMENDATIONS (7/12)
5.4 RELEASE MANAGEMENT AND DEPLOYMENT
Level2 Observation Recommendation Tower Proposed Mapping to
Priority Summary Rec.
5.4.1) There is no standard release strategy, it is
currently manual and repeatable but carries the risk ReeS.4A) Revise the Environment Strategy to include mandated compliance and automation v #24
of poor code quality. While automation tools and _of deployments to improve release quality
controls are being implemented through to higher
environments, lower environments lack consistency
in using and leveraging these tools to maintain code RecS.4B) Remediate areas known to impact the release schedule such as technical debt, v
a quality and developer productivity continuous deployment blockers and manual interventions by actively allocating engineering #24
' time to resolve (Underway)
E 5.4.2) Repeatable deployment approach exists, it
3 involves manual interventions that delay deployment
Faeeyeed cycles and limit continuous delivery capabilities
a &
8-99 5.4.3) Go Live criteria are standardised in CAB for ReeS.4C) Through use of effective workflows, facilitate challenge earlier in the development
ge A #24, #12
le Waeme release, however while the process is secure, lifecycle to remove potential blockages at the end of the lifecycle
Filta effective challenge is not present in the current
6 & decision-making forums. This may have major
Eyed repercussions when a release is deployed to several
ez branches
ses
-; I rT have bi
Fg 8-4-4) Releaoes into Production nave oven Rec5.4D) Use empirical evidence obtained from DevSecOps tooling to support faster and v
belied) completed and include a high number of issues and
3 valivorebltties called out The lane and schedule are Safer Go Live decisions (i.., insight data from SonarQube, Git, JIRA, Snyk etc.) - This is work (Underway) #24, #19
3 out. ne P " “tin progress as part of the Cl and Build Better initiatives
= available, the confidence that scope is achievable is
3 open to question
5.4,8a) Releases into live have followed POL
guidance with the project providing Hypercare and ReeS.4E) Create increased confidence to release at scale by initially reducing the size and
POL service support shadowing initiated. While this scale of releases by using automated deployments that secure quality code. Post Office #24, #25
area is immature, steps to remediate are in progress, should aim to continuously deploy releases at pace into non-prod environments as Vv g
including a TOM that draws NBIT and POL teams frequently as possible. Small changes
together to achieve an enduring process
> @ RAG Definitions i I Significant interventions recommended Moderate interventions recommended —_Limited or no interventions recommended Copyright © 2023 Accenture. All rights reserved. 125
RECOMMENDATIONS (8/12)
5.4 RELEASE MANAGEMENT AND DEPLOYMENT
Level2
cE
s
a
3
a
3
z
i
z
A
&
§
5
?
H
5
=
3
3
3
2
¢
P
(continued)
Observation
5.4.1) There is no standard release strategy, it is
currently manual and repeatable but carries the risk
of poor code quality. While automation tools and.
controls are being implemented through to higher
environments, lower environments lack consistency
in using and leveraging these tools to maintain code
quality and developer productivity
5.4.2) Repeatable deployment approach exists, it
involves manual interventions that delay deployment
cycles and limit continuous delivery capabilities
5.4.3) Go Live criteria are standardised in CAB for
release, however while the process is secure,
effective challenge is not present in the current
decision-making forums. This may have major
repercussions when a release is deployed to several
branches
5.4.4a) Releases into Production have been
completed and include a high number of issues and
vulnerabilities called out. The plans and schedule are
available, the confidence that scope is achievable is
open to question
5.4.5a) Releases into live have followed POL
guidance with the project providing Hypercare and
POL service support shadowing initiated. While this
area is immature, steps to remediate are in progress,
including a TOM that draws NBIT and POL teams.
together to achieve an enduring process
> @ RAG Definitions i I Significant interventions recommended
POL00458014
POL00458014
WORKING DRAFT
IMPLEMENTATION
Recommendation Tower Proposed Mapping to
Priority Summary Rec.
RecS.4F) Remove conflicting/out of date guidance/documentation from Confluence to #04, #31
ensure clarity of criteria and expectations for release management and deployment q
Rec&.46) Provide feedback to wider stakeholders and assure ownership and accountability
#24, #31
of lessons identified from each release and deployment
Rec&.4H) Train and engage post hypercare support to enable effective Subject Matter 404, #31
Experts from POL during the Pilot q
Rec8.41) Validate current and future training needs for POL support teams through lessons
#24, #31
identified during knowledge transfer
Ree&.44) Align technical deployments to the hardware roll out and support remediation of #04, #31
the current known challenges. Greater alignment between the NBIT and POL d
Moderate interventions recommended _Limited or no interventions recommended Copyright © 2023 Accenture. All rights reserved. 126
RECOMMENDATIONS (9/12)
5.5 DATA CONVERSION
Observation
5.5.1) Lack of a data strategy has been accepted as a
gap across the programme. Most data requirements
are maintained through individual business
workstream areas. Duplication of work is not
considered extensive. Gaps in data requirements are
not consistently managed
5.5.2) Data requirements have been captured, but
most data is handled by 3” party systems
5.5.3) Limited evidence of a joined-up
understanding of data and security requirements
driving risks to POL and 3° party stakeholders
5.8.4) 3rd party connectivity is currently managed
on a case-by-case basis with development teams
5.5.5) The programme approach is to use the dual
running phase with the legacy system to assure and
remediate any residual interdependencies
> @ RAG Definitions i I Significant interventions recommended
Recommendation
Rec5.SA) Generate a data strategy to align the data requirements for the programme
Rec5.5B) Review data requirements and align data management approach to workstreams
Rec5.8C) Provide access to standardised synthetic data to enable re-use and automated
testing
ReeS.8D) Review low-level designs and requirements to assure data requirements have been
captured by including a mandated section in the low-level design template
Rec5.5E) Conduct security review of low-level data designs and remediate areas of concern
through collaboration across Architecture, Security and Engineering teams
__ Moderate interventions recommended —_Limited or no interventions recommended
Copyright © 2023 Accenture. All rights reserved.
POL00458014
POL00458014
WORKING DRAFT
IMPLEMENTATION
‘Tower Proposed Mapping to
Priority Summary Rec.
v
#2, #3
#5, #30, #31
#5, #30, #31
#5, #30, #31
v
(Underway)
#24, #25
127
POL00458014
POL00458014
WORKING DRAFT
RECOMMENDATIONS (10/12)
5.5 DATA CONVERSION
‘Tower Proposed Mapping to
Level2 Observation Recommendation pre
Priority Summary Rec.
5.5.1) Lack of a data strategy has been accepted as a Rec5.5F) Remediate current gaps in data observability and security vulnerabilities v 5, #30, #31
gap across the programme. Most data requirements
are maintained through individual business
workstream areas. Duplication of work is not
considered extensive. Gaps in data requirements are
not consistently managed
5.5.2) Data requirements have been captured, but
most data is handled by 3 party systems
Rec5.5G) During the Pilot, rigorously assess the effectiveness of data use, storage and #30, #31
5.6.3) Limited evidence of a joined-up accuracy prior to full roll out by and include chaos testing
understanding of data and security requirements
driving risks to POL and 3 party stakeholders
8.5.4) 3rd party connectivity is currently managed
on a case-by-case basis with development teams
5.5.8) The programme approach is to use the dual
running phase with the legacy system to assure and
ge remediate any residual interdependencies RecS.5H) Identify additional opportunities to create and or improve the quality of 3° Party
stubs for testing. This mitigates late-stage testing of these activities in the E2E test #30, #31
environment
Limited or no interventions recommended Copyright © 2023 Accenture. All rights reserved. 128
Moderate interventions recommended
> ED rcdotinivions [Bf sioniicantincerventions recommended -
RECOMMENDATIONS (11/12)
5.6 POST GO LIVE SUPPORT
Level2
Observation
5.6.1) The post-go-live support plan has limitations,
but work is underway to establish a sustainable
model. Dedicated engineering resources for initial
technical support and knowledge transfer have been
identified. However, this current level of support is
not viable long-term as NBIT is rolled out to all
branches
5.6.2) Knowledge transfer was initiated following
Release 1 and POL operations teams have been
identified for the interim transition. A larger
programme of KT is being considered for the target
state
5.6.3) POL has a process and criteria for Go Live,
and NBIT has and will continue to align with this.
While the process is secure, effective challenge is
not present in the current decision-making forums
5.6.4) Contingency planning for roll backs are
immature and require additional testing and
assurance
_ 5.6.5) There are monitoring, alerting and
observability tools across the programme.
Integration with POL ITSM tool, Service Now is in
progress
> @ RAG Definitions i I Significant interventions recommended
Recommendation
RecS.6A) Remediate existing technical debt introduced by hot fixes prior to building
additional releases that compound them
Rec5.6B) Clearly define the transition timeline and accountability for service support
RecS.6C) Rapidly incorporate lessons learned from the pilot into future ways of working by
discussing and incorporating into plans and assigning ownership
Rec5.6D) Integrate JIRA and Service Now to capture Live Incidents
Rec5.6E) Define and align the product roadmap with solution and operational support in
programme increment planning (if introduced as part of an Agile methodology)
RecS.6.F) Establish TOM for support. The current setup of a L1 support desk and then
straight to delivery squads for every area of the solution is neither sustainable nor economic
Moderate interventions recommended Limited or no interventions recommended
Copyright © 2023 Accenture. All rights reserved.
POL00458014
POL00458014
WORKING DRAFT
IMPLEMENTATION
‘Tower Proposed Mapping to
Priority Summary Rec.
v #24, #25
(Underway)
Vv #5, #30, #31
Vv #5, #30, #31
Vv #5, #30, #31, #12
#24, #25
#30, #31
129
RECOMMENDATIONS (12/12)
5.7 SERVICE INTRODUCTION
Level2 Observation
service support
(ServiceNow)
progress
not defined
8.7.1) Evolving strategy and transition approach in
progress and handed over to a new owner with
support from existing POL standard practices in Live
5.7.2) There is work in progress to prepare the
ground for Live Service readiness once the platform
is rolled out at scale, however there is
currently limited engagement and coherence
between remediations (in JIRA) and its
automated updates into the Enterprise ITSM tool
8.7.3) Tech KT limited (Project teams remain 1* line
support for incidents/issues raised in Prod). However
operational guidance has been generated, and is.
planned to be iterated and KT has been conducted
5.7.4) User communications strategy in progress but
recognised training gaps exist across user groups,
additional work in progress
5.7.5) Enterprise-wide ITSM is established, and work
is in progress to align software engineering teams to
the POL tools and processes that govern this. The
level of technical knowledge required to support
transfer into the new system, this remains a work in
5.7.6) Value definition during requirements
generation is not captured and products are not
prioritised within releases, Metrics for KPIs and value
ignificant interventions recommended
Recommendation
RecS.7A) Maintain closer working relationships between POL and NBIT with a clear TOM
RecS.7B) Leverage the opportunity offered by NBIT to enable modern technology
approaches that support exploitation of novel areas. By allocating time for the team to
conduct POC and Experiment as part of the hardening sprints
Rec5.7C) Align management of POL resource to a non-vendor led approach at Levels 1 and 2
based on the current strategy prior to R2 Go Live
Rec5.7D) Remediate workarounds that prevent handover of RI to POL service support by
allocating time throughout the proposed hardening sprints
RecS.7E) Fully transition ITSM to Service Now and POL Service Management Team
RecS5.7F) Communicate the interim change and defect process required during transition,
POL00458014
POL00458014
WORKING DRAFT
IMPLEMENTATION
‘Tower Proposed
Priority
v
v
(Underway)
Mapping to
Summary Rec.
#5, #30, #31
#5, #30, #31, #14
#30, #31
#30, #31
#5, #30, #31, #12, #9
and track all inputs and changes in Confluence, linked to items in JIRA for work to be Vv #30, #31
completed
Rec5.7G) Use the Incident management environment to validate that the environment works #30, #31
as expected to resolve incidents in Live ahead of release launches ‘
RecS.7H) Align dashboards that capture data from monitoring and observability tools,
Vv #30, #31
including performance metrics and tooling approach
I Moderate interventions recommended __ Limited or no interventions recommended Copyright © 2023 Accenture. All rights reserved. 130
POL00458014
POL00458014
WORKING DRAFT
IV I ADDITIONAL
SUPPORTING EVIDENCE
BUILD BETTER / Cl INITIATIVE AND JIRA DEFECT
TRENDS
POL00458014
POLO0458014
WORKING DRAFT
BUILD BETTER QE PROGRESS SUMMARY (1/3)
DEFINITION OF METRICS BASED ON DORA THAT ARE BEING TRACKED BY THE BUILD BETTER INITIATIVE
Definition of Metrics
Topic
DoR
‘Metric Definition
Average number of stories with Acceptance Criteria populated per
quarter, Data extracted using Jira Hygiene board,
Timeframe
Baseline ~ start of Q2 2022 to end of Q2
2023
Latest ~ current quarter
‘Metric Methad
Populated AC (per quarter)
Unit Tests
Average number of days stories are held within a testing/QA status.
‘Data extracted from Jira via queries.
{note ~ quality & consistency of Jira story data is currently insufficient
to use]
Baseline ~ start of Q2 2022 to end of 2
Latest ~ current quarter
‘Agility ~ Cycle Time
Automation
Of the total number of tests executed, what percentage were
automated. Data extracted from Zephyr folders using queries.
Baseline ~ start of Q2 2022 to end of Q2
2023
Latest ~ current quarter
Efficiency ~ Total
2p
Ff the total number of defects raised, what percentage were found
within the Squad team. Data extracted from fira queries.
{note ~ until we start E2E testing, we cannot calculate for a release]
Baseline ~ Release 2.0
Latest ~ Current Release (e.g. R2.1)
Quality - Defect Capture
Early NET
Percentage of expected NFRs documented in Jira. Based on tracker
maintained by NFT team.
Baseline ~ start of Q2 2022 to end of Q2
2023
Latest ~ current quarter
NFR coverage
As of Oct 2023
Build better and Cl initiative
are underway. The metrics
shown are being gathered
and reported on by the QA
team.
Average number of defects with Root Cause Analysis populated per
quarter. Data extracted using Jira Hygiene board,
Baseline ~ start of Q2 2022 to end of 02
2023
Latest ~ current quarter
Populated RCA (per month)
Percentage of stories that meet QE elements of the DoD criteria:
+ Allstories have associated test cases linked that cover the AC
+ Allassociated test cases executed
*+ All associated test cases passed with evidence attached
+ All defects linked to story have been closed or formally deterred
with commentary,
Data based on extract from Zephyr using toot,
Baseline ~ start of Q2 2022 to end of Q2
2023
Latest ~ currant quarter
Dob Compliance Check
Copyright © 2023 Accenture. All rights reserved.
132
POL00458014
POL00458014
WORKING DRAFT
BUILD BETTER QE PROGRESS SUMMARY (2/3)
REPORT FROM QE REFLECTS EMPIRICAL PROGRESS AGAINST BASELINE DATA ENABLING ASSURANCE
Overa ul Head of QE Date
Dan Perrin Sept 2023
slid _ As of Oct 2023
+ This quarter we completed the Cl Wave 1 engagement with teams, focused on the below topics.
+ We are now beginning Cl Wave 2, which will include expanding/refining the use of the test automation framework, implementing the
PACT tool to support integration, implementing common Jira configuration and formalising the handover from Squad to E2E teams.
The focus is on
implementing a common
pie Ct Actions Status Metric Method Baseline Latest configuration in Jira and
bor Defined and meseured Dok. ~ voslatea nc ter at som oon rolling it out across the
3 Amigos added for complex stories. Open ‘opulated AC {per qtr.) squads.
Unit Tests I Unit Test evidence captured and shared with QA, Dene Agility ~ Cycle Time Nia Nia - DoR, RCA are the main
‘Automated Smoke Tests in CICD pipe metrics tracked from Jira
Automation I (standalone pipe or live pipe, depending on Done Efficiency ~ Total 11% 31% A Data
GitHub Actions migration status)
2p Documented planned P2P cycles. Done Quality - Defect Capture 81% Na - Automation, Unit Tests and
DoD pull from data from
Early NFT Product NFR approach presented by NFT team. en NFR coverage 0% 26% A Zephyr (test mana gement)
integrated in Jira.
Added RCA to Jira. " F;
RCA Cover defect RCA in Retro. en Populated RCA (per qtr) 8% 28% A
Defined and measured DoD.
DoD Demos to E2E team. DoD Compliance Check 39% 50% A
> @ Copyright © 2023 Accenture. All rights reserved. 133
POL00458014
POLO0458014
WORKING DRAFT
BUILD BETTER QE PROGRESS SUMMARY (3/3)
EXAMPLE REPORT FOR ONE AREA INDICATING PROGRESS AGAINST METRICS
. QA Lead Date
Banking and Payments
9 y Ankita Saoji Sept 2023
Summary
+ Current effort is focused on test execution for Sprint 16 for Release v2.1. were progressed from April to June.
+ Challenges - Assistance requested to reduce execution time for Smoke Tests. Concerns raised on NFR approach.
‘Status Metric Method Latest Trend
DoR 3 Amigos added for complex stories Done Populated AC (per qtr.) 93% 97% A
Unit Tests Test scope shared with QA Done Agility ~ Cycle Time N/a N/a -
Automation Automated API Smoke Tests in CICD pipe Done Efficiency ~ Total 31% 79% A
2p Documented planned P2P cycle Done Quality - Defect Capture 84% Nia .
Early NFT Approach presented by NFT team NFR coverage 0%, 20% \
RCA Added RCA to Jira & Cover defect RCA in Retro Done Populated RCA (per gtr.) 1% 17% A
DoD Provide Demo to E2E team Done DoD Compliance Check 54% 75% AN
As of Oct 2023
A view of the trends from
the Banking and Payment
area.
A useful statistic would be
to get a squad-by-squad
view.
This would start to give an
indication of adoption
across the program and
give a view of the adoption
and results across the
squads.
Copyright © 2023 Accenture. All rights reserved.
134
DEFECT TRENDS
HISTORICAL DATA AND ANALYSIS
POL00458014
POLO0458014
WORKING DRAFT
Aview of the historical defect trends
+ This aligns with findings about releases promoted from in-sprint into E2E resulting in a high level of defects found in
the environment. Defects in the main that should have been captured in prior environments and or the Cl/CD
pipelines.
+ BVT issues were also historically high as some raised differing feature issues were seen and tagged as defects.
+ Also, note the spike in Security issues from those carried over from 2022 to the trend in 2023.
+ There is a downward trend quarter by quarter. This is can be attributed to the current period of relative stillness on
the project, the Build better and Cl initiatives being rolled out to squads and from E2E environment, the introduction
of a regression test pack. More analysis and stronger data is required to validate these assumptions.
>@
Copyright © 2023 Accenture. All rights reserved.
(Count of issue keyI Column Labels
in Pre-Prod Deployment
Row Labels BVT E2E I Sprint I OATI Performance Testing (E2E) Validation. Production Security Testing _ITech ProvingI UAT] UAT (Ri) I (blank) IGrand TotalI Note - The data from Jira and:
29/03/2022
boaa 6 19 Ezy @ 112 1. This table provides a list of
ot ¢ ‘i all the defects raised on the
tra 7 7 14 Test & Assurance
Qtea 6 10 79 1 96 Dashboard.
oa. 369 42095 I 19 10 10 4 22 zo IaoI 2 1191
aera 14 226 I 52 _I 45 2 82 491 2. this tables does include
2, 391. 238 I_37_) 2 2 2 Ae 482 tickets which have been
Qer3 63 s7I 6 [2 1 2 43 aol 2 223.
‘tra 1 2 + 70. 15 cloned by product teams to
(Grand Total 375, 439 I 95 I 19 10 4 291 10 40 I 10 1303 the TA board, but it is known
that only a small subset of
defects were cloned for
E2E/BVT test visibility.
3. This table excludes
duplicate, invalid, defects
which do not have assignees
and defects that are not
tagged to a test phase: ~700.
The caveats above highlight
the findings, observations
and recommendations made
around JIRA re-
configuration.
135