• RACI defines who does the work (Responsible) and who signs off (Accountable), but not who drives it forward

• In multi-partner programmes, this gap creates decision paralysis, accountability games, and finger-pointing

• Five governance frameworks exist: RACI, RASCI, DACI, RAPID, and MOCHA – each designed for different contexts

• For transformation execution, DACI is the right choice: it explicitly names the Driver (who ensures work moves forward) and the Approver (who makes the call)

• For steering committee decisions with multiple stakeholders, add RAPID to name a single Decider

• This article reviews all programme governance frameworks and explains why DACI wins for transformation programmes

You are in a steering committee. The RACI chart is on the screen. The vendor is Responsible for data migration. The client sponsor is Accountable.

Someone asks: “Who is making sure this actually happens? Who is engaging the right stakeholders, scheduling the workshops, chasing the decisions?”

Silence.

The vendor says: “We are doing the work, but we cannot force client decisions.”

The sponsor says: “I am accountable for the outcome, but I am not running this day-to-day.”

Everyone has a letter. No one is driving.

This is the governance gap that quietly kills transformation programmes. Not missing processes. Not bad intentions. Just a framework that assumes someone will drive without ever naming who.

Sound familiar?

Before we go further, I’m curious what you’re seeing in the field.

What RACI Gets Wrong

RACI emerged in the 1950s from management consulting. It was designed for internal projects with clear hierarchies: one organisation, one chain of command, one boss who could hold people accountable.

It defines four roles:

• Responsible – who does the work

• Accountable – who signs off (and supposedly “owns” the outcome)

• Consulted – who gives input before decisions are made

• Informed – who needs to know after decisions are made

This works nicely when:

• One team delivers to one manager

• Authority flows through a single hierarchy

• The Accountable person has direct control over the Responsible person

• Decisions stay within one organisation

It falls apart when:

• Multiple vendors share delivery responsibilities

• Authority is distributed across organisations

• The Accountable person cannot direct the Responsible parties

• Decisions require alignment across competing interests

In other words: it falls apart in transformation programmes.

RACI is not failing because people are incompetent. It is failing because it quietly assumes conditions that no longer exist.

• It assumes a single organisation context, where authority and accountability sit within the same boundary.

• It assumes line management authority, where the Accountable role can direct the Responsible role.

• It assumes decisions are internal, not negotiated across contracts, vendors, and steering forums.

Digital transformation programmes violate all three assumptions by design.

The Three Gaps That Kill Transformation Governance

When you apply RACI to multi-partner programmes, three critical gaps emerge.

Gap 1: No Driver

Who ensures work moves forward?

Who engages stakeholders, schedules workshops, chases decisions, and removes blockers?

In RACI, the Accountable person is supposed to “own” this. But in transformation programmes, the Accountable person is often a senior sponsor, someone with ten other priorities who cannot drive work day-to-day.

The Responsible party does the work. But they are often a vendor who cannot force decisions from the client side. They cannot schedule workshops without client availability. They cannot resolve design disputes between client stakeholders. They cannot approve scope changes.

So work stalls. The vendor waits for the client. The client waits for the vendor. Everyone points at the RACI chart and says: “I did my part.”

In transformation programmes, “Driver” is not an optional governance enhancement.

It is a structural requirement.

Gap 2: No Decision Authority

RACI assumes Accountable = Approver = Decider.

In complex programmes, these are often different people.

Or committees.

Or informal consensus that never quite forms.

The result: decisions bounce between forums. They wait weeks for the next Steering Committee. They die in endless alignment meetings where everyone is consulted but no one is empowered to say ‘yes’ or ‘no’.

I have seen programmes where “Accountable” meant “will be blamed if this fails” rather than “has the authority to make this succeed.”

That is not governance. That is a setup for finger-pointing.

Gap 3: Accountability Without Authority

Someone is marked “Accountable” but cannot actually influence the work.

Architects labelled Accountable for solution designs they cannot enforce.

Architects are often treated as Accountable because they “own the design”.

But owning design quality is not the same as owning delivery outcomes.

Architects can be accountable for architectural coherence, technical integrity, and adherence to principles. They should never be accountable for delivery speed, vendor performance, or business adoption unless they control the levers that make those things happen.

Client managers Accountable for vendor deliverables they cannot control.

Programme directors Accountable for benefits that depend on business changes they have no authority to mandate.

This is pressure without power. It creates resentment, not results.

What Happens When No One Drives

These gaps create predictable failure modes. You will recognise them.

Failure Mode 1: Decision Paralysis

Everything escalates.

Design decisions that should take a day wait for the next Design Authority. Design Authority decisions wait for Steering Committee. Steering Committee defers to “offline alignment”.

A Fortune 500 manufacturing firm learned this the hard way during their global ERP rollout. They assigned regional business units as “Consulted” for global process templates.

The regions interpreted “Consulted” as “Consent Required”.

43 Regions flooded the programme with over 2,000 change requests to localise the processes. The system integrator ground to a halt, waiting for the Programme Director to resolve the conflicts. The Programme Director lacked the political power to overrule regional VPs.

The programme paused for six months. Five million dollars burned in “standby army” costs – consultants and contractors waiting for decisions that never actually came.

The RACI was perfect on paper. Everyone had their letter.

And the programme nearly died.

Failure Mode 2: The Blame Game

RACI becomes a legal document for post-mortems rather than a collaboration tool.

