Project Post-Mortem

What this actually is

Project Post-Mortem is a browser game in which a language model plays four witnesses to a failed £2.1m IT programme, and you get 25 questions to work out why it failed. It is a practice ground for root cause analysis — the skill of finding the system fault behind the obvious culprit — and it teaches by resistance rather than by lecture.

Retrospectives and post-mortems are usually taught from slides: here is the template, here is the blameless principle, here are the five whys. The trouble is that a difficult conversation looks nothing like a template. It looks like a person telling you the truth — but not all of it, because part of it is inconvenient for them.

This game reproduces that resistance. The model plays four witnesses to a collapsed programme, each with their own interests, their own version of events and their own secret. Nobody lies outright; everybody shifts the emphasis. A witness opens up only when you ask a question that cannot be answered with a generality, or when you confront them with what somebody else has already told you.

The case: Phoenix

Thornbury Systems, a Bristol integrator, was to deliver an ERP rollout for Barrowfield Distribution — a catering and janitorial supplies wholesaler with 280 staff across four depots. The plan was six months and £900,000. Fourteen months and £2.1m later, Barrowfield terminated the contract. The system never went live.

Thornbury's board wants to know whether it was the client, the team, or the way the programme was run. Four people can tell you: the project manager, the client director who sold the work, the technical lead, and the client's own operations project manager. Each of them is right about something. Each of them is hiding something else.

There are five real root causes and three plausible-sounding decoys. Getting all five takes better questions than most people ask on their first run — which is the point.

A shorter one: Billboard

Billboard is the introductory case, and the one to start with if Phoenix looks like a lot: three witnesses, four root causes and a budget of 20 questions. A £340,000 launch campaign for an energy drink goes live on the opening day of a trade show. The strapline reads two ways, the Advertising Standards Authority logs complaints inside forty-eight hours, two supermarket chains suspend their orders, and the campaign is pulled after five days.

It is the shortest case here and the least forgiving of a lazy conclusion. Everyone in the room has a tidy story about whose fault it was — the agency's, the client's, the internet's — and all three stories are true enough to stop an investigation early. There are four separate failures, two on each side of the contract, and none of them is the one the witnesses want to talk about.

Play Billboard in the browser — three witnesses, twenty questions, about fifteen minutes. Published as a case file too: scenario 03 — Billboard (it contains the full solution, so play it before you read it).

A harder one: Bridge

Phoenix is a company-sized failure. Bridge is an institutional one, and it is the harder case by some distance: five witnesses, six root causes and a budget of 30 questions. A large English council replaces a twenty-year-old finance system under the principle "adopt, don't adapt". Four years later the £20m business case has become a forecast £146m, the council has issued a Section 114 notice, and the system is being implemented a second time.

What makes Bridge worth playing after Phoenix is that there is no villain in it. Nobody lied, nobody was incompetent, and no single decision looked like a catastrophe when it was taken. The failure is the shape the decisions made together — which is why the case has a mechanic of its own: from question 15 the witnesses start reaching for "we had already spent too much to stop", and the game will not tell you what is wrong with that sentence.

Play Bridge in the browser — five witnesses, thirty questions. It is also published as a case file you can run on your own model: scenario 07 — Bridge (it contains the full solution, so play it before you read it).

All three cases are fiction — the council, the supplier, the agency, the brands and every person in them are invented. The shape of the Bridge problem is drawn from publicly documented experience of large UK ERP implementations.

The leaderboard

Saving a score is optional. It asks for a nickname and an e-mail address, confirmed by a one-time code — the code exists only to stop somebody entering scores under your name.

Once the code is confirmed, the address itself is not stored. What stays in the database is an irreversible hash of it, used to recognise a repeat entry, and a mask shown publicly: the first three and last three characters, the rest replaced by "#". Both language editions share one board behind the scenes; what you see in-game is scoped to the case you just played, not mixed with every other entry.

To remove your entry, write to hello@attv.uk from the address you used. There is nothing else to delete.

Questions people ask

Do I need an API key to play?

No. The game runs on a model paid for by attv.uk, so there is nothing to install, no account to create and no key to paste. A daily allowance applies; if you reach it, the game says so and asks you to come back later. The single-file build in the repository is the bring-your-own-key option.

Is this a test, or a game?

Both, deliberately. You have 25 questions and four witnesses who each hold part of the truth. At the end you write a post-mortem report and the model marks it against a hidden rubric out of 100 — including what you missed and which question would have unlocked it.

What is root cause analysis?

It is the practice of tracing a failure past its most visible cause to the system fault that allowed it. The classic technique is the "five whys": you keep asking why until the answer stops naming a person and starts naming a process.

Can I run this with my own team?

Yes. The full case is published as a single text file you can paste into any chat model. Those files contain the hidden solution, so read them after you play, not before.

Is any of it real?

No. Every company, person and figure is invented. The failure patterns are not — unpriced pre-sales promises, verbal scope changes, watermelon status reporting and a sponsor change mid-programme are the ordinary way projects die.