Why Independent Program Review Exists

If a program really matters, it rarely fails outright. It drifts, and the consequences build until they force themselves into the open.

Timelines slip, costs increase, and benefits get reduced, often gradually enough to feel manageable. On paper, everything still looks fine. The plan hangs together and progress gets reported. But something doesn’t feel right, and you can’t quite see why.

The issue is rarely inside the teams. It sits between them.

Most business-critical programs are approved under what looks like heavy scrutiny. In reality, it is mostly internal, which is not the same as being rigorous. People are, in effect, marking their own homework. The business case is “tested”, but rarely hard enough.

The numbers are challenged, but usually within a shared set of assumptions, and risks are debated and often played down to get the decision through.

Mitigation actions tend to come from the same thinking that created the risk in the first place, which is why the same blind spots get recycled. By the time you approve the program, the plan feels coherent. And that’s usually enough.

Then delivery starts, and the nature of the problem changes.

The issue is not all programs, but the small number that really matter – the businesscritical ones you are personally accountable for, the ones the board is watching, and the ones investors are counting on.

These programs do not behave like the rest. They are more complex, more exposed, and far less forgiving. We see five or six of these business-critical programs every year, and they are the ones that matter most. This is where the cracks start to appear.

Execution spreads across functions, suppliers, and partners. Each part can look as though it is doing its job, especially in the early days. The difficulty lies in how those parts come together.

The real work is not inside the teams, it is between them.

Dependencies are taken for granted, handoffs are assumed, and sequencing looks fine on paper but is rarely tested under real conditions.

Under pressure, that is where your program starts to come apart.

From your position, this is hard to see clearly. Dashboards track activity, governance tracks decisions, and progress gets reported, and it is not always accurate.

What they do not show is whether the program will actually hold together when it matters.

You usually sense this before you can prove it. You know something is not quite right, but you cannot see exactly where or what to do about it.

This is the gap.

You apply rigorous due diligence before committing capital, but you do not have an equivalent discipline that tests whether the program will actually work under real conditions. That exposure sits with you.

An Independent Program Review (IPR) exists to close the gap. It is due diligence applied to execution.

This is work we have been doing for years, often when programs are already under pressure. Across more than 130 complex programs, the same patterns appear.

An Independent Program Review looks at your plan in the context of real delivery and tests whether it will hold together under pressure.

• Are the critical assumptions sound, and if so, how were they tested, specifically?
• Are the dependencies real, owned, and sequenced?
• Will the execution model cope when things do not go to plan?

These questions usually surface a new set of concerns. The issue isn’t whether the plan looks coherent. It’s whether it will actually work.

• Done early, it gives you options while change is still possible.
• Done late, it limits the damage.
• Not done at all, the gap between the plan and the outcome widens until it is too late to recover the original timescales or the original budget position.

By far, the worst time to find out your plan does not work is when you are already committed.

Find out early, or pay for it later.