The failing program nobody is allowed to stop

Consider a two-year program carrying a workstream that no longer has a believer: an integration nobody will use, or a module built for a process that has since been redesigned. Anyone close to that work would say it should come out of scope. The plan has no step that takes it out. Each re-baseline moves its dates to the right and leaves it where it is, and the person who would have to propose its removal is the person whose commitment it was.

Two questions settle what happens to it: who is permitted to stop it, and what stopping costs them. Neither question is about the merits of the workstream. The usual prescriptions are a better dashboard or training on decision bias, and both leave the cost of stopping where it was. Research going back to 1976 on why committed courses of action keep running points somewhere less comfortable.

Continuing is frequently the right call. Patience and paralysis look identical from outside for a long time, and plenty of work needs longer than its first review window. An organization that stops a program over one bad quarter teaches everybody that nothing survives a bad quarter, and then nobody reports a bad quarter.

The escalation evidence and what it leaves out

Barry Staw opened this research line in 1976, and the consolidation worth reading is a meta-analytic review by Dustin Sleesman and colleagues, published in 2012, which sorted the determinants of escalation into four categories: individual, project, social and structural. Personal responsibility for the original choice predicts continuation, as do the need to justify that choice to an audience, the framing in which the decision is put, and an accountability arrangement that treats a reversal as an admission. The framing and the accountability arrangement sit in the design of a review, which is where somebody building one can reach them.

That review is about people deciding whether to keep funding choices they had already made. Carrying it across to a scope boundary needs an argument of its own, and the argument is about accounting.

Removal has to be proposed by whoever owns the commitment, and proposing it puts them back in front of the people who approved it. Keeping the item costs the program money that is nobody’s in particular. Where no one will absorb the first cost, the boundary keeps its shape whatever anyone thinks of what sits inside it, and the program runs until a budget cycle takes the decision out of everyone’s hands. The same accounting runs at program scale, which is where the public record is thick enough to check.

NPfIT and the price of the exit

NPfIT, the English NHS patient-records program launched in 2002, is the fullest version of this in the public record, and the shape of its ending is what makes it useful here. It was described at the time as the largest civil IT project in the world. Parts of it were delivered and outlived it, among them the Spine, the N3 network and NHSmail. The piece at the center, detailed care records, slipped and slipped. The National Audit Office and the Public Accounts Committee both reported on it, and the cost was estimated at £12.7bn at 2004-05 prices, which is the figure to quote with its price base attached, because no final total was ever established.

Three reports and a review by the Major Projects Authority came before the September 2011 announcement, which dismantled the program and kept its components under separate management. Contracts with one supplier for care records across the North, the Midlands and the East were worth £3.1bn, so any decision to stop ran through a renegotiation with that supplier. The Department went into that renegotiation weakly placed, having contracted to make enough trusts available to take the system and being unable to do it.

The program’s condition was documented in public reports well before anyone acted on it. The ordinary machinery for acting is a gate that declines to approve the next stage, and it fails quietly, which is the subject of an earlier piece on what a falling kill rate is telling you. Stage-Gate is one of the models on our Insights page, carrying the condition that page already states, that a funnel of go and kill decisions does nothing unless the kill decisions happen. What had changed by the time anyone reached for the gate was the set of terms available. Commitments the center had already given determined what stopping would cost, and a central function that cannot deliver what it contracted to deliver has little leverage in that conversation.

Accurate reporting against the wrong baseline

Through all of it, the reporting can be accurate. Spend to date is correct, and the re-baselined milestones carry the dates that were approved at the last re-baseline. The failures that last are the ones that never breach anything visible, because a breach is what produces an owner and a date by which they have to answer.

Bent Flyvbjerg’s work on megaprojects adds the upstream half. He attributes megaproject outcomes to selection at the approval stage: the proposals that clear appraisal are the ones carrying the most favorable estimates on both cost and benefit.

Where the stop decision sits

The accounting above leaves whoever designs the review with a choice between two arrangements. The first is to tell the sponsor that stopping counts as a success and leave the stop decision with them. It is free to adopt, and the escalation evidence gives a reason to expect it to fail: the audience the sponsor has to justify the original commitment to is still in the room, and an instruction does not remove an audience.

The second arrangement is the one worth arguing for. It seats the stop decision away from the person who made the commitment, with a reviewer whose own objectives do not include the program finishing, and it requires a governance change that takes time to agree. It also buys a reviewer with materially less context than the sponsor, and the answer to that is to give the role standing to go and ask for the context instead of waiting for it to arrive. Which of the two is in place can be read off the governance papers: write down the name of whoever is allowed to take a workstream out of scope, then check it against the name of whoever committed to it. Whether a reviewer holding that authority ever uses it is a separate question, and the papers do not answer it.