D3.1 · Target state implementation roadmap

Work stream	WS 3 — Implementation Roadmap & Cost Estimate
SOW source	Schedule "A", WS 3 deliverables, first bullet
Status	⚪ Not started
Indicative window	Weeks 5–6

What the SOW asks for

Target state implementation roadmap, including: implementation work streams · sequencing and phasing of the work · key milestones · dependencies · critical path · transition considerations · key risks and mitigations

Backed by WS 3 activities 1–7, which add the reasoning the roadmap has to embody: sequencing logic based on business priorities, technical dependencies, organizational readiness and opportunities to deliver incremental value; dependencies across platforms, applications, integrations, data, identity, infrastructure and participating lines of business; and transition considerations from current to target state.

Structure

Section	Content
Implementation work streams	The major parallel tracks required to realize the target state
Sequencing and phasing	What goes first and why — the why is the deliverable
Key milestones	Verifiable points, with what each one proves
Dependencies	Cross-platform, application, integration, data, identity, infrastructure, and per-LOB
Critical path	The chain that actually determines the end date
Transition considerations	How to get from the current environment to the target without a big-bang cutover
Key risks and mitigations	With owners

Where the content is being assembled

• Roadmap narrative and tables: docs/roadmap/ (created when WS 3 starts)
• Dependencies carried forward from D2.4
• Working notes: WS 3 tasks

Diagrams

Diagram	Type	Purpose
Roadmap phasing	workflow or lifecycle	Work streams across phases, with gates
Dependency map	architecture	What blocks what, across platforms and business units
Transition states	lifecycle	Current → interim → target, and what runs in parallel

Deltas between diagram versions are architecture-only — Archify computes them for architecture diagrams and no other type. A roadmap drawn as a workflow still gets versions, the switcher and a timeline; the timeline will say no delta is available rather than inventing one.

What the client material already gives us

This deliverable starts further along than it looks, because three artifacts already contain sequencing logic:

The strategy's seven workstreams. The unified customer architecture decomposes into seven independently shippable workstreams across three phases, each with an owner and a layer, and explicitly notes that none assumes the others have finished. That is a candidate spine.

The assessment's nine conditions. The segment assessment lists nine conditions to overturn its rejection, already ordered, with conditions 1–3 marked prerequisite. That is a sequenced, severity-graded, client-authored view of what blocks what.

The experience map's build classification. The experience map already separates promote-to-production work from net-new build from procurement, zone by zone, with API-level evidence. That is the raw material for phasing the experience layer.

Sequencing forces we already know about

• Environments gate everything downstream. SIT Redis pending, UAT pending, PROD not ready, no DR-region instance anywhere. No performance test, no penetration test and no DR drill can happen before those exist — and the penetration test is a mandatory security gate that requires a non-production environment which does not exist.
• The cancelled operational workstreams have no owner. Readiness, Testing, GTM, Stabilization and Scale Planning were cancelled in the CAUCE-to-CAUEX replan without an inheritor. A roadmap that does not re-home them is repeating the mistake.
• The delivery record is not reconcilable. Two Jira projects, zero cross-links. Reconciling them into one traceable view may need to be an explicit early roadmap item — it is condition 7 of the assessment.
• Volumetry is cheap and unblocks pricing. Per-BU load projections and the FCC capacity question gate the API strategy, the cache design, the NFR catalogue and the performance test. It is a small piece of work sitting upstream of a lot of others.
• The operating model is a hard dependency and out of scope. Four components with no business-unit home. We sequence around it and flag it; we do not design it (SOW §3.0).

Transition considerations

The one the material makes unavoidable: the Unified Dashboard replaces the Product Selection Home Page, which is today the route by which Canadian customers reach every BU portal. After cutover its availability bounds all Canadian digital servicing. A transition plan that does not specify the bypass route, how it is triggered and who can trigger it is not a transition plan.

Acceptance

Written acceptance per SOW §5, following the executive readout (WS 3 activity 11).