Skip to content

D2.3 · Stakeholder alignment and feedback summary

Work streamWS 2 — Target State Architecture
SOW sourceSchedule "A", WS 2 deliverables, second bullet
Status⚪ Not started
Indicative windowWeeks 2–4

What the SOW asks for

Stakeholder alignment and feedback summary

Supported by WS 2 activity 6: "conduct working sessions and alignment discussions with the various lines of business IT and leadership teams to get buy in on the vision and approach."

What it contains

SectionContent
Sessions heldWho, when, what was covered, what was shown
Feedback receivedWhat each stakeholder group said, attributed and unsoftened
What changed as a resultThe architecture revisions each piece of feedback drove
Where alignment was reachedExplicitly, per group and per topic
Where it was notThe disagreements that remain open, and what they block

The last row is the one that makes this deliverable worth reading. A summary that reports alignment everywhere is a summary nobody believes. The client material contains an open disagreement between a delivery team and a segment architecture function; a document that reports it as resolved would be wrong, and would be seen to be wrong.

Stakeholder groups

Derived from the client material — to be confirmed and completed during WS 1.

GroupInterest
Canada Segment Enterprise ArchitectureAuthors of the strategy and both critical reviews
Unified Project delivery teamAuthors of the ADS; owns the MVP build
Manulife ID / CIAMOwns identity, the BU Mapping Service, and the platform the MVP runs on
Group BenefitsOwn gateway, largest API surface, MVP1 in scope
Group Retirement (GWAM)MVP1 in scope; Login Handler change required
Wealth (GWAM)Net-new experience API required; FCC capacity constraint
Manulife BankMVP scope
Individual InsuranceLargest tenant on the shared gateway
Seg Funds, AffinityMVP scope; Affinity de-prioritized in the initial release
Privacy OfficeCoverage letter and PIA position — currently unrequested
Security / CISOThreat model, SEC control mapping, penetration test gates
R2R Design Authority / Chief ArchitectCriticality classification and architecture approval

Where the content is being assembled

Diagrams

The diagram version history is built for exactly this deliverable. Cutting a version at each stakeholder session — labelled with something a reader recognises, like "WS2 identity session", carrying the feedback that drove the revision — produces a timeline at /diagrams/history/<slug> that shows, per revision, what changed and whether it was structural or layout only.

That turns "we incorporated your feedback" from an assertion into an artifact. The version log should be cut alongside sessions as they happen, not reconstructed afterwards; a snapshot is immutable once taken, and reconstructed history would make the deltas lie.

Acceptance

Written acceptance from Manulife's project manager per SOW §5.

Internal working knowledge base — not for external distribution.