People hide behind their letter.

• “That is not my R”.

• “I was only Consulted, not Accountable”.

• “The RACI says the vendor is Responsible, so this is their problem”.

I have watched vendors and clients spend more energy and time defending their RACI assignments than solving actual problems.

The framework designed to create clarity becomes a weapon for avoiding responsibility.

Failure Mode 3: The Integration Gap

In multi-vendor programmes, each vendor is Responsible for their piece. No one is Responsible for making the pieces fit together.

Vendor A delivers their scope.

Vendor B delivers their scope.

Neither works with the other because no one drove the integration. Each vendor points at the RACI: “We delivered what we were Responsible for, and what’s in our statement of work (SoW)”.

The client, marked Accountable for overall success, is left holding the pieces.

Failure Mode 4: The Anti-Agile Effect

Practitioners working in agile transformations often find RACI causes friction at the team level.

RACI focuses on individual accountability: “I did my job”.

Agile focuses on team accountability: “We delivered the value”.

When you overlay RACI onto agile teams, people revert to “ticket passing” behaviour. They complete their assigned task and throw it over the wall. The agile, collaborative, outcome-focused mindset breaks down.

This does not mean governance is unnecessary. It means RACI is the wrong framework for how modern programmes actually work.

The Five Governance Frameworks: A Complete Review

RACI is not the only option. Four other governance frameworks exist, each designed to solve different problems.

Before choosing a governance framework for your transformation, you need to understand what each one does, and what it does not do.

Framework 1: RACI

Stands for: Responsible, Accountable, Consulted, Informed

Origin: 1950s management consulting, designed for internal projects with clear hierarchies

What it defines:

• Responsible: Who does the work

• Accountable: Who owns the outcome and signs off (rule: only one A per task)

• Consulted: Who provides input before the work is done (two-way communication)

• Informed: Who is told after decisions are made (one-way communication)

What gap it fills: Basic task clarity, i.e. who does what

When to use it:

• Single-organisation projects with clear reporting lines

• Tasks where the Accountable person has direct authority over the Responsible person

• Simple approval workflows

When NOT to use it:

• Multi-partner programmes with shared accountability

• Complex decisions requiring explicit decision rights

• Situations where “Accountable” lacks authority over “Responsible”

The core weakness for transformations: RACI does not define who drives work forward or who makes decisions. It assumes the Accountable person does both. In multi-partner programmes, they usually cannot.

One-line summary: RACI tells you who does and who approves but not who drives or who decides.

Framework 2: RASCI

Stands for: Responsible, Accountable, Supportive, Consulted, Informed

Origin: Variant of RACI, adds a Support role for complex delivery

What it defines:

• Responsible: Who does the work

• Accountable: Who owns the outcome

• Support: Who actively helps the Responsible party (hands-on assistance, not just advice)

• Consulted: Who provides input

• Informed: Who is told after decisions are made (one-way communication)

What gap it fills: Clarifies who is hands-on helping versus who is just advisory

When to use it:

• Multi-party delivery where teams actively support each other

• Situations where “Consulted” is too passive so you need people rolling up their sleeves

• Vendor-client relationships where the client provides active support (data, access, decisions)

When NOT to use it:

• When you need decision clarity (RASCI still has no explicit Decider)

• When you need a Driver role (RASCI still assumes Accountable drives)

Why it is not enough for transformations: RASCI improves on RACI by distinguishing active support from passive consultation. But it still has the same weakness for transformation scale: no explicit Driver, no explicit Decider. Adding the Support role helps with execution clarity but does not solve the governance gaps.

One-line summary: RASCI clarifies who helps but still does not clarify who drives or decides.

Framework 3: DACI

Stands for: Driver, Approver, Contributor, Informed

Origin: 1980s, developed for environments where decision-making clarity was critical

What it defines:

• Driver: Who drives the work forward: coordinates inputs, schedules decisions, chases blockers, ensures progress. Does not do all the work but makes sure it happens.

• Approver: Who makes the final call. One person with decision authority. Their ‘yes’ means go; their ‘no’ means stop.

• Contributor: Who provides input and does parts of the work. Combines RACI’s Responsible and Consulted.

• Informed: Who needs to know the outcome.

What gap it fills: Explicitly separates driving from approving. Names who keeps things moving, distinct from who makes the call.

When to use it:

• Multi-partner programmes where no single party controls all the pieces

• Workstreams and deliverables that require coordination across teams

• Any situation where work stalls waiting for someone to “drive”

When NOT to use it:

• Simple tasks where driving and approving are naturally the same person

• High-stakes decisions requiring explicit veto rights (use RAPID instead)

Why it works for transformations: DACI directly addresses the Driver gap. The Driver is explicitly named and accountable for progress. Not just for doing work, but for making sure work gets done. This prevents the “everyone has a letter, no one is driving” problem.

One-line summary: DACI names who drives and who decides, the two things RACI leaves ambiguous.

Framework 4: RAPID

Stands for: Recommend, Agree, Perform, Input, Decide

Origin: Bain & Company, early 2000s, designed for complex multi-stakeholder decisions

What it defines:

• Recommend: Who develops the recommendation: gathers input, analyses options, proposes a course of action

• Agree: Who must agree before proceeding – a formal veto right, used for compliance, legal, or technical feasibility

• Perform: Who executes once the decision is made

• Input: Who provides information and perspective influences but does not decide or veto

