The Program Delivery Guide

Why this guide exists

Every programme we are asked to look at arrives with the same two documents: a plan that was credible when it was written, and a status report that is still green. Somewhere between them is a date that has already moved and a room in which nobody has yet said so. This guide is about that gap. It is written for the people accountable for a date they did not personally set — programme sponsors, PMO leads, and the executives who will be asked in twelve months why the benefits case has not arrived. It is not a methodology. It is a description of what we see go wrong, in the order it goes wrong, and the small number of decisions that change the outcome.

The month-nine pattern

Months one to six run close to plan. Mobilisation is energetic, the early deliverables are the easy ones, and the first two steering committees are pleasant. Somewhere in months seven to nine the reported status stops matching the felt status. Decisions begin to queue. Workstreams start protecting their own dates. The programme enters a phase in which everyone close to it knows the date has moved and nobody has the standing to say so in the room where it would matter. The Standish data is blunt about how this ends: fewer than one in ten large projects finish on time, on budget and on scope, and half are classed as challenged rather than failed — which is the polite word for stalled.

A stalled programme is worse than a failed one. A failed programme is cancelled. A stalled one keeps consuming budget while everyone privately re-forecasts the date.

Why the third quarter

Because that is roughly when the first genuinely hard trade-off arrives — the decision where something has to give and the person with the authority to give it is not present. Before that point every decision has sat inside someone’s delegated authority. After it, the programme needs a decision that crosses a boundary: scope against date, one division’s convenience against another’s, a benefit promised to the board against a constraint discovered in the data. EY and Oxford’s Saïd Business School found that 96% of transformation programmes experience at least one such turning point. What distinguished the programmes that went on to beat their KPIs was not the absence of a crisis but how leadership behaved inside it.

Five things we find when we open one up

• The cadence is quarterly and the slippage is weekly. By the time a variance reaches a steering committee it is three months old and has already been explained away twice.

• Nobody is permitted to change scope. There is a steering committee and there is a programme director, and neither believes they can say the date has moved without the other.

• The benefits case has drifted from the delivery plan. The business case still describes the outcome that justified the funding; the plan now describes a smaller thing that can be delivered by the date.

• Integration debt has been deferred to the end. The parts each work; the whole has never been run. The last quarter of the plan is carrying the risk of the first three.

• The handover is an afterthought. Nobody has been named to own the change once the delivery team leaves, so the programme is heading toward a go-live that is also an orphaning.

A cadence that surfaces slippage in weeks

The fix is not more reporting. The information is almost always already in the deck, in a colour nobody escalates. The fix is a shorter loop between a variance appearing and a named person seeing it who is able to act. In practice that means three things. A weekly forecast conversation — not a status meeting — in which each workstream lead states the date they now believe, and the difference from last week is the agenda. A single variance log, owned by one person, that records the day a slippage was first noticed rather than the day it was first reported. And a rule that a variance older than two cycles is escalated automatically, so that the decision to escalate is never a personal one.

Decision rights: who is permitted to say no

Ask any programme who can change its scope and the answer is usually ‘the steering committee’. That is not an answer; it is a calendar. A committee that meets monthly cannot clear a decision queue that fills weekly, and its members individually will not pre-empt it. The programmes that recover have one named person with the authority to change scope, who attends the weekly forecast conversation, and who has agreed in advance the limits within which they may act without convening anyone. This is uncomfortable to set up because it makes one person visibly responsible for the date. That discomfort is the point. A programme in which nobody can be blamed for the date is a programme in which the date will move quietly.

A programme that cannot change scope is not a programme. It is a schedule with a budget attached.

Benefits that survive go-live

The business case is written once, to secure funding, and then rarely read. The plan is rewritten every month. The two drift apart until go-live, at which point somebody is asked to demonstrate a benefit the plan stopped delivering a year earlier. The discipline that prevents this is a benefits ledger: each benefit in the business case, the specific delivered thing it depends on, the operational owner who will realise it, and the measure that will show it. The ledger is reviewed alongside the plan, so that a scope change that removes a dependency is seen, on the same page, to remove a benefit. When a benefit has no owner in the operating business, it is not a benefit yet. It is a hope.

Business acumen inside the team, not above it

PMI’s 2025 research found that only 18% of project professionals rate highly on business acumen — and that the teams that do meet their business goals 83% of the time, against roughly two-thirds for the rest. The gap between those groups is most of the gap between stalled and delivered. The practical implication is about who sits where. A programme in which the commercial judgement lives on the steering committee and the delivery judgement lives in the team will make its trade-offs slowly and badly, because each side has half the picture. The programmes that move put someone with the business understanding inside the delivery room, with the standing to say which of two dates matters more.

How we run it: the Taidou Way

Our engagements follow five steps, and they map directly onto the failures above. Position — establish where the programme truly is: felt status against reported status, the age of the oldest waiting decision, the drift between the benefits case and the plan. Define — agree, in writing, who may change scope, what the weekly cadence is, and what the handover will consist of. Engage — run the first cycles alongside the programme team, so the cadence is learned by doing rather than described in a deck. Negotiate — the hard trade-offs, brokered by someone who is not staying and therefore has nothing to protect. Deliver — hand over a working cadence, named owners, and a portfolio view the leadership team maintains themselves. We are paid to leave a programme that no longer needs us.

The handover checklist

Most programmes are handed over at the point of maximum fragility: the delivery team is leaving, the operating team has not yet lived with the change, and the people who understood the trade-offs are already on their next assignment. Before we consider a handover complete, all of the following are true.

• A named operational owner for every benefit in the ledger, who has signed for it.

• The weekly forecast cadence is running without the delivery team in the room.

• One person is named as able to change scope of the remaining work, and knows it.

• The variance log is owned by someone who will still be there in six months.

• Every integration has been run end to end in the operating environment, not the test one.

• The decision queue is empty or every open item has an owner and a date.

• Support arrangements are documented for the first ninety days, with names, not roles.

• The measures that will demonstrate each benefit are being collected already.

• The board or sponsor has seen the current date, not the original one.

• Open risks have been re-owned by the operating business, not closed by the programme.

• The knowledge that lives in individuals has been written down or deliberately accepted as a risk.

• The programme has a closing date after which it no longer exists as a cost centre.

Twelve questions for a sponsor

If you are accountable for a date and want to know whether the programme is at month nine whatever the calendar says, these are the questions we would ask.

• Who, by name, can change the scope of this programme without convening a committee?

• When did the reported status and the felt status last disagree, and who noticed first?

• What decision has been waiting longest, and why?

• What is the current date, and who on the steering committee has heard it out loud?

• Which benefit in the business case no longer has a delivered thing it depends on?

• Who in the operating business owns each benefit, and have they agreed?

• When was the whole system last run end to end?

• What is the oldest item in the variance log, and how old was it when it was first written down?

• Who is the person on the delivery team with the business judgement to choose between two dates?

• Who will own this on the first Monday after the delivery team has gone?

• What are we no longer going to do, and who has been told?

• If we stopped today, what would be left standing?

The uncomfortable part

Somebody has to tell the steering committee the date has moved. In most programmes there is no one whose job that is — a structural gap, not a personal failing. It is also one of the more valuable things an outside firm can do, precisely because we are not staying. If any of the twelve questions above has an answer you would not want read aloud, that is where to start.