The Execution Threshold: Is Your Organisation Set Up To Deliver This Program?

Before committing fully to a major program, every senior team should ask one uncomfortable question:

“Are we about to approve, or do we already have, a program that our organisation is not actually set up to deliver?” 

Most senior teams have built organisations that deliver change constantly. They know how to appoint sponsors, create workstreams, select suppliers, establish governance, track progress and report to the Board.

That model is proven. It may have worked many times before.

But some programs go beyond normal business change. They depend on too many assumptions, suppliers, decisions, handoffs, operating teams and external conditions lining up under pressure.

At that point, the issue is no longer whether the organisation can manage activity. It can.

The issue is whether its normal delivery model can control the conditions the outcome depends on.

That is the execution threshold.

A program crosses the execution threshold when normal management can still run the activities, but can no longer reliably control the conditions needed for the outcome to succeed.

Once that threshold is crossed, the program is in a different league. The normal machinery of program management remains necessary, but it is no longer sufficient.

A program is likely to be approaching the execution threshold when too many important assumptions must prove true at the same time; underperformance would damage the business, not just the timetable; success depends on several parts of the organisation acting as one delivery system; no single function controls all the levers needed to deliver the outcome; the difficult work sits in the handoffs, interfaces, sequencing and decisions between teams; and substantial parts of the outcome sit with suppliers who are contractually accountable but not operationally integrated.

These are the conditions senior teams need to understand before they approve the program, commit the date or reassure the Board that the work is under control.

The danger is that programs above the execution threshold often look reassuringly normal.

They have a sponsor, a plan, workstreams, suppliers, governance, dashboards and Board reporting. On the surface, everything appears sensible.

But the execution threshold is not about whether those ingredients are present.

It is about whether they are strong enough for the work being attempted.

A program can look familiar and still be structurally underpowered. The plan may describe the work, but the delivery model may not control the conditions that determine whether the work can actually be completed.

That is the distinction senior teams often miss.

When The Proven Model Is No Longer Enough

Most organisations are designed to run the business they already have. They are arranged around functions, budgets, reporting lines, operating responsibilities and local accountabilities.

That is how businesses operate. It is not a weakness.

Major programs usually ask the organisation to behave differently.

They require technology, operations, commercial, finance, legal, regulation, procurement, customer service, suppliers and external partners to act as one delivery system. Each part may be highly competent within its own boundary. Each may have good people, sensible plans and legitimate priorities.

But the program outcome depends on how those parts join up.

That is where normal management reaches its limit.

The organisation believes it has created a program model. In reality, it may have created a collection of functional workstreams with a reporting layer on top.

That looks like control.

It is usually coordination.

Below the execution threshold, coordination may be enough. A competent sponsor, clear plan, disciplined PMO and regular governance rhythm can manage the work perfectly well.

Above the threshold, the problem changes. The issue is no longer whether each workstream can make progress. The issue is whether the whole delivery system can be made to move together.

That requires a different level of authority, integration and judgement.

It Is Not Simply A Cross-Functional Problem

The execution threshold is sometimes described too loosely as a cross-functional problem. That is not precise enough.

Almost every meaningful program touches more than one function. That alone does not mean it has crossed the execution threshold.

For some programs, the substantial work is concentrated in one or two parts of the business. The contribution required from other functions is limited. Dependencies are few. Assumptions are modest. Suppliers are under control. Decisions can be made through existing governance.

Those programs sit below the execution threshold.

The threshold is reached when several parts of the organisation, often alongside several external suppliers, must complete substantial and interdependent work under pressure for the outcome to succeed.

At that point, no single function controls all the levers. Technology may depend on operations. Operations may depend on supplier readiness. Supplier readiness may depend on commercial decisions. Commercial decisions may depend on regulation, customer impact, finance or Board appetite.

The hard part is no longer the individual task.

It is the system of dependencies between the tasks.

That is why isolated workstream confidence can be misleading. Each team may be telling the truth about its own progress, while the overall outcome remains unsafe.

A program can therefore be green in its parts and amber, or red, as a whole.

The Supplier Trap

Outsourcing the work does not outsource accountability for the outcome.

A supplier may be contractually responsible for delivering a system, platform, service or implementation. The contract may allocate responsibility, define service levels and include penalties.

That matters, but it does not create an integrated delivery system.

The client still has to control the overall conditions of success: assumptions, dependencies, interfaces, decisions, readiness, acceptance, integration and business impact.

This is where many major programs become vulnerable. The organisation believes risk has been transferred because work has been contracted out. In reality, the supplier’s delivery is only one part of the outcome.

If several suppliers are involved, the challenge becomes sharper. Each may be managing its own scope properly while the gaps between them remain unmanaged.

Contracts can define responsibility. They cannot, by themselves, make separate organisations behave as one delivery system.

Above the execution threshold, supplier management is not enough.

