Every major program is built on assumptions

Every program begins with a plan. Every plan rests on assumptions.

Some are informed. Many are provisional. A large number are educated guesswork – not a few marginal edge cases, but dozens of untested beliefs sitting beneath the plan.

These assumptions cover the hardest parts of delivery: dependencies, sequencing, capacity, decision rights, supplier behaviour, and how the organisation will actually behave once delivery pressure arrives.

At the point these assumptions are made, the resources they depend on are often unknown, unavailable, or not yet hired. Plans assume levels of parallel working that rarely exist in practice. Bottlenecks are rarely identified, and almost never backed by credible mitigation.

Early on, this is tolerated. Momentum depends on it.

When plans harden, something changes – and it is hard to reverse

Once assumptions are absorbed into plans, budgets, contracts, and public commitments, the plan stops being treated as a hypothesis and starts being treated as a fact.

Questioning it now feels dangerous.

Admitting uncertainty feels like admitting loss of control.

The organisation quietly stops asking whether the plan is sound and starts asking whether it can be defended.

Changes that would have been easy early on now require justification.

Corrections become explanations. Explanations become arguments.

This is the point where freedom of movement is lost

By the time this shift is visible, the damage is already done.

Options have narrowed. Costs are sunk. Without any explicit decision, the conversation moves from delivery to containment.

There is no cheap solution at this stage.

Everything takes longer and costs more – not because execution suddenly became hard, but because the underlying requirements were never properly understood.

The plans now in play are almost always built on conditions that never hold in business-critical programs: that resources are effectively unlimited, that dependencies behave as expected, and that nothing material goes wrong.

Something always does.

What follows is entirely predictable

Progress slows. Teams become defensive. Reporting stays reassuring for far too long. The program stops accelerating and begins to flatline.

Most business-critical programs do eventually fail – although failure is rarely called that. More often it is reframed as a recovery, a reset, or a re-baselining.

We know this because we are usually brought in at that point – after the program has already failed to survive real delivery pressure.

By then, delivery is no longer the objective.

Containment is.

And yet the pattern repeats

Organisations continue to commit millions to complex programs on the back of incomplete internal reassurance and fragile assumptions – quietly hoping that this time reality will be more forgiving.

This is inconsistent with how organisations treat every other high-stakes decision. For example:

·  We stress-test acquisitions before signing

·  We scrutinise major investments before committing capital

·  We demand assurance where regulatory or reputational risk exists

Yet program plans – which lock in just as much cost, risk, and exposure – are routinely committed to without any equivalent test of whether their assumptions can survive real-world delivery pressure.

The conclusion is unavoidable

If it makes sense to test a commercial deal before you sign it, it is self-evident that you should test a program plan before you lock it in.

That discipline is what most business-critical programs are missing.

About the author

David Hilliard is founder of Mentor, specialists in strategic program execution.

You can call him on 0118 359 2444 or email david.hilliard@mentoreurope.com.