Why Transformation Programs End Up Governed by the Rules They Were Meant to Change

The architecture of how most programs are run is borrowed from the very organisations they're trying to transform, and that's where the heaviness comes from.

TL;DR: Three things this covers

1. Why transformation programs become slow and heavy, and why the usual explanations don't get to the root cause.

2. The governing rules most programs unknowingly import from BAU, and the three principles that should replace them: value first, agility, and feedback loops over reporting cycles.

3. What the symptoms look like when this is the real problem, and what good actually looks like in practice, in observable terms.

🎤🎧Audio Version of the Article

If you prefer to listen to this AI-generated deep dive that is solely based on this article, you can listen to it here:
https://www.dropbox.com/scl/fi/dhbhn9yb5amdryst4rnv2/transformation-governing-rules.m4a?rlkey=uwapyian99pgnvcj237g7uy4f&st=vwllyubq&dl=0

You've heard these before. Probably in the last month, by one of the executive team, C-level, or the sponsor.

"Why are we only getting to this now? We could have moved on to this months ago."

"I thought we already agreed on this. Why is there another workshop about it?"

"Why is it taking this long to reach something that was obvious from the start?"

These aren't the complaints of people who don't understand transformation. They come from senior leaders and business unit heads watching from a distance, and what they're seeing is a program that feels slow, cumbersome, and disconnected from the business's pace. The natural instinct is to treat this as a stakeholder engagement problem. They're too focused on BAU. They don't appreciate complexity. They need better communications.

That framing puts the problem in the wrong place.

The real issue: transformation is being run by the wrong set of rules.

Most transformation and change programs are architected, funded, governed, and reported using the same operating logic as business-as-usual. That logic wasn't designed for the kind of work transformation actually is, and importing it wholesale is where the weight comes from.

BAU rules exist for good reason. They were built to optimise for:

• Predictability, doing what was planned, on schedule, with minimal deviation

• Control, maintaining visibility through reporting hierarchies and structured tollgates

• Rigour, thorough sign-off before anything is allowed to move forward

These work well when the path is known, when cause and effect are clear, and when the goal is consistent, repeatable execution. Transformation sits in an entirely different category of work. The path is partly unknown. What seemed like the right decision in month one often looks different in month four, because you've learned something. Dependencies surface only when things start moving. Stakeholder readiness shifts.

When you apply rules built for certainty to inherently uncertain work, the program becomes heavy, sequential, and slow to course-correct. By the time information reaches the people who need to act on it, the window has often already closed. That's not a people failure, it's an architectural one.

Others have named this. The gap is in the practical layer.

To be fair, some of the most well-known thinkers in this space have identified the tension.

John Kotter argued that traditional hierarchies are built for stability, not change, and proposed a second, parallel operating system dedicated to transformation. The concept holds. The difficulty is that most organisations running this dual model still apply the same governance logic to the second system as they do to the first. The structure changes; the underlying rules travel with it.

Dave Snowden's Cynefin framework draws a useful distinction between complicated problems, where expert analysis leads to the right answer, and complex ones, where understanding only emerges through doing. Transformation almost always sits in the complex domain. Governing it with tools designed for complicated work is a category error. The framework names this clearly. What it doesn't resolve is what a program leader does with that insight on Monday morning.

McKinsey research confirms that legacy governance models, static budgets, and annual planning cycles are fundamentally misaligned with the adaptive nature of transformation, and that when run-and-change processes aren't properly connected, the result is typically transformation fatigue and organisational backlash. The diagnosis is accurate. The prescriptions tend to stay at the structural level without translating into the mechanics of how a program is actually run week to week.

The missing layer across all of this is the practical one: which specific rules need to change, what the symptoms look like when they're wrong, and what good looks like in observable terms?

How to tell if this is your actual problem.

Before trying to fix it, it's worth confirming that governance is where the real issue lives. These are the patterns that point in that direction:

Decisions arrive too late to make any changes.

Information travels up through governance layers, gets tabled at a steering committee, and a decision comes back down, often weeks after the point of relevance has passed. By then, the team has either stalled, waited, improvised without authority, or moved on. The program reads as slow because its decision-making rhythm is set by governance cycles rather than by the work itself.

Senior leaders are surprised by things the program team considers normal.

