Once you have a target operating model and a roadmap, the next question is: who is going to run this, how, and with what discipline? Governance and delivery design are what convert ambition into consistent execution.
This chapter focuses on four practical elements:
- Choosing the right transformation governance model
- Defining the role of the Transformation Office (TO) and avoiding common failure modes
- Designing workstreams and integration routines that keep everything joined up
- Tracking progress, managing risks, and correcting course when reality bites
15.1 Choosing the Right Transformation Governance Model
A TOM transformation is not “just another project.” It cuts across business units, functions, technology, risk, and people. The governance model must:
- Keep ultimate accountability with the executive leadership, not with a project team
- Provide enough structure to manage complexity
- Avoid creating a parallel universe that competes with business-as-usual (BAU)
You can think of governance in three tiers:
- Enterprise leadership and sponsorship
- Transformation governance (Transformation Steering and Transformation Office)
- Workstream / wave-level delivery
1. Enterprise leadership and sponsorship
At the top, you need:
- A single accountable sponsor (often the CEO, sometimes the COO or a BU CEO for scoped TOMs), clearly visible.
- The executive team collectively owning the TOM ambition, value targets, and major design choices.
Their responsibilities:
- Approve the TOM blueprint and roadmap.
- Make cross-cutting trade-offs (e.g., between BUs, functions, or regions).
- Resolve escalated issues that cut across mandates or politics.
- Review TOM progress and value realization as part of normal business reviews, not as a side topic.
If the TOM is run entirely “below the line” without active executive leadership, it will be treated as optional.
2. Transformation governance: Steering and TO
Just below the executive team, you typically establish:
- A Transformation Steering Committee (TSC)
- A Transformation Office (TO)
The TSC should be a small group (often a subset of the ExCo) including:
- Sponsor
- 2–4 key business / BU leaders
- CIO / CTO (if tech-heavy)
- CFO (for value and investment oversight)
- CRO / Head of Risk (for risk-heavy contexts)
The TSC:
- Owns the overall transformation scope and priorities.
- Approves wave charters, major design decisions, and re-prioritizations.
- Arbitrates between competing demands on resources.
- Ensures TOM stays aligned to strategy and value agenda.
The TO (covered in 15.2) serves this group by providing a single version of the truth and driving integration.
3. Workstream / wave-level governance
At the delivery layer, governance is closer to the work:
- Wave leads (often senior business leaders) own the outcomes of each transformation wave.
- Workstream leads own specific domains (e.g., SME Lead-to-Cash, Shared Services, Data & Analytics, People & Culture, Tech Platforms).
- Design authorities (e.g., Enterprise Architecture Board, Data Council, Risk Policy Committee) validate that designs align with standards and guardrails.
This layer:
- Runs the backlog of initiatives for each wave.
- Escalates only when cross-workstream trade-offs or major risks arise.
- Owns detailed plans, resourcing, and day-to-day delivery.
Lightweight vs heavy governance
You want to be deliberate about how “heavy” governance is:
- If the TOM is enterprise-wide, cross-functional, with substantial capital at stake → you need more formal governance (clear charters, regular cadence, documented decisions).
- If scope is narrower (single BU or function) → governance can be leaner, but still must have clear roles and routines.
In all cases, design governance to be:
- Business-owned, not project-owned
- Integrated with existing forums where possible (e.g., folding TOM updates into existing ExCo and BU reviews)
- Transparent: decisions, assumptions, and changes recorded and accessible
15.2 Role of the Transformation Office (and Common Failure Modes)
The Transformation Office (TO) is the engine room of TOM delivery. Done well, it’s an integration and enablement function. Done badly, it becomes an administrative burden or a shadow hierarchy.
At its core, the TO has six responsibilities:
- Integration and orchestration
- Planning and re-planning
- Risk, issue, and dependency management
- Value tracking and benefits realization
- Standards, methods, and quality control
- Communication and change support
1. Integration and orchestration
The TO:
- Maintains the master view of the roadmap, waves, and workstreams.
- Ensures that workstreams are aligned on priorities and are not duplicating or conflicting.
- Prepares synthesized, decision-ready material for the TSC and executive team.
This is where the TO adds the most value: seeing across workstreams, not inside each one.
2. Planning and re-planning
The TO:
- Coordinates quarterly or semi-annual planning cycles for TOM work.
- Challenges unrealistic plans, over-commitments, and missing dependencies.
- Manages re-planning when reality changes (delays, new regulatory demands, shifts in strategy).
They do not own every Gantt chart, but they make sure:
- Each wave and major initiative has a realistic, integrated plan.
- The overall transformation portfolio remains deliverable.
3. Risk, issue, and dependency management
The TO maintains the central RAID view (Risks, Assumptions, Issues, Dependencies):
- Aggregates and prioritizes from workstreams.
- Flags themes to the TSC (e.g., systemic tech capacity constraints, recurring data challenges).
- Ensures owners and deadlines exist for key items.
The TO is not there to “own” all risks, but to make sure someone does and that nothing critical falls between gaps.
4. Value tracking and benefits realization
The TO:
- Works with Finance and workstreams to define baseline, targets, and tracking logic for TOM benefits.
- Maintains a benefits tracker tied to initiatives and waves.
- Calls out slippage and helps investigate whether it’s a timing issue, an estimation issue, or a design/execution issue.
Benefits tracking forces the transformation to stay focused on outcomes, not just activity.
5. Standards, methods, and quality control
The TO provides:
- Simple templates (e.g., wave charters, initiative charters, RAID logs, status reports).
- Minimal design standards (e.g., what a journey blueprint must contain, how org proposals should be documented).
- Lightweight quality checks on major deliverables before they go to the TSC or ExCo.
This reduces noise and rework, and lets senior leaders compare apples with apples.
6. Communication and change support
Finally, the TO helps:
- Craft the TOM narrative and core messages.
- Coordinate communications cadence (town halls, leader briefings, updates).
- Support HR / Change teams in planning training, leadership engagement, and local change efforts.
The TO should not replace HR or Communications, but should be the central integrator and driver.
Common failure modes – and how to avoid them
- The “reporting factory” TO
- Symptom: TO spends almost all its time collecting slides and RAG statuses.
- Fix:
- Reduce reporting to a small, standard set.
- Explicitly assign TO time to integration, decision support, and value tracking.
- Stop measuring TO by volume of reports.
- The “shadow management team” TO
- Symptom: TO starts deciding priorities, designs, and resource allocations without real business ownership.
- Fix:
- Clarify: TO prepares options; sponsors and TSC decide.
- Put business leaders as owners of workstreams and benefits; TO supports.
- The “everything escalates” TO
- Symptom: Workstreams push every decision or issue up to the TO, which becomes a bottleneck.
- Fix:
- Define clear decision rights and escalation thresholds.
- Coach workstream leads to solve within their remit; TO only steps in when cross-cutting or material.
- The “isolated from BAU” TO
- Symptom: TO acts as if TOM is separate from normal operations. Line managers see it as an add-on.
- Fix:
- Integrate TOM topics into existing business reviews.
- Include line leaders in wave design and governance.
- Ensure TOM metrics and BAU metrics are aligned.
A simple rule:
If the TO disappeared tomorrow, could the transformation still run?
If yes, the business truly owns it and the TO is doing its job. If not, the TO has absorbed responsibilities that belong to line leaders
15.3 Workstream Design and Integration Routines
Workstreams are how you break the work down so it can be managed. Poor workstream design creates overlaps, confusion, and politics. Good design makes it clear who owns what and how they work together.
Designing workstreams
Start from your TOM blueprint and roadmap (value streams + enabling capabilities). A typical pattern:
- Value stream workstreams
- E.g., “Retail Lead-to-Cash”, “SME Onboarding”, “Claims to Settlement”, “Incident to Resolution”.
- Own end-to-end design and rollout of those journeys.
- Enabling workstreams
- Technology platforms (e.g., CRM, core systems, workflow / integration, data & analytics).
- Shared services & hubs (e.g., Global Operations, GBS, CoEs).
- People & culture (e.g., capabilities, leadership, culture shifts).
- Risk & compliance (e.g., embedding 3LoD, key controls).
Each workstream should have:
- A clear mission: a 2–3 sentence description of what it will deliver.
- A named workstream lead – ideally a respected business or functional leader, not just a project manager.
- A small core team, with contributions from business, tech, ops, risk, and change as needed.
- A defined scope and “out of scope” list.
Avoid:
- Too many tiny workstreams (unmanageable overhead).
- Purely functional workstreams that ignore value streams (e.g., “Operations”, “Sales”, “IT”) – they simply recreate existing silos.
- Workstreams whose success is not linked to clear KPIs and benefits.
Charters and responsibilities
For each workstream, agree a short charter:
- Objectives and key outcomes (linked to TOM KPIs and benefits).
- Scope (processes, geographies, customer segments, systems).
- Major deliverables (designs, pilots, implementations).
- Timeline at a high level (aligned with waves).
- Dependencies (what they need from others; what others need from them).
Clarify:
- Who signs off key designs and decisions within the workstream.
- When and how the workstream escalates to the TO or TSC.
A good charter fits on 1–2 pages and is referred to frequently, not filed away.
Integration routines
Even with clear workstreams, integration will not happen by accident. You need regular, structured routines:
- Weekly / bi-weekly workstream leads meeting
- Attendees: workstream leads, TO, key architects / risk leads.
- Agenda:
- Cross-workstream dependencies and conflicts.
- Upcoming milestones and readiness checks.
- Major risks and issues requiring joint action.
- Monthly wave review
- Attendees: wave lead(s), key workstream leads, TO, sponsor or delegate.
- Agenda:
- Progress toward wave objectives and benefits.
- Design decisions that cut across streams.
- Readiness for upcoming cutovers or expansions.
- Quarterly transformation review (with ExCo / TSC)
- Integrated view of progress, value, risk, and next-quarter plan.
- Decisions on reprioritization, resourcing, and scope.
These routines are as important as the structures themselves. Without them, each workstream will drift toward local optimization.
15.4 Tracking Progress: RAID Logs, Dashboards, and Course Corrections
Finally, you need a way to see what’s happening, act early on problems, and adjust course without losing credibility.
You can think about tracking in three layers:
- Execution health – are we doing what we said, on time and on budget?
- Change health – are people adopting the new model?
- Value health – are we getting the benefits we expected?
Execution health: RAID and milestones
At the workstream level, basic mechanics matter:
- RAID logs (Risks, Assumptions, Issues, Dependencies)
- Simple, living documents – not complex tools.
- Each item has: description, impact, likelihood (for risks), owner, target date, and status.
- Reviewed at least bi-weekly within workstreams; summarized by TO for TSC.
- Milestone tracking
- A small number of milestones per initiative and wave (e.g., design sign-off, build complete, testing done, go-live).
- Traffic lights (Green/Amber/Red) with short commentary: what changed, what’s being done, what support is needed.
The TO aggregates into a master RAID and master milestone view, highlighting:
- Systemic risks (e.g., tech capacity, data issues, regulatory uncertainty).
- Cross-cutting dependencies (e.g., platform delays affecting multiple journeys).
- Areas consistently behind plan that may require scope changes or leadership intervention.
Change health: adoption and behavior
A TOM doesn’t land just because systems go live or org charts change. You need to monitor adoption and behaviors, such as:
- % of volume going through new processes vs. old workarounds
- Usage of new tools and platforms (log-ins, transactions, features used)
- Compliance with new ways of working (e.g., use of standard workflows, new approval paths, daily huddles)
- Qualitative feedback from front-line staff and customers (surveys, interviews, focus groups)
These can be:
- Built into dashboards for journey owners and operations leaders.
- Summarized by the TO as part of monthly wave reviews.
If adoption lags, you know you have a change and leadership problem, not just a “project delay.”
Value health: benefits dashboards
Finally, link to the business case (Chapter 13):
- For each major value lever, track actual vs. target over time.
- Show at least:
- Cost metrics (e.g., FTE, cost per transaction).
- Volume and efficiency (e.g., throughput, automation rate).
- Experience (e.g., NPS, lead times).
- Risk (e.g., incidents, losses, audit findings).
The TO and Finance can maintain a simple benefits dashboard:
- Displaying both realized value and “value at risk” (where TOM delays or under-delivery threaten the case).
- Reviewed quarterly at the TSC or ExCo.
Where measurement is hard or noisy, use:
- Proxies (leading indicators).
- Before/after comparisons at pilot vs. control sites.
- Ranges and scenarios instead of single-valued estimates.
The objective is not false precision; it is honesty about direction and magnitude.
Course corrections: how to react without losing momentum
No TOM roadmap survives first contact with reality unchanged. The crucial thing is how you correct course:
- Reprioritize
- Shift focus to waves or initiatives with higher value or lower execution risk.
- Defer or scale back low-value, high-complexity items.
- Rescope
- Reduce scope where you’ve overreached (e.g., fewer geographies in the first phase).
- Tighten MVP definitions if you’re trying to solve everything at once.
- Re-sequence
- Move foundational tech or data work earlier if it is blocking multiple streams.
- Delay dependent initiatives until prerequisites are truly ready.
- Reinforce
- Swap leaders in critical roles if needed.
- Inject additional capability (e.g., design experts, architects, change leads) into struggling areas.
The governance model should normalize course corrections:
- The TSC expects and asks, “What have we learned? What do we need to change?” rather than only “Why are you off plan?”
- The TO presents options and impacts, not just problems.
- Decisions are recorded, communicated, and reflected in the next iteration of the roadmap and business case.
A simple discipline:
- Each quarterly transformation review must end with three lists:
- What we are stopping or pausing
- What we are starting or accelerating
- What we are continuing as planned
If everything is “continuing as planned” every quarter, you are almost certainly not learning fast enough.
