Delivery and retirement plan

Target Play and configuration: Basic / Connected / Advanced
Dimension | Current evidence | Required for Play | Gap type | Owner | Next action
Strategy and customer understanding:
Economics and outcome linkage:
Data, identity and permission:
Measurement and experimentation:
Acquisition, activation or lifecycle execution:
Automation and optional AI:
Operating model, authority and reviewer capacity:
Governance, reliability and recovery:
Skills, adoption and learning:
Funding, support and retirement:
Gap types: Blocking / Value limiting / Scale limiting / Optional

Use colours only as a visual aid to these explicit labels. No overall maturity score. “Advanced” requires evidence for the chosen capability, not a high score elsewhere. When this view feeds D02, complete the versioned fixed prerequisite set for the selected Play/configuration. Do not omit or downgrade a blocking condition such as current permission; supplemental gap rows add detail without replacing source requirements.

Compare existing/manual, configure native, buy missing capability, integrate lightly and build the residual gap. For each option record differentiation, data fit, delivery speed, vendor maturity, integration, total cost, control, portability and maintenance. Add permission boundaries, actual licensed capability, exit and support.

Required decision and acceptance task:
Option | Meets task? | Native proof | Gaps | Five-year cost | Owner | Exit
Existing/manual:
Configure native:
Buy missing capability:
Integrate existing capabilities:
Build documented residual gap:
Chosen option: Buy / Configure / Integrate / Build (or keep existing/manual)
Why simpler options fail the acceptance task or economics:
What would reverse the decision?

For centralisation, share standards, scarce methods and cross-team controls where useful; embed customer context and local execution. Require measured recurring coordination demand before a new shared team. For real time, state the valuable latency requirement and test native event handling first. For personalisation, require meaningful need differences, available treatments and net benefit above variant maintenance. These are option tests within T5, not new architecture frameworks.

Accountability, not proposed title:
Purpose / outcomes / decisions and actual authority:
Human judgement and relationship work:
AI-assisted work / automated work / external support:
Skills demonstrated in real tasks:
Volume, allocated time, cover and specialist bottlenecks:
Metrics: commercial, quality, reliability and burden:
Existing work that stops or transfers:
Dedicated role or persistent team justified? Evidence and funding:

Phase / selected outcome / accountable owner / review date:
Prerequisites and named gate evidence:
Actions, dependencies, staff-days and cost by existing role:
Available capacity and competing commitments:
Work displaced; specialist and review bottlenecks:
Measurement: contribution, customer, accepted-work cost, evidence, reliability:
Decision gate: Continue / Fix first / Stop; predeclared local thresholds:
Support owner, absence cover, maintenance and vendor-change review:
Old process/tool/report/meeting to retire, date and closure owner:
Replacement acceptance and fallback before retirement:
Records/export/retention, access removal and contract action:
Actual cash or capacity realisation and Finance verification:

60-minute planning workshop: Confirm the Play and blocking gaps; allocate actual capacity; test the smallest implementation option; set the next gate; name one retirement. If no work can stop and no capacity can be added, reduce scope. A deep assessment is warranted for customer-impacting automation or material platform investment; it uses system tests, quotes and operational evidence.