• Decide: The single person who makes the final call. One person. Not a committee.

What gap it fills: Explicitly names the Decider and distinguishes input (no veto) from agreement (veto). Prevents decisions from dying in consensus-seeking.

When to use it:

• Steering Committee or Design Authority decisions with multiple senior stakeholders

• High-stakes decisions where multiple parties have legitimate interests

• Situations where “Consulted” keeps being interpreted as “Consent Required”

• Go/No-Go gates, major scope changes, strategic trade-offs

When NOT to use it:

• Day-to-day workstream execution (too heavyweight)

• Simple decisions where one person naturally owns the outcome

Why it works for transformations: RAPID solves decision paralysis by forcing clarity on who decides. The Decide role is singular. Input providers can influence but cannot block. The Agree role is reserved for veto requirements, not political comfort.

One-line summary: RAPID ensures one person decides and everyone else knows their role is input, not veto.

Framework 5: MOCHA

Stands for: Manager, Owner, Consulted, Helper, Approver

Origin: Nonprofit and social sector, developed by The Management Center for mission-driven organisations

What it defines:

• Manager: Who supports the Owner and holds them accountable, provides coaching, removes blockers, ensures the Owner succeeds

• Owner: Who owns the work, i.e. the single point of accountability for driving it forward

• Consulted: Who provides input

• Helper: Who actively assists the Owner (similar to RASCI’s Support)

• Approver: Who signs off on the final output

What gap it fills: Separates ownership from management. Clarifies that the Owner drives while the Manager supports and holds accountable.

When to use it:

• Programme leadership structure where sponsor and programme lead are different people

• Situations where senior leaders need to support without micromanaging

• Organisations that value coaching and development alongside delivery

When NOT to use it:

• Corporate IT environments unfamiliar with the framework (requires explanation)

• Decision-heavy governance where RAPID’s explicit Decider is more useful

• Organisations that equate “Manager” with “Boss”

Why it may not be the best choice for transformations: MOCHA is excellent for clarifying leadership dynamics – who owns versus who supports. But it is less known in corporate IT and consulting circles. Introducing MOCHA requires education that DACI does not. For pure governance clarity, DACI achieves the same Driver/Approver separation with less friction.

One-line summary: MOCHA clarifies who owns and who supports, valuable for leadership, but less known in enterprise transformation.

The Framework Comparison: Which One Fits Transformations?

Key observations:

1. RACI and RASCI leave the Driver role undefined. They assume the Accountable person drives. In multi-partner programmes, this assumption fails.

2. DACI explicitly names the Driver. This is the core fix for transformation execution.

3. RAPID explicitly names the Decider and separates Input from Agree. This is the fix for decision governance.

4. MOCHA has an Owner role similar to DACI’s Driver, but is less known in enterprise contexts and requires more education to adopt.

Why DACI Wins for Transformation Execution

For day-to-day programme execution across workstreams, deliverables, cross-functional coordination, DACI is the right governance framework.

Here is why:

1. It names the Driver explicitly.

No more assuming the Accountable person will drive. The Driver role is defined, assigned, and accountable for progress. They coordinate, chase, escalate, and unblock. They do not do all the work but they make sure it happens.

2. It separates driving from approving.

The Driver keeps things moving. The Approver makes the call. These are often different people with different availability and authority. Making that explicit prevents confusion.

3. It is simple enough to adopt.

Four roles. Clear definitions. No extensive training required. Teams can start using DACI in days, not weeks.

4. It works for multi-partner delivery.

When you have vendors, clients, and third parties sharing responsibilities, DACI forces clarity on who is driving coordination, not just who is doing their piece.

DACI in Practice: The Multi-Vendor Success

A financial services organisation used DACI for a multi-vendor ERP- and data-enabled transformation programme. They explicitly assigned the lead system integrator as the Driver for the integrated cutover plan.

This meant the SI had to coordinate the ERP vendor, security vendor, the data vendor, and the client infrastructure team (all Contributors). They could not say “the data vendor is late” and shrug. As the Driver, it was their contractual obligation to chase the data vendor and escalate to the Client Approver only if blocked.

The result: no integration gap. No finger-pointing between vendors. One party was clearly responsible for making sure all the pieces came together. Not because they did all the work but because they drove it.

When to Add RAPID: Steering Committee and Design Authority Decisions

DACI handles execution. But some decisions are bigger. They involve multiple senior stakeholders, competing interests, and political complexity.

For Steering Committee and Design Authority decisions: major scope changes, design trade-offs, localisations, go/no-go gates – consider RAPID.

The power of RAPID is the explicit Decider. One person. Not a committee. Not consensus.

RAPID in Practice: Clearing the Backlog

Remember the ERP programme that burned five million dollars waiting for regional alignment?

They reset using RAPID.

Regional VPs were moved from “Consulted” (which they interpreted as veto power) to “Input” (perspectives welcomed, no veto).

A Global Process Owner was given the Decide role.

The System Integrator was assigned Recommend.

The backlog of 2,000+ change requests was cleared in six weeks. Not because the regions stopped caring. Because the right to veto was explicitly removed. The Decider could hear input and make the call.

This is what good governance does. It does not eliminate disagreement. It ensures disagreement does not paralyse progress.

When Governance Blurs: The ASX Lesson

The Australian Securities Exchange attempted to replace its CHESS clearing system with a blockchain solution. The project failed after years of delay and massive cost overruns.

