# Transformation Playbook

A maturity improvement playbook for practical execution. It defines the target
state, action path, owners, operating rhythm, and acceptance criteria.

## Reference Mood

Transformation playbooks / operating models / Deloitte-style roadmap materials.
Organize content around target state, capability gaps, initiatives, owners,
cadence, and metrics.

The emphasis is on delivery mechanics and acceptance, not reassessment.

## When To Use

- A maturity assessment is complete, and the next step is transformation, governance, platformization, or capability building.
- 30/60/90 plans, transformation roadmaps, governance operating models, and capability improvement plans.
- Materials for transformation leads, platform leads, PMOs, and execution teams.
- Situations where the problem is already understood and the question is how to move it forward.

## Information Architecture

- Define the target state first, then convert gaps into initiatives.
- Every initiative needs a why, what, owner, deliverable, and success metric.
- Resolve foundational dependencies before scaling broader actions.
- Operating rhythm and acceptance criteria are as important as the roadmap.
- A playbook must be executable, not merely advisory: each phase should include
  dependencies, cadence, escalation or decision mechanism, and closeout criteria.

## Structure Pattern

1. Target state: define the target maturity, target capabilities, expected benefits, and picture of success.
2. Guiding principles: explain the principles and trade-offs that should shape execution.
3. Gap to initiatives: map key gaps into concrete initiatives.
4. Roadmap: organize actions, deliverables, dependencies, and acceptance points by 30/60/90 days or by phase.
5. Ownership model: list owners, RACI, decision mechanisms, and collaboration model.
6. Operating rhythm: define meeting cadence, review cycle, escalation path, and reporting mechanism.
7. Success metrics: define metrics, pass criteria, review method, and next actions.

## Visual Language

- Action-oriented, checklist-friendly, and explicit about accountability.
- Works well with a gap-to-initiative map, roadmap, RACI table, stage gates, and action checklist.
- The roadmap should express phased delivery, not vision slogans.
- RACI and success metrics should be tables so execution can be checked.
- Stage gates should clarify entry and exit conditions.

## Visualization Style

- Primary visualization family: phased roadmap or stage-gate timeline that
  makes sequence, dependencies, ownership, and closeout criteria visible.
- The second report section should map issues into a gap-to-initiative or
  roadmap matrix before expanding work packages.
- Supporting visualization blocks: initiative table, acceptance table, and
  ownership/RACI table. Capability matrices and prescription cards are optional
  supporting blocks only when they clarify the gap-to-target plan.
- Put the evidence boundary or caveat near the top of the visual companion,
  before dense initiative tables, when the playbook is based on static evidence.
- Initiative and acceptance tables should preserve pass checks, owners, timing,
  evidence artifacts, and impact from the Markdown report.
- For mobile readability, render each work package as a compact narrative block
  with trigger evidence, dependency, next action, cadence, escalation or
  decision forum, pass check, closeout criteria, owner, timing, evidence
  artifact, and impact. Use tables as compact summaries, not as the only place
  where execution mechanics are visible.
- If an evidence artifact is proposed for future work, mark it as proposed and
  use a repo-relative path such as `[proposed] artifacts/validation-output.txt`.
  Do not use a local absolute path for an artifact that does not exist yet.

## Content Granularity

- Each initiative should be a work package that can be delivered and accepted independently.
- A work package should name dependencies, cadence, escalation path or decision
  forum, and closeout criteria.
- Proposed evidence artifacts should be reviewable placeholders, not local
  machine paths.
- Keep recommendations focused so they do not become a long backlog.
- Every phase should have deliverables and acceptance signals.
- If owner, timing, or acceptance criteria are missing, mark them clearly as TBD.

## Boundaries

- Do not merely repeat assessment conclusions; convert them into action.
- Do not include recommendations without an owner, timeline, deliverable, or acceptance criteria.
- Do not write this as a score report, opinion essay, or status dashboard.
- If data is missing, use `[owner TBD]`, `[due date TBD]`, or `[acceptance criteria TBD]`.