WS 3 — Implementation Roadmap & Cost Estimate
| Duration | 2 weeks |
| Objective | Translate the target state architecture into an implementation roadmap identifying the sequencing, dependencies and milestones required to move from the current environment to the target state |
| Deliverables | D3.1 · D3.2 · D3.3 |
Tasks
| ID | Activity (SOW Schedule "A") | Output | Status |
|---|---|---|---|
| WS3-A1 | Define major implementation work streams and capabilities required to realize the target state | Work stream definitions | ⚪ |
| WS3-A2 | Develop sequencing logic — business priorities, technical dependencies, organizational readiness, incremental value | Sequencing rationale | ⚪ |
| WS3-A3 | Identify key dependencies across platforms, applications, integrations, data, identity, infrastructure and participating lines of business | Dependency map + diagram | ⚪ |
| WS3-A4 | Identify critical path activities and key milestones | Critical path | ⚪ |
| WS3-A5 | Define the phased implementation roadmap — initiatives, sequencing, dependencies, indicative timing | Roadmap + diagram | ⚪ |
| WS3-A6 | Develop transition considerations for current to target state | Transition plan | ⚪ |
| WS3-A7 | Identify key risks and constraints of the transition, with mitigation strategies | Risk register | ⚪ |
| WS3-A8 | Create two implementation cost options — Konrad-owned delivery; co-delivery | D3.2 | ⚪ |
| WS3-A9 | Develop ROM implementation estimates for each option | ROM estimates + basis of estimate | ⚪ |
| WS3-A10 | Prepare the executive summary of roadmap, options and recommended path forward | D3.3 | ⚪ |
| WS3-A11 | Conduct the executive readout | Readout · next steps · engagement close | ⚪ |
Working notes
Three candidate spines, already written by the client
A2 does not start from nothing. Three artifacts in the client material already contain sequencing logic, and the roadmap will most likely be a reconciliation of them rather than a fourth invention:
- The strategy's seven workstreams across three phases, each with an owner and a layer, explicitly designed so none waits on the others.
- The assessment's nine conditions, already ordered by severity with 1–3 marked prerequisite to any further review.
- The experience map's build classification, separating promote-to-production from net-new build from procurement, zone by zone.
Reconciling three client-authored sequences into one is a much stronger position than presenting our own — it makes the roadmap theirs, and it makes disagreements visible instead of implicit.
Dependencies already visible
For A3, before any new analysis:
| Dependency | Gates |
|---|---|
| SIT / UAT / PROD / DR Redis provisioning | Integration test, performance test, penetration test, DR drill |
| A non-production environment that exists | The mandatory authenticated penetration test |
| Volumetry and the FCC capacity answer | API strategy, cache design, NFR catalogue, performance test, and the cost estimate |
| NFR catalogue and signed SLOs | Anything that has to be tested against a number |
| Privacy Office position | Customer-facing release |
| Named accountable owner for the shared runtime | Incident response, cross-BU decisions, and the co-delivery cost option |
| CAUCE / CAUEX reconciliation | Evidencing what is actually built |
| Re-homing Readiness, Testing, GTM, Stabilization, Scale Planning | Launch readiness — currently owned by nobody |
Risks to carry into A7
- Environment slippage — recorded in the client's own review as the programme's number-one schedule risk.
- The cancelled operational workstreams — cancelled in the CAUCE-to-CAUEX replan with no inheritor. A roadmap that does not re-home them repeats the mistake.
- Operating model as a gating dependency we cannot resolve — SOW §3.0 puts operating model design out of scope. We sequence around it and name it; we do not build it.
- Criticality tier unresolved — Gold versus Critical Digital Properties changes every recovery commitment by roughly an order of magnitude, and therefore the DR work in the roadmap.
- Cutover with no bypass — the dashboard replaces the only post-login route to every BU portal.
Duration basis, 23 October 2026
Source: Implementation Roadmap & Cost Estimate (Realistic and Optimistic tabs, Cost Estimations, Appendix). The v4 deck, slides 71 and 73, now shows our re-sized durations rather than the Realistic tab's, and slide 72 shows the same plan with no pilot gate. Task sizes below are our judgment from the Appendix task list, not data; the pod leads should check them. The Cost Estimations tab has not been re-run for these durations or for one oversight role in place of three.
Method. Each epic is sized in developer-weeks from its Appendix tasks, +20% buffer, at three developers per work stream and about 85% focus (11 developer-weeks a month per pod). Where an epic is bound by lead time (environments, MDM SME, business-unit availability) the bar follows that, not effort.
Finding. Pod effort matches the sheet's staffing for work streams 1, 2 and 4 (within about 15%). Work stream 3 does not: the pod is staffed 23 months for roughly 16 months of epics, with idle gaps between the gateway, Group Benefits and rollout bars. The Realistic tab is not padded beyond its stated 20%; its length is sequencing. Optimistic is the same work without the buffer.
| Epic | Realistic tab | Revised | Why |
|---|---|---|---|
| OIDC SSO | Nov 26 to Mar 27 · 5 | Nov 26 to Feb 27 · 4 | Runs first with the whole pod; the BFF and business-unit apps integrate against it |
| Token security | Nov 26 to Mar 27 · 5 | Jan 27 to Apr 27 · 4 | Follows SSO instead of sharing the pod with it; scope still to be confirmed |
| Context resolution | Mar 27 to May 27 · 3 | Mar 27 to May 27 · 3 | Unchanged |
| Latency POC, cookie consent, MDM integration, data projection | as sheet | as sheet | Pod effort fits; MDM and OneTrust are bound by SME and platform decision |
| Identity linking (PingIDM) | Jul 27 to Sep 27 · 3 | Jun 27 to Aug 27 · 3 | One month earlier so linking exists when the pilot starts |
| Unified consent | Aug 27 to Dec 27 · 5 | Sep 27 to Dec 27 · 4 | 36 developer-weeks of work after linking |
| Enterprise API design | Nov 26 to Feb 27 · 4 | Nov 26 to Feb 27 · 4 | Unchanged; bound by VPC and gateway lead time |
| System APIs, Group Benefits | May 27 to Sep 27 · 5 | Mar 27 to Jun 27 · 4 | Gateway done in February; the sheet leaves the pod idle for two months. Needs the pilot business unit named by February |
| System APIs, remaining units | Jan 28 to Sep 28 · 9 | Nov 27 to Jul 28 · 9 | Same effort, two months earlier (see playbook) |
| Data residency | Nov 26 to Dec 26 · 2 | Nov 26 to Jan 27 · 3 | Non-production environments depend on Manulife change control |
| Resilience | Nov 26 to Dec 26 · 2 | Feb 27 to Jun 27 · 5 | PROD and DR region, Akamai traffic management and failover, plus the performance and penetration tests that gate the pilot; the environments risk the client's own review ranks first |
| UI composition | Jul 27 to Oct 27 · 4 | Feb 27 to Jun 27 · 5 | The sheet leaves two work stream 4 developers idle from March to July; starts when the SSO session exists, and ends against the Group Benefits APIs |
| Routing and caching | Jun 27 to Aug 27 · 3 | Jun 27 to Aug 27 · 3 | Unchanged |
| Unleash | Sep 27 to Dec 27 · 4 | Jul 27 to Sep 27 · 3 | About 14 developer-weeks; needed before the pilot cohort ramps |
| Group Benefits pilot | Aug 27 to Nov 27 · 4 | Aug 27 to Nov 27 · 4 | Unchanged; gated by identity linking, PROD and DR, and the pen test |
| Playbook | Nov 27 to Dec 27 · 2 | Sep 27 to Oct 27 · 2 | Written during the pilot, from its first two months |
| Architecture assessment | Jan 28 to Feb 28 · 2 | Oct 27 to Nov 27 · 2 | Business-unit led; starts as the playbook lands |
| Rollout | Feb 28 to Nov 28 · 10 | Dec 27 to Sep 28 · 10 | Same length, two months earlier |
| Milestone 4, one portal | Dec 2028 | Oct 2028 | Net two months; the first wave starts in the pilot's last month |
What would shorten it further. A second integration pod through the three rollout waves (about 29 developer-months of System API work) cuts roughly four to five months, to about the Optimistic date. That is a staffing decision, and one lead architect over five pods is a design authority bottleneck. Business-unit readiness bounds the rollout bars either way.
Shorter-path scenario (v4 slide 72). Same bar lengths and no separate pilot: the rollout starts when Group Benefits does (Aug 2027), and System APIs for the remaining units start a month earlier, straight after Group Benefits' APIs. The playbook and architecture assessment move four months earlier, and marketing activation starts with phase 2 (Jun 2027). Milestones 2, 3 and 4 become Aug 2027, Nov 2027 and Jun 2028, so one portal arrives four months before the plan. It is a scenario for the audience, not the plan of record. It gives up the pilot gate: the playbook is written before any production traffic, not "from its first two months", and every unit needs capacity to start together, which the Cost Estimations tab has not been re-run for. It also starts the rollout while unified consent is still being built (it ends Dec 2027); the plan began the first wave in the month it finished, so the pod leads should confirm that no early wave needs it live. Marketing activation is out of scope and its timing is Manulife's; live activation still waits on unified consent.
Stale registry assumption in the sheet. The Appendix names "PingIDM (ERR)", and the Identity Resolution epic assumes "PingIDM is approved as the enterprise relationship registry platform". That predates ADR-0006 (12 October), which made Informatica MDM the enterprise relationship registry. PingIDM only holds the ECR crosswalk replica. Slides 71 to 73 of the v4 deck carry the corrected wording; correct the sheet too, or the old assumption returns with the next export.
Gaps in the sheet. The Cost Estimations tab leaves no identity capacity after May 2027 and no data or platform capacity after December 2027, though each rollout wave needs OIDC integration, token exchange configuration and policy work per business unit. Context resolution (PingAuthorize) precedes identity linking (PingIDM) in both tabs, although its policies read the ECID schema.
On the cost options
The co-delivery option's viability depends on Manulife staffing that the client's own material describes as absent — "no shared platform team funded to run them", and four components with no business-unit home. Price it, present it fairly, and name that dependency explicitly. A co-delivery number that quietly assumes a team which does not exist is not a cost option, it is a forecast of a slip.
Engagement close
A11 is the last event. Everything the engagement produced should be handed over in the agreed format at or before it — which requires the format question (open questions, item 1) to have been settled well before week six.