The 'I thought we already agreed on this' reaction is worth understanding carefully. It's rarely a volume problem in communication. What's actually happening is that agreements made early in the program are being revisited, which the program team understands as iteration, while everyone outside the program experiences it as going backwards. BAU governance treats iteration as rework that needs explaining. In transformation, it's how understanding develops.

The program is technically on track and still feels wrong.

RAG status is green. Milestones are being hit. And yet senior leaders have low confidence, business units feel disengaged, and no tangible value has landed anywhere. This is what happens when a program measures activity rather than outcomes. Compliance with the plan and progress toward the goal are being conflated, and they're not the same thing.

Agile is claimed, but the program still runs sequentially.

Many transformation programs describe themselves as agile. In practice, agile sprints feed into waterfall governance. Workstreams run in parallel, but nothing of substance lands until everything converges. The language shifted. The governing rules didn't.

Every decision that matters goes upward.

When something requires a call, a shift in approach, a re-prioritisation, or a response to something unexpected, the only available route is up. There's no mechanism for making decisions close to where the information lives. Everything waits. And waiting, compounded across a multi-month programme, looks exactly like slowness.

What the governing rules of change & transformation programs should actually look like.

The BAU rules aren't wrong in themselves; they're wrong for this kind of work. Change & Transformation needs a different set of governing principles:

Shifting from BAU Governing Rules to Change & Transformation Governing Rules

• form Predictability→ Value first, what lands for the business, and when

• from Control through reporting cycles→ Agility, decisions made close to the work, not above it

• from Governance sets the rhythm→ Feedback loops, short, frequent, action-oriented check-ins

1. Value first, not completion first.

The sequencing question in transformation shouldn't be 'what's the logical order to complete the work? 'It should be 'what can land earliest, and prove that this is real?' That reframe changes how workstreams get designed, how dependencies are handled, and what earns priority. A program that can't demonstrate tangible value within its first 90 days most likely has a sequencing problem, not a communications one.

2. Agility, the operating principle, not the methodology.

This means decisions get made at the level closest to where the relevant information actually lives. It means the program can absorb new information mid-stream without triggering a full re-plan. It means iteration is treated as a normal part of how understanding develops, rather than as a problem requiring justification. Practically, the test is straightforward: can you describe, clearly, who has authority to make which decisions without escalating? Does the team have the guiding principles that help them become autonomous? So they have the right support system? If that map doesn't exist, agility is an aspiration, not a reality.

3. Feedback loops, not reporting cycles.

Monthly steering committees are reporting cycles. They tell you what happened. Feedback loops tell you what to do next, with enough time to actually do something about it. In practice, that means short-cycle check-ins built not to report status but to surface blockers, recalibrate priorities, and make decisions. It means measuring leading indicators, early evidence that the change is taking hold, rather than lagging ones that confirm what was already true three weeks ago.

What good looks like, in observable terms.

Good doesn't mean frictionless. It means the governing rules are matched to the nature of the work. Here's what you'd be able to observe:

• Value lands in tranches. Business units can point to something concrete within the first quarter, not a future-state slide, but an actual improvement already being experienced.

• The program absorbs change without derailing. A leadership shift, a new strategic priority, an unexpected dependency, these get handled and the program keeps moving, rather than triggering a three-month re-plan.

• Decisions happen at the speed of work. There's a clear map of who can decide what without escalating the issue. Escalation routes exist, but they move in days, not weeks.

• Iteration is described as progress. When a workstream changes direction because something was learned, this is called good program management, not rework that needs to be explained away at the next steering committee.

• Senior leaders feel informed rather than surprised. This is not about more communication; it's about the information they receive being timely and meaningful, not a status report that reads green two weeks before something goes wrong.

• The business owns the outcomes. The transformation office is an enabler, not the keeper of the change. Business unit leaders can articulate what they're accountable for delivering, and why.

A final thought.

Changing the governing rules of a transformation program mid-flight is genuinely hard. The business case was approved against a set of assumptions. A steering committee endorsed the governance structure. The reporting format has been running for months. There's real inertia across the whole thing.

But the cost of not changing them is a program that keeps producing the same frustrations, stakeholders asking why things are taking so long, value arriving later than anyone expected, and a team working hard inside a structure that's quietly working against them. The weight doesn't come from the ambition of the transformation. It comes from the rules it's operating under.

That's the thing worth changing first.