Post-mortems revealed a governance structure where ASX tried to act as both the Platform Owner and the Systems Integrator despite lacking internal software depth.

The lines between “Client” and “Vendor” blurred. There was no clear architecture veto to stop scope creep. The codebase inflated from 300,000 to 1.3 million lines.

In RAPID terms: there was no Agree function to say “this is not technically feasible.” The desire for features (Input) was never separated from the feasibility of execution (Perform/Decide).

The lesson: governance frameworks must match reality. If you do not have the capability to act as the integrator, do not govern as if you do. And if decisions require technical feasibility checks, make that an explicit Agree gate, not an assumption.

A quick clarification on frameworks

Governance frameworks are not mutually exclusive. They operate at different layers.

• DACI governs execution and coordination.

• RAPID governs decision authority.

• Agile roles govern team delivery.

The Recommendation: What to Implement

If you are a transformation leader deciding on governance, here is the practical guidance:

Replace RACI with DACI for programme execution.

For every major workstream and deliverable, name:

• A Driver who ensures work moves forward

• An Approver who makes the final call

• Contributors who do the work and provide input

• Informed parties who need visibility

Use RAPID for steering committee and cross-functional design decisions.

For major programme decisions (scope changes, design trade-offs, go/no-go gates), name:

• A Recommender who develops the proposal (typically your lead implementation partner)

• A Decider who makes the call (one person, not a committee)

• Input providers who inform but do not veto

• Agree roles only where genuine veto is required (legal, compliance, technical feasibility)

Why not RASCI? It adds Support but still lacks a Driver. The core governance gap remains.

Why not MOCHA? It has an Owner role that functions like a Driver, but is less known in enterprise contexts. DACI achieves the same outcome with less friction.

The Mindset Shift

• RACI asks: “Who is accountable if this fails?”

• DACI asks: “Who is driving this to success?”

That is not wordplay. It is a fundamentally different positioning, from blame assignment to progress ownership.

Questions to Ask (Without Getting Yourself Burned)

If you suspect your programme has a governance gap, here are questions you can raise without sounding like a cynic.

To surface the “Driver” gap:

• “Who is responsible for making sure this moves forward, not just doing the work, but ensuring decisions get made?”

• “If this stalls waiting for input, who chases it?”

• “I want to make sure I understand who is driving this workstream. Can we name that person explicitly?”

To surface the “Decision” gap:

• “Who will make the call if we disagree?”

• “Is the Accountable person also the decision-maker or do they need to consult others first?”

• “For this decision, who has the authority to say yes?”

To propose a fix without confrontation:

• “It might help to name a Driver for this workstream, someone who keeps it moving day-to-day, separate from the Approver.”

• “Can we clarify who the single Decider is for this? I want to make sure we do not end up in circular alignment.”

These questions position you as diligent, not difficult. You are trying to make the programme succeed and you need clarity to do your job.

A Note on Agile Programmes

If your transformation uses SAFe or another agile framework, you may find RACI causes friction at the team level.

This is expected.

RACI focuses on individual accountability: “I did my job.”

Agile focuses on team accountability: “We delivered the value.”

Successful agile transformations often abandon RACI at the squad level entirely.

Teams rely on Scrum roles (Product Owner, Scrum Master, Team) for day-to-day work.

They retain RAPID only for portfolio-level decisions that span multiple teams or trains, the decisions that still require explicit authority.

The principle holds: use the governance framework that matches the work. DACI for cross-cutting coordination. RAPID for strategic decisions. Agile roles for team-level delivery.

The Governance Diagnostic

Signs your programme has a “Driver” gap:

• Work stalls waiting for someone to chase decisions

• Responsible parties say “we cannot move without client input”

• Accountable parties say “I am waiting for the vendor to deliver”

• No one is explicitly named to coordinate across parties

Signs your programme has a “Decision” gap:

• Everything escalates to Steering Committee (and sometime beyond)

• Decisions get revisited after they are made

• Multiple people believe they have veto power

• “Consulted” is interpreted as “Consent Required”

The fix:

• Replace RACI with DACI for deliverables and workstreams

• Optionally, use RAPID for major cross-functional and execution decisions

• Name a single Driver and a single Decider for everything that matters

• Make sure the Driver has the mandate and the bandwidth to actually drive

The Bottom Line

RACI tells you who does the work. It does not tell you who drives it.

In multi-partner transformation programmes, that gap is fatal.

Work stalls.

Decisions bounce.

Accountability becomes blame.

Five governance frameworks exist. For transformation execution, DACI wins: it explicitly names the Driver and the Approver. For steering committee decisions, add RAPID: it explicitly names the Decider and separates input from veto.

The next time someone pulls up a RACI chart and asks “who is Accountable?”, try a different question:

• “Who is driving all of this?”

If the answer is not immediate and clear, you have found your governance gap.

A simple rule for sponsors and programme leaders:

If progress depends on goodwill, informal escalation, or heroic individuals, your governance is already broken.

While retrospectives tell us what went wrong after the fact, pre-mortems offer a chance to see those same risks before they become reality. It’s a simple, powerful shift in mindset: instead of assuming success and reacting to failure, assume failure and plan to prevent it.

Pre-Mortems: A Strategic Reframing of Risk

A pre-mortem is not about being cynical. It’s about being clear-eyed.

