Your Plan Looks Solid. That’s Not the Problem

You’ve just approved a major program.

The plan looks solid. The risks are known. Mitigations are in place. That’s not the problem.

The problem is control. More specifically, whether you understand those risks well enough to stay in control once the program is underway.

Because what happens next is where things start to shift.

It usually starts quietly

Large programs are built on high-level assumptions about how things will interact. In reality, there are hundreds of dependencies. They don’t fail dramatically; they land slightly late, slightly out of sequence, or not quite in the way the next team expected.

Individually, each one looks manageable. In aggregate, they begin to change the behaviour of your program. Before long, it is no longer behaving as the plan suggested it would.

At this point, most leadership teams still believe they are in control. If you’re honest, this will feel familiar.

What’s actually happening is more subtle. The plan hasn’t failed – it’s being tested in ways it was never fully designed for.

And the reason becomes clearer when you look at how those risks were understood in the first place.

To understand why, you have to look back at how risk was handled at the outset.

At the outset, risks are described in abstract terms – simplified, overgeneralised. That’s inevitable. Mitigations are framed the same way – enough to make them, and their potential impact, understandable, but not enough to show how they will behave in practice or how they can be truly dealt with.

So when the program begins to move, it is not just executing the plan – it is discovering how those risks actually behave under real conditions.

By that point, you are already on the hook to deliver the benefits. Backtracking is no longer realistic. Alternative paths may exist, but they are rarely visible at the outset.

This is where most programs lose their grip.

Mitigation, in that context, is not a statement of intent. It is a substantial piece of work.

It needs to be specified like anything else – what will be done, by whom, with what capability, at what cost, and in what sequence. Without that level of specificity, the mitigation exists in theory but not in delivery – and control is assumed rather than established.

From there, the pressure shows up in predictable places.

That exposure doesn’t happen evenly. It shows up in very specific places – where assumptions meet real conditions, where work crosses boundaries, and where the organisation itself starts to shape the outcome.

That’s where control is either established – or quietly lost.

First, where assumptions meet reality.

Plans are approved because they make sense; they are rarely tested under the conditions they will actually face.

So this is the moment to force the plan to behave – before your program does.

Walk the sequencing end to end. Stress the capacity. Test whether the dependencies actually line up under realistic conditions – not as a paper review, but as a practical test of whether the system holds together.

If that hasn’t happened, your program is already carrying hidden risk. It just hasn’t surfaced yet – and your sense of control is likely overstated.

Second, where work crosses boundaries.

Most critical issues don’t sit within teams – they sit between them: handoffs that aren’t fully defined, dependencies that are assumed rather than locked, responsibilities that look clear on paper but diffuse in practice.

This is where drift starts. The joins have to be treated as first-class work – made explicit, owned, and tested early. If they haven’t been properly exercised, your program is already out of sync. You just won’t see it yet – but control is already slipping.

Third, the organisation itself.

Large organisations are not frictionless systems; they are collections of strong domains, each with their own priorities, pressures, and lines of control. Integration and cooperation have to be worked for. They rarely come for free.

So teams do what makes sense locally, even when it creates friction elsewhere. No one is behaving irrationally, but the system begins to optimise itself in the wrong direction.

At that point, pushing harder doesn’t restore control. The system has to be actively orchestrated – trade-offs made visible, conflicts resolved early, and system outcomes prioritised over local progress. If that orchestration isn’t happening, your program will continue to move – but not in the direction you intended.

Fourth, what you’re being told.

By the time issues reach formal governance, they have usually been shaped – not dishonestly, but selectively. Confidence is maintained, ambiguity reduced, edges are smoothed.

Which means you are often steering your program on a partial view of what is actually happening.

So proximity matters. Staying close to where teams, systems, and suppliers come together is the only reliable way to see how your program is really behaving – and where you still have the ability to act. If you’re relying on formal reporting alone, you are already one step removed from reality – and one step away from effective control.

Fifth, the space for challenge.

Most programs allow for review; far fewer allow for real challenge. Challenge takes time, creates friction, and slows things down in the short term, so it is often compressed or deferred.

But in aggregate, that avoidance creates a different kind of drag – delay, rework, and time wasted at exactly the points where clarity and speed are needed most.

Introducing real challenge early, while the plan is still fluid, strengthens the outcome and reinforces control. Waiting simply increases the cost – and reduces your ability to influence it.

Finally, people.

In most large programs, key individuals are seconded in from the business. On paper, that makes sense; in practice, it creates an ongoing structural tension.

Their career, salary, bonuses, reputation, and future still sit firmly in their home organisation, under the control of their functional director. That conflict is real. So when difficult moments arise, they are pulled in two directions.

Most don’t choose explicitly; they manage the tension, soften the message, and delay escalation.

Entirely rational behaviour – but in aggregate it creates drag exactly where clarity and speed are needed most. If this isn’t addressed directly, you will see delay without immediately seeing why. Control erodes quietly.

The answer is not to ask for different behaviour but to change the conditions: make accountability visible beyond the program, provide air cover for escalation, bring difficult decisions into the open, and, where necessary, introduce capability that can operate without those constraints.

At this level, execution is not a process problem.

It’s about whether you are truly in control – seeing what is really happening in your program and acting early enough to change the outcome.

The patterns are well understood by the people who’ve had to recover programs like this. The failure modes are familiar. They’re just not tackled early enough to make a difference.

So, the question is not whether these forces are present in your program.

They are.

The question is whether you recognise them early enough to act – or wait until they show up at full scale.

Because the window to intervene is always there at the start.

It just closes far more quickly than you might think.