The 20-Page Termination Deck

The client had spent two weeks building it. Twenty pages. Each one a shortfall, dated and sourced, with screenshots of the project board and quotes lifted from status calls. It was not an angry document. That was the unsettling part. It was calm, organised, and exhaustive, the way a person is calm when they have already decided to leave and are now simply assembling the evidence. By the time it landed in front of me, it was not a complaint. It was a case file. The final slide formally requested termination of the engagement.

I had been on the programme for less than a week. An AI and data platform for a maritime intelligence firm, a £350k contract, two months in. I was brought in to replace a delivery lead who was no longer there. Nobody hands you a twenty-page termination deck on your first week unless something has gone badly wrong for a long time, in full view, while everyone looked at something else.

This is what I do now. I am brought into technology programmes that are failing, usually at the point where the client has stopped believing recovery is possible and started documenting why. I diagnose fast, stabilise delivery, install the minimum governance that should have been there from the start, and hand back a programme that can be run by the people who own it. Seven of these. Roughly £5.9m of programmes across them. The maritime one is the cleanest example I have of what a failing programme actually is, underneath the noise. So let me show you the inside of it.

Five days out of forty

The contract had been priced and scoped around a clear expectation: by this point in the calendar, the client should have received something on the order of forty days of tangible, demonstrable output. Working software, validated models, things they could see and touch and judge.

What had actually been produced, when I added it up honestly, was about five days' worth.

Five out of forty. Around twelve and a half percent of the expected delivery. That is the headline number, and it is the number that fills twenty pages.

Sit with the ratio for a second, because the interesting question is not "why was the team slow." The team was not slow. People had been working the whole time. Code had been written. Conversations had been had. Effort had been expended at something close to full capacity for two months. The interesting question is the one almost nobody asks in the room: if real work was happening, why was almost none of it landing as something the client could recognise as delivery?

And the more dangerous question underneath that one: who noticed the gap opening, and why did it take a client building a termination deck to make it visible? Because that is the actual failure. Not the twelve and a half percent. The fact that the twelve and a half percent was a surprise.

What the deck was really showing

When I read the deck properly, and then went looking at the programme itself, I found that it documented the wrong thing. It catalogued symptoms. Missed demos, vague updates, features promised and not seen. What it could not see, because it was written from outside, was the cause. And the cause was almost embarrassingly simple.

There was no backlog. Not a thin one, not a messy one. None. There was no single visible, committed list of what was being built, in what order, to satisfy what.

There was no Definition of Done. No shared agreement on what "finished" meant for any piece of work, which means that everything was perpetually almost-done and nothing was ever actually done.

There was no sprint structure. Work was not broken into bounded, reviewable increments with a beginning and an end. It was a continuous, undifferentiated stream of activity.

And there was no reporting cadence. No regular, structured moment where the work was held up against the expectation and the gap was named out loud.

Jeff Sutherland and Ken Schwaber, when they formalised Scrum, reduced empirical process control to three pillars: transparency, inspection, and adaptation. The phrasing sounds abstract until you watch what happens when all three are missing at once. Transparency is the precondition: you cannot inspect what you cannot see, and you cannot adapt what you have not inspected. A backlog is transparency. A Definition of Done is the standard that makes inspection meaningful. A sprint review is the inspection. The decision to reprioritise off the back of it is the adaptation.

The team genuinely did not know how far behind it was, because there was no instrument capable of measuring it. The twenty-page deck was not evidence that the team had failed to deliver. It was evidence that the programme had been running for sixty days with no way to see itself. The client built the instrument the programme lacked, and the instrument's first reading was: terminate.

Why this keeps happening

It would be comforting to treat this as a one-off, a uniquely badly run engagement. It is not. The base rates are brutal and they are stable.

The Standish Group's CHAOS research, which has tracked software project outcomes since the 1990s, has settled into a depressingly consistent distribution: roughly 31% of projects succeed in the full sense of on time, on budget, with the features required; about 19% fail outright and are cancelled; and the remaining half, around 50%, are challenged: late, over budget, missing scope, or some combination of all three. If you are running a technology programme, the single most likely outcome, statistically, is not success and not failure. It is challenged. It is exactly the murky, drifting, behind-but-not-dead state the maritime programme was in when I arrived.

The scale of the problem extends far beyond individual engagements. The UK's National Programme for IT, launched in 2002 with a budget of £6.2 billion, was called by the NHS "the world's biggest civil information technology programme." By the time it was dismantled in 2011 after nine years, estimates of the total spend reached £12.7 billion. A parliamentary inquiry concluded it was one of the "worst and most expensive contracting fiascos" in public sector history. The root cause findings were familiar: top-down decisions made without local buy-in, no shared definition of what success meant, and no feedback loop between what was being built and what was actually needed. The same three pillars. Missing at a different order of magnitude.

Bent Flyvbjerg has spent his career explaining why. In his work on megaprojects, summarised in How Big Things Get Done (2023, with Dan Gardner), he draws on a database of thousands of projects to show that IT efforts in particular do not just run over. They run over with a fat tail. The average overrun is bad, and the catastrophic outliers are far more common than a normal distribution would predict. His central claim is the one that matters most here: the dominant cause of failure is not poor execution. It is poor framing at the very start. The plan was wrong before anyone wrote a line of code.