This technique, popularised by psychologist Gary Klein, helps teams imagine that a project or programme has failed, and then articulate all the possible reasons why. Unlike traditional risk registers — which often surface only the obvious or already-known threats — a pre-mortem encourages a more creative and candid examination of vulnerabilities.

In the context of large, cross-functional change, pre-mortems allow leadership teams to:

• Pressure-test assumptions that underpin business cases and roadmaps.

• Identify cultural, political, or behavioural blockers that formal planning often ignores.

• Expose interdependencies across teams or initiatives that may not be obvious at the outset.

• Build a shared understanding of what failure actually looks like — and how to avoid it.

Rather than relying solely on bottom-up risk escalation, a pre-mortem gives the executive team direct visibility into the dynamics that may threaten delivery. It facilitates proactive decision-making rather than reactive damage control.

Anatomy of a Pre-Mortem: From Assumption to Action

To conduct a high-impact pre-mortem, it’s essential to go beyond surface-level exercises. The process must be structured, inclusive, and psychologically safe — especially when challenging sacred cows or exposing potential leadership missteps.

Here’s how it typically works:

1. Clarify the Objective: Define what success looks like. What is the intended outcome of the programme? What metrics or milestones matter most?

2. Assume Failure Has Happened: Fast forward 12–18 months. The programme has failed to deliver. Imagine the headlines, the boardroom discussions, the loss of confidence.

3. Identify the Causes: Participants — ideally a cross-section of business, IT, delivery, and operations — list every reason this failure occurred. Nothing is off limits: unrealistic timeframes, underpowered governance, missed change impact, lack of user buy-in, weak sponsorship.

4. Cluster the Insights: Group the risks into themes — technical, organisational, behavioural, political — and assess their severity and likelihood.

5. Turn Risks into Action: Identify countermeasures for the most critical risks. This might include governance changes, sequencing adjustments, redefined KPIs, or a reframed narrative to support alignment.

The key is to embed this process before execution begins — and revisit it at key decision gates as the programme progresses.

Executive-Level Benefits

Senior leaders are the primary custodians of business outcomes. Yet they’re often the furthest removed from daily delivery challenges. Pre-mortems bridge that gap by giving executives direct, unfiltered insight into what may go wrong — and what can be done about it now.

Some of the core benefits include:

• Strategic clarity: Gain confidence that major assumptions and dependencies have been pressure-tested before sign-off.

• Cultural candour: Signal to the organisation that speaking about risk isn’t punished — it’s valued.

• Alignment: Ensure sponsors, delivery teams, and supporting functions are clear on their role in both success and failure prevention.

• Governance resilience: Design oversight that goes beyond reporting — capable of course-correcting when needed.

By investing time in a pre-mortem, leadership teams don’t just prevent failure. They build stronger muscles for delivery, agility, and cross-functional trust.

Making Pre-Mortems Part of the Governance Rhythm

The real power of pre-mortems lies in consistency. While a single workshop can generate valuable insights, embedding pre-mortem thinking into programme governance creates ongoing resilience.

For instance, some organisations:

• Schedule pre-mortem checkpoints before each major investment gate.

• Use “What would make this fail?” as a standing agenda item in executive steering groups.

• Conduct mini pre-mortems for specific workstreams or vendor engagements.

In this way, the pre-mortem evolves from a one-time event to a cultural mindset — one that embraces critical thinking, surfaces dissent productively, and encourages leaders to challenge their own blind spots.

Conclusion: Preparing for Failure to Deliver Success

It’s tempting to believe that a well-documented plan and a high-level sponsor are enough to guarantee transformation success. But the reality is that even well-intentioned programmes falter when organisations fail to anticipate — and mitigate — the many forces that work against change.

A pre-mortem isn’t about slowing down delivery. It’s about making delivery smarter.

By assuming failure and designing from that place, organisations give themselves the best chance to succeed. They protect their investments, their credibility, and most importantly — their outcomes.

Leave a comment

So how do you architect a transformation journey that protects the balance sheet and still delivers operational lift?

Why Strategy Without Structure Fails

Many transformation programmes start with strategy documents full of ambition, buzzwords, and bullet points. But beneath the vision, they lack:

• A sequenced plan that accounts for capability gaps

• Defined investment phases with clear commercial logic

• A benefits model that is measurable, realistic, and cash-aware

Without these elements, organisations either try to do too much at once or follow vendor-led timelines that prioritise technology over business value.

The result? Programmes run hot, cash burns fast, and board confidence erodes before any value lands.

Anchor the Roadmap in Business Reality

A robust roadmap starts not with what’s technically possible, but what’s commercially necessary. That means:

• Mapping the target operating model (TOM) across people, process, data, and tech

• Identifying which changes will unlock measurable EBITDA impact fastest

• Sequencing initiatives to fund later phases through early wins

This isn’t about “boiling the ocean.” It’s about picking the right depth and timing for each investment — focusing capital where impact is real, measurable, and visible to the board.

Bridge the Gap Between Strategy and Execution

The missing link in most plans is execution logic. Great strategy should naturally feed into delivery — but too often, the handoff breaks:

• Vendors propose “Day 1” architectures with no path to get there

• PMOs struggle to translate vision into achievable workstreams

• Sponsors can’t defend the investment case under scrutiny

To avoid these traps, roadmaps must be built backward from desired outcomes, not forward from technology constraints. They should:

• Translate high-level goals into concrete transformation tracks

• Show where investments compound (versus compete) for value

