D3.2 · Two implementation cost options with ROM estimates

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

What the SOW asks for

Two cost options for the implementation: Konrad end-to-end implementation · co-deliver model

From WS 3 activities 8 and 9: "create two implementation cost options to execute the roadmap: (1) Konrad owned delivery; (2) Co-delivery model" and "develop ROM implementation estimated for each option."

Two options, not a range and not a recommendation dressed as two options. Both have to be genuinely costed and genuinely deliverable.

What each option contains

Element	Content
Delivery model	Who does what — team composition, roles, reporting lines
Scope covered	Which roadmap work streams the option delivers, and which it does not
ROM estimate	Rough order of magnitude, with the basis of estimate stated
Assumptions	What the number depends on
Timeline implication	What the option does to the roadmap's dates
Risk profile	What each model absorbs and what it leaves with Manulife
Manulife commitment required	People, decisions, environments, access

The two options

Option 1 — Konrad end-to-end. Konrad owns delivery of the roadmap work streams. Fastest to mobilize and single-throat-to-choke on delivery risk; leaves Manulife with a knowledge-transfer obligation at the end and does not by itself build internal capability.

Option 2 — Co-delivery. Konrad and Manulife teams deliver jointly. Builds internal capability and keeps domain knowledge in-house; depends on Manulife staffing that the client's own material suggests is contested — "no shared platform team funded to run them" is concern #1 of the readiness review, and four of the eleven new components have no business-unit home.

That last point is worth stating plainly in the deliverable. The co-delivery option's viability is a function of an operating-model gap the client has already identified. Pricing it without naming that dependency would be misleading.

Basis of estimate

A ROM is only defensible if its basis is written down. The estimate should state, at minimum: the roadmap scope it covers; the assumed team shapes and durations; what is excluded (SOW §3.0's out-of-scope list applies to the roadmap too); the confidence range; and the specific unknowns that would move the number most.

Two unknowns dominate today and both are cheap to close:

• Volumetry. No documented TPS, peak concurrency or per-BU rate limits anywhere, against a single known downstream ceiling of 25 TPS at FCC. This drives the API strategy, cache design and capacity work — and therefore the effort.
• Environments. SIT, UAT, PROD and DR Redis provisioning states are pending, pending, not ready and non-existent. Environment readiness is recorded as the programme's number-one schedule risk, and schedule risk is cost.

Where the content is being assembled

• Cost model and options: docs/roadmap/cost-options.md (created when WS 3 starts)
• Scope basis: D3.1
• Working notes: WS 3 tasks

Handling

Commercial content. It goes in the repository so the basis of estimate stays attached to the roadmap it prices, but it is the one part of this knowledge base with a narrower audience than the rest. If the site is ever hosted rather than handed over as files, this deliverable is a reason access control is not optional — see item 4 in open questions.

Acceptance

Written acceptance per SOW §5, presented at the executive readout alongside D3.3.