Supplier integration becomes one of the central tasks of delivery.

The Senior Coordinator Problem

One reason this problem is missed is that the program can look well organised.

In some organisations, the person called the program director is really being used as a senior coordinator with the ear of the CEO. They are often trusted, knowledgeable, well connected and politically safe.

They organise reviews, capture actions, arrange follow-up meetings, assemble the progress view and maintain the reporting rhythm. They understand the organisation, know its politics, have access to senior people and give the CEO a reliable account of what is happening.

That appointment feels sensible and often has real value.

The problem is that this is not the same as directing a business-critical program.

These people often see the underlying issues more clearly than almost anyone else. They know where the weak assumptions sit, which dependencies are being finessed, which executives are avoiding difficult decisions and where the program is relying on hope rather than control.

But they may be reluctant to say it plainly because doing so would upset people whose cooperation they need.

They can explain the issues, describe the state of play and keep everybody informed. That is useful, but it is not the same as changing the conditions of delivery.

A business-critical program needs someone with enough authority, judgement and experience to force decisions, resolve trade-offs, tighten dependencies and make separate parts of the organisation act as one delivery system.

Those are different jobs.

One keeps the program conversation moving.

The other changes the conditions that determine whether the program succeeds.

Above the execution threshold, senior coordination is not enough.

How To Recognise It Before The Damage Appears

The warning signs are visible before the program starts.

At that point, there may be no missed milestones, supplier disputes, red risks or disappointing benefits. There is only the proposed outcome, the assumptions behind it, the work required and the organisation expected to deliver it.

That is enough to ask the right question:

“Can this outcome be delivered by managing the component parts well, or does success depend on the whole delivery system working as one?”

If a lead function can manage the work through normal planning, governance, supplier reviews and reporting, the program probably sits below the execution threshold.

But if success depends on several parts of the organisation, external suppliers, systems, operating teams and commercial decisions lining up under pressure, the program may have crossed the threshold before delivery has even started.

The flashing red light comes on when the outcome depends on too many things sitting outside normal management control.

Important assumptions remain untested. Suppliers are central to the result. Decisions cut across budgets, operating priorities and commercial interests. Customer impact, operational readiness, technology delivery, regulatory expectations and benefit timing must all line up.

Underperformance would damage the strategy, rather than merely inconvenience the timetable.

At that point, the question is no longer whether the organisation knows how to run a program.

It is whether its normal program machinery can control the conditions this particular program depends on.

The Management Choice Must Be Made Early

Once the program is under way, the symptoms become visible quickly.

Dependencies begin to bite. Suppliers attend meetings but do not operate as one delivery system. Workstreams report progress while the overall outcome remains uncertain.

Dates become protected rather than tested. Governance receives reports rather than controls events. The Board sees confidence while delivery teams feel unease. People become extremely busy, but forward movement remains weaker than the effort suggests.

By then, the execution threshold has already been crossed.

The better question is the one asked at the start, before approving the structure, committing the date, locking in the governance and appointing the same delivery model used on previous programs:

“Can our execution model control the conditions this program depends on?”

If the answer is yes, normal program machinery may be enough.

If the answer is no, the program needs a different management model from day one: clearer end-to-end ownership, stronger authority at the centre, harder dependency management, active assumption testing, integrated supplier control, faster escalation and direct management of trade-offs across the delivery system.

This is where an Independent Program Review (IPR) becomes valuable.

An IPR is not simply a health check on a program already in motion. Used early, it tests whether the proposed program remains within the organisation’s normal delivery capability or has crossed the execution threshold and requires a stronger execution model.

It helps answer the question senior teams most need to ask before the program begins:

“Is our normal program machinery strong enough for the shape of work we are about to attempt?”

The purpose is not to criticise the team, make the program seem more complicated or replace management judgement with methodology.

It is to avoid making the wrong execution choice at the moment when the program is still easiest to shape.

Below the threshold, normal program machinery is enough.

Above the threshold, it remains necessary, but it is no longer sufficient.

The Cost Of Finding Out Late

The purpose of recognising the execution threshold is to establish which side of it the program is on before the organisation finds out the expensive way.

Once a program has crossed the threshold without being recognised, correction is rarely quick and never cheap.

By then, assumptions have hardened. Dates have become commitments. Suppliers are locked into the wrong rhythm. Governance is reporting the problem rather than controlling it. The organisation must repair its delivery model while the program is already in flight.

That is when the real cost appears.

It is not limited to delay or budget overrun. It includes rework, lost momentum, damaged confidence, diverted leadership attention, supplier friction, operational disruption and benefits that arrive late, arrive smaller or do not arrive at all.

Those costs are rarely visible when the program is approved. By the time they become visible, the organisation has usually already paid too much.

That is why the execution threshold matters.

It is an early warning that a major program has entered a different league and requires a different management model.

The expensive mistake is not crossing the execution threshold.

 

About the author

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