• Include decision gates for reallocation if assumptions shift

When the board sees this level of rigour, they’re far more likely to release funding and stay committed.

Build a Benefits Track, Not Just a Budget

It’s easy to focus on the cost line — but if the benefits case isn’t built in, it’s just another spend programme. A transformation roadmap must have a benefits track that:

• Defines value in business, not technical, terms

• Tracks how each phase contributes to EBITDA or customer outcomes

• Establishes a method for periodic review and scope adjustment

Crucially, the benefits model must be credible, co-owned, and monitored — not buried in a spreadsheet the moment go-live hits.

Protecting Cash While Accelerating Value

Transformation doesn’t have to be a financial cliff. By sequencing phases smartly, and ensuring each builds toward measurable outcomes, organisations can:

• Self-fund later phases through early efficiency or margin wins

• Minimise stranded cost and vendor lock-in

• Retain agility to shift as markets or internal realities change

A good roadmap isn’t about spending less — it’s about spending wisely, and building a transformation journey that sustains executive backing and withstands boardroom pressure.

The Architect’s Role: Independent, Commercial, Pragmatic

Many organisations rely on internal teams or technology partners to build the roadmap. But vendor incentives, internal blind spots, and delivery optimism often skew planning.

An independent architect brings:

• A commercially grounded view of sequencing and scope

• Honest stress-testing of assumptions, timelines, and cost estimates

• The ability to integrate across finance, ops, and tech in one plan

The outcome is a roadmap that isn’t just technically sound, but politically resilient and commercially fundable — one that makes transformation a credible enterprise priority, not a siloed IT initiative.

Final Thought

A clear, value-driven roadmap does more than set direction — it builds confidence. Confidence for the CFO to release funds. Confidence for delivery teams to stay focused. And confidence for the board that transformation will land value, not just headlines.

In today’s climate, that kind of clarity isn’t a luxury. It’s a prerequisite for making transformation real.

Leave a comment

Because slideware isn’t strategy. Because transformation isn’t a technology problem — it’s a value realisation challenge.

Read more

• Ask one question: Will this change how we create or capture value, beyond moving the same work onto a new system?

• Sort the programme into one of three realities: 1/ IT modernisation, 2/ real business transformation, or 3/ digital theatre.

• Then use the matching playbook: what success looks like, what to expect from leaders, and what to say in the room without getting yourself burnt.

The Feeling You Cannot Shake

You are three months into a programme everyone calls a “digital transformation”.

The town halls are energetic. The slides talk about reimagining the business. Your calendar is full of workshops with names like “Future State Design” and “Value Stream Mapping”.

But something does not add up.

The conversations are mostly about system configuration, data migration, and cutover planning (the planned switch from old systems to the new one). The benefits case is a spreadsheet of assumptions nobody has validated. Middle managers smile politely in steering committees, then go back to doing things the way they always have.

You are starting to wonder: Is this actually a transformation? Or is it something else dressed up in transformation language?

You are not imagining it. And you are not the only one who sees it.

This guide will help you diagnose what you are really working on, understand why programmes get mislabelled, and, most importantly, figure out how to do good work and protect yourself regardless of which type of programme you are in.

The Upshift Transformation Test

There is one question that cuts through the noise. Ask it about any programme that carries the word “transformation”:

Does this change how we create or capture value, beyond doing the same work on a new system?

If the honest answer is yes, you are in a real transformation.

If the answer is no but the work is still valuable, you are in an IT modernisation.

If the answer is no and the programme is mostly narrative and optics, you are in digital theatre.

Let me break down each one.

IT Modernisation

The programme is:

• Replacing legacy systems

• Moving to cloud

• Standardising processes across the organisation

• Automating manual work

Example: Moving from an unsupported on-premise ERP to a supported cloud platform, with standardised finance processes and stronger controls, but no change to products, pricing, or routes to market.

The business model stays the same. How the company makes money stays the same. The outcomes are lower cost to serve, better reliability, reduced risk from ageing technology, and improved controls. These programmes are necessary and valuable. They keep the company running. But they are not transformation in the value-creation sense.

Real Business Transformation

The programme is:

• Changing how the company creates or captures value

• Entering new markets or channels

• Launching new products, services, or pricing models

• Fundamentally redesigning how work gets done

Example: Shifting from one off product sales to subscription revenue, redesigning service delivery, incentives, and customer success so retention and lifetime value drive the P&L.

Technology enables new ways of selling, serving, pricing, or operating. Customers, suppliers, or partners will experience the difference. The P&L will move in ways that matter to investors. This is genuine transformation.

Digital Theatre

The programme is:

• Called a transformation because it sounds impressive

• Full of town halls, change campaigns, and glossy communications

• Generating dashboards and decks that look sophisticated

Example: Rebranding an implementation programme as a “customer journey transformation”, while measures of success remain go live, training completion, and dashboard activity.

But underneath, the business operates almost exactly the same. The P&L does not move in a visible way. The main change is new software, new vocabulary, and a lot of activity that does not add up to value. Digital theatre often starts from good intent. But it raises expectations that the programme cannot meet.

Quick Diagnostic Checklists

You are likely in IT Modernisation if most of these are true:

1. The main driver is system age, support risk, or vendor sunset

2. Benefits are described as efficiency, standardisation, control, or compliance

3. Success is measured by go-live date, budget, and adoption rates