He names two mechanisms. The first is optimism bias: the systematic, almost involuntary human tendency to underestimate how long things will take, how much they will cost, and how much can go wrong. The second is strategic misrepresentation: the quieter tendency to shade estimates toward what will get the work approved rather than what is true. A contract scoped to deliver forty days of output in this window was very likely a product of both.

So the gap is born at framing. But a gap born at framing does not have to become a termination deck. It becomes a termination deck only when nobody says so in time. Amy Edmondson's work on psychological safety supplies the missing explanation: the absence of reported problems is not evidence that things are healthy. It is very often evidence that people do not feel safe reporting them. Problems do not surface early as small, manageable signals. They are suppressed until they are too large to hide, at which point they surface all at once, from outside, as a crisis.

The twenty-page termination deck is the document that gets written when suppression finally fails. In a healthy programme, the gap between five days and forty days would have surfaced in week two, as a green-flag conversation. Instead it surfaced in month two, written by the client, with screenshots. The same information. Six weeks too late and in the worst possible hands.

What diagnosis actually looks like

People assume the diagnosis lives in the deck. Read it carefully enough and the answer will be in there. It is not. The deck tells you what the client saw. It tells you nothing about why. The real diagnosis takes two to three days and it is almost entirely conversation.

You do read the deck, closely, but you read it as a symptom list, not a diagnosis. Then you go and ask the questions the deck cannot answer. I have a short set I come back to every time, because they cut straight to whether the three pillars exist.

Do you have a single, visible, committed backlog right now, and can you show it to me? The hesitation before the answer tells you as much as the answer. If they have to go and make one to show you, you have found the problem.

What is your Definition of Done? If you get four different answers from four people, there is no Definition of Done. There are four private ones, and work is being declared finished against whichever is most convenient.

What would need to be true for this delivery date to be accurate? This is the most useful question I know. It reframes the date from a promise into a set of preconditions, and it gives people permission to tell you, sometimes for the first time, that the preconditions were never met.

On the maritime programme the answers came fast and they were consistent. No backlog they could show me. No shared Definition of Done. A date that nobody, when pressed, could actually defend. Two to three days of this and the diagnosis was not in doubt.

What recovery actually looks like

Recovery is not heroic. It is not a war room and a turnaround narrative. It is the dull, fast reinstatement of the mechanisms that should have been there on day one.

I sat down with the technical leads and we built a backlog from scratch. Not a wish list. A real, ordered, committed list of what we were building, sequenced, with each item carrying acceptance criteria so that "done" meant something specific and testable rather than "I think that's finished." We grouped it into sprints, and against each sprint I wrote the outcome it was meant to produce, the milestone it moved us toward, and the acceptance criteria that would let the client judge it. For the first time the programme had a shape you could hold up against the calendar.

Within a month of taking over, we delivered a working proof of concept. The client could open it, use it, and judge it. I want to be precise about what that month bought: it did not prove the programme would ultimately succeed. What it bought was the one thing that had gone missing: visible, demonstrable delivery, held against an explicit expectation. The client could see the work again. That is the moment a termination conversation turns back into a delivery conversation.

They retained the engagement.

What survives contact with reality

Here is the part that vindicates the structural work, and it is the part people underestimate when they dismiss backlogs and acceptance criteria as bureaucracy.

Over the following weeks, the client pivoted. Twice. Two full changes of direction in what the platform needed to be. On the programme as I found it, two pivots would have been fatal. With no backlog and no sprint structure, a pivot does not redirect the work. It dissolves it. There is nothing to re-sequence because nothing was sequenced. You start again, and the budget bleeds out through the restart.

With the backlog in place, a pivot is a different event entirely. It becomes a re-prioritisation, not a reconstruction. You take the committed list, re-order it against the new direction, redefine acceptance criteria for what changed, drop what no longer matters, and keep budget discipline because you can see, line by line, what the pivot costs. We absorbed both pivots without losing budget control. That is not because I am clever. It is because the structure was there to absorb them. The investment in transparency, which looks like overhead on a calm day, is precisely what buys survivability on a bad one.

What the deck really was

I have kept thinking about that document, calm and thorough and twenty pages long. It was not, in the end, a record of a team that could not build software. The team could build software; they did, before and after I arrived. It was a record of sixty days during which nobody, on either side, said the true thing out loud while it was still small enough to fix.

That is what a failing programme actually is. Not an execution failure. A failure of honesty. Honesty between team members who could see the drift and did not feel safe naming it. Honesty between the delivery lead and the client about a date that was never defensible. And, hardest of all, honesty between the people on the programme and themselves, in those weeks when everyone could feel the gap widening and chose, individually and rationally, to keep their heads down and hope.

The intervention is not a rescue. Nobody gets pulled from a fire. What you actually do is much plainer and much harder to fake. You rebuild the instruments that let a programme tell the truth about itself, and then you stand in the room while it does. The recovery is not the new backlog or the working PoC, useful as those are. The recovery is the moment the programme can see itself again, and everyone in the room agrees on what they are looking at. The twenty-page deck is what gets written in the dark. The work is turning the lights back on.