4. The benefits case mentions FTE savings but not new revenue or margin

5. Business users describe their work the same way as before, just “on the new system”

You are likely in Real Transformation if most of these are true:

1. There is a specific, measurable change in how the company will make or save money

2. The business case links directly to P&L drivers: revenue, margin, working capital, risk

3. Processes, roles, and decision rights will visibly change

4. Customers, suppliers, or partners will notice the difference

5. Senior business leaders own the programme, not just IT

You are likely in Digital Theatre if most of these are true:

1. Slides are full of vision language but vague on specific value changes

2. People talk about “journeys,” “ecosystems,” and “capabilities” but cannot draw a clear before-and-after for any process

3. Success means “go-live” rather than business impact at month 12, 24, or 36

4. Only a small share of the budget is allocated to changing how people work (process, roles, incentives, training, adoption), compared with technology delivery

5. Middle managers were not involved in design but are expected to “drive adoption”

6. The benefits case looks like an Excel wish list rather than a disciplined model

Why Programmes Get Mislabelled

If you have diagnosed your programme as IT modernisation or digital theatre, you might wonder: why does everyone keep calling it a transformation?

The answer is not stupidity or dishonesty. It is incentives.

“Transformation” gets budget approved.

A request for a $50 million “platform modernisation” faces tough questions. A request for a $50 million “digital transformation” that will “reimagine customer experience” and “future-proof the business” often sails through. The word itself unlocks funding.

“Transformation” accelerates careers.

Leading a transformation is a promotion-worthy achievement. Leading an IT upgrade is just doing your job. Senior leaders have strong incentives to frame their work as transformation, because that is what gets noticed.

External partners reinforce the narrative because it matches how the work was funded and sold.

Changing the label mid-stream creates governance and commercial friction, so most people avoid it. That does not mean the people involved are bad actors. It means the incentives point in one direction, and the easiest path is to keep the original story alive.

Many people see the gap, but few say it plainly in formal forums.

This is not a secret. Senior leaders understand the game. Consultants understand it. Programme team members understand it. The mislabelling is not a mistake – it is a feature of how large organisations work.

Understanding this does not make you cynical. It makes you realistic. And realism is what allows you to navigate well.

What to Expect Once You Know

Once you have diagnosed what you are really in, certain things become predictable. Here is what to expect from different players depending on the type of programme.

If You Are in IT Modernisation

Your boss may still use transformation language in public forums. That is fine – they need to. But in working sessions, the focus will be on delivery milestones, technical stability, and adoption metrics.

Colleagues will be pragmatic. They know this is an upgrade. Conversations will centre on configuration, testing, cutover, and training. Less vision, more execution.

External consultants will focus on implementation methodology and go-live readiness. The transformation narrative in the Statement of Work (SoW) may not match the day-to-day reality of delivery.

Steering committees will track RAG (Red-Amber-Green) status, timeline, and budget. Conversations about business value may be brief or formulaic.

Benefits reviews will focus on cost savings, efficiency metrics, and risk reduction. Expect modest outcomes that are hard to attribute cleanly to the programme.

If You Are in Real Transformation

Your boss will be under genuine pressure to deliver value, not just go-live. Expect hard conversations about outcomes, trade-offs, and business ownership.

Colleagues will include people from the business, not just IT and programme management. Cross-functional tension is normal. It means people care.

External consultants may push for scope that matches the transformation ambition. Watch for scope creep but also recognise that real transformation requires real investment.

Steering committees will ask about value realisation, not just go-live. Expect robust challenge on whether the business is actually changing.

Benefits reviews will be visible and consequential. Business owners will be named. There will be accountability for P&L impact, not just activity metrics.

If You Are in Digital Theatre

Your boss will maintain the transformation narrative in all forums. Challenging it publicly will not go well. The messaging is deliberate.

Colleagues will divide into true believers and quiet sceptics. The sceptics will find each other at coffee machines and in private conversations. You are not alone.

External consultants will validate the vision. Their fees depend on the programme continuing. Do not expect them to name the gap between narrative and reality.

Steering committees will focus on activity metrics, workshops delivered, systems deployed, people trained. Conversations about actual business impact will be brief or deferred.

Benefits reviews will be quietly rescheduled, redefined, or reframed. When they happen, expect explanations about “adoption curves” and “lagging indicators.” The hard numbers may never arrive.

How to Navigate Each Type of Programme

Whatever type of programme you are in, you can do good work, build your skills, and protect your reputation. The approach varies depending on what you are actually working on.

Navigating IT Modernisation

This is honest, valuable work. Your job is to deliver a stable platform that improves reliability, reduces risk, and creates a foundation for future change. Here is how to do it well.

Focus on what is actually measured. Go-live readiness, system stability, user adoption, issue resolution. These are the metrics that matter. Do not overinvest in transformation outcomes that are not in scope.

Be excellent at execution. Clean data migration, solid testing, smooth cutover, effective training. A well-delivered modernisation is career-building work. It demonstrates you can be trusted with complexity.

Manage stakeholder expectations quietly. You cannot contradict the transformation narrative. But you can steer conversations toward realistic outcomes: “After go-live, we will have a stable platform to build on. The real changes to how we work will come in subsequent phases.”

Document your contribution clearly. Keep a record of what you delivered, the quality of your work, and the problems you solved. When the programme ends, you want to be known for solid execution, regardless of what the initiative was called.

Build skills that transfer. Even if this is not transformation, you can develop expertise in system implementation, stakeholder management, cross-functional coordination, and delivery governance. These skills are valuable anywhere.

Navigating Real Transformation

This is rare and valuable experience. Real transformation programmes demand more from everyone but they also offer the most learning and the greatest career impact. Here is how to contribute at your best.

Connect your work to value outcomes. Understand how your workstream contributes to the P&L changes the programme is trying to achieve. If you cannot draw a line from your work to business value, ask until you can. This is how you make your contribution visible.

Build relationships with the business. Real transformation requires genuine partnership with people who own processes, customers, and revenue. Invest time with business stakeholders. Understand their incentives and constraints. This is where transformation succeeds or fails.

Embrace productive discomfort. Transformation is messy. Scope will change. Priorities will shift. Conflict between functions is normal, it means the change is real. Your job is to navigate ambiguity, not to eliminate it.

Challenge constructively. In real transformation, good ideas can come from anywhere. If you see a gap between what is being built and what the business needs, say so, but do it with data, options, and respect. Being the person who asks hard questions well is valuable.

Stay close to change adoption. Technology delivery is necessary but not sufficient. The real work is getting people to work differently. Volunteer for roles that put you close to users, training, and behaviour change. This is where transformation actually happens.

Think beyond go-live. Transformation benefits take months or years to materialise. Position yourself for roles in post-go-live optimisation and continuous improvement. This is where reputations are made.

Document the value story. Keep notes on business outcomes, not just deliverables. When benefits start to land, you want to be able to articulate your contribution. “I helped deliver the platform that enabled a 15% reduction in customer churn” is more powerful than “I was on the technology workstream.”

Navigating Digital Theatre

This is the most politically delicate situation. The gap between narrative and reality is wide. Your job is to do good work, protect yourself, and avoid becoming collateral damage when expectations are not met. Here is how:

Accept what you cannot change. You will not relabel this programme. Your boss needs it to be called a transformation. Fighting that battle is career-limiting and unwinnable. Focus on what you can control.

Do good work within realistic scope. Even if the programme is mislabelled, there is usually real work to be done. System implementation, process improvement, data cleanup – these are valuable. Do them well. Your execution quality is within your control.

Ask clarifying questions diplomatically. You cannot say “this is not a transformation.” But you can ask questions that surface the truth without confrontation:

“Help me understand how this will change how we make money, I want to focus my effort on the right outcomes.”

“What will be different about how we work after go-live? I want to prepare stakeholders.”

“Who owns the benefits after go-live? I want to make sure I am aligned with them now.”

These questions position you as diligent and aligned, not as cynical or obstructive.

Document carefully. Keep your own record of what was in scope, what you delivered, and what assumptions were made about benefits. Not to blame anyone but so you can speak precisely about your contribution when asked. When benefits do not arrive, you want a clear record that you delivered what was funded.

Find the other realists. You are not the only one who sees the gap. Find colleagues who share your perception. You do not need to say it loudly. But working alongside people who see clearly is better for your sanity and your work.

Manage your energy. Stop trying to transform things you were never funded to transform. Do not overinvest emotionally in outcomes that were never realistic. Do good work. Protect your wellbeing. That is enough.

Build transferable experience. Even in theatre, you can develop skills: stakeholder management, navigating ambiguity, delivery under pressure, political awareness. These are valuable. Use this programme to sharpen them, even if the programme itself does not deliver what it promised.

Questions You Can Use

Here are questions you can ask in steering committees, design workshops, or one-on-ones. They surface the truth without putting you at risk.

“How exactly will this change how we make or save money?”

Tests whether the team can connect scope to P&L. In real transformation, this answer is crisp. In theatre, it is vague.

“What would stay the same about how we run the business, even if this programme succeeds?”

Tests whether you are doing an upgrade or a redesign. If almost everything stays the same, it is probably not transformation.

“If we removed all the technology language, how would we describe this change in plain business terms?”

Tests whether this is a technology story or a business story. Transformation should be explainable without mentioning systems.

“Who in the business owns the benefits after go-live, by name?”

Tests whether value accountability exists. In real transformation, business owners are named. In theatre, it is unclear or deferred.

“How much of the budget is for changing how people work, not just implementing technology?”

Tests investment in behaviour change. If less than about 15% of the budget is aimed at changing how people work (process, roles, incentives, training, adoption), it is probably delivery dressed as transformation.

The Coffee Machine Conversation

Sometimes you want to acknowledge reality with a peer without sounding like the bitter cynic. Here is language that works:

“You know, I think what we are doing is important, the platform upgrade is valuable work. I just wonder if calling it a ‘transformation’ sets expectations we cannot meet. But that is probably above my pay grade.”

This names the gap while respecting the reality that you cannot change it. It signals that you see clearly, without positioning you as the problem.

The Quiet Clarity

You probably cannot change what your programme is called. You probably should not try.

But you can stop doubting your own perception. You can adjust your expectations. You can do good work without overinvesting in outcomes that were never realistic.

If you are in a real transformation, you now know what that demands, and what it offers. Engage fully. This is where careers are built.

If you are in IT modernisation, you know what success looks like. Deliver it well. Solid execution is valuable.

If you are in digital theatre, you know the game. Protect yourself. Do good work anyway. Find the others who see it clearly.

And the next time someone asks you about “the transformation,” you will know exactly what you are really working on, even if you never say it out loud.