How a Software Project Bankrupted a City

Edit: This piece originally led with the Oracle project as the primary cause of Birmingham’s Section 114 notice. Readers rightly pointed out that the equal pay liability was the larger financial exposure. I have updated the opening to reflect both causes more precisely. The core argument about decision infrastructure remains unchanged.

The Numbers

Birmingham City Council’s Section 114 notice in September 2023 had two causes. A £760 million equal pay liability, on top of £1.1 billion already paid following a 2012 Supreme Court ruling. And an Oracle ERP implementation that ballooned from £19 million to over £130 million, destroyed the council’s ability to produce budget reports for two years, and left it running two systems in parallel because neither worked properly alone.

The equal pay liability was the larger number. But the Oracle failure made both crises unmanageable. A council that cannot produce basic financial information cannot manage any liability, including equal pay. Of the £87 million in-year deficit cited in the Section 114 notice, £69 million related to Oracle savings that had to be written off.

A million residents now face 18% higher council tax. Services slashed. Assets sold. Two different failures, compounding over years, with no decision trail for either.

Oracle implementations succeed and fail in roughly equal measure. The software was not the failure. The decisions were. In both cases.

No One Can Trace How It Happened

The budget grew from £19M to £38M to £90M to £216M. At each stage, someone approved the increase. Someone weighed the options. Someone decided to continue rather than stop.

But there is no decision trail.

No record of which tradeoffs were considered. No documentation of why “continue” beat “cut losses” each time the project was reviewed in 2019, 2020, and 2021. No capture of the constraints, the alternatives, or the reasoning.

The auditors can count the money. They cannot trace the logic.

When Grant Thornton audited the council’s accounts, they identified the Oracle project as a material uncertainty. But the uncertainty was not about the technology. It was about the decisions. How did rational people, reviewing this project quarterly for five years, approve its continuation at every stage?

We do not know. We cannot know. The decisions were made but not recorded.

The Swiss Cheese Model

In aviation, single failures do not cause crashes anymore.

This was not always true. In the early decades of commercial flight, a single mechanical failure, a single human error, or a single environmental factor could bring down an aircraft. The industry responded with rigorous incident tracking, mandatory reporting, and fleet-wide fixes whenever a pattern emerged.

The result: modern accidents require multiple failures aligning. James Reason called this the Swiss cheese model. Each layer of defense has holes, but the holes are in different places. A catastrophe requires the holes to line up, the single failure to pass through layer after layer of safeguards.

Aviation built infrastructure to prevent that compounding. When you can trace each incident, you see the pattern before the fourth failure meets the fifth.

Birmingham had no such infrastructure for decisions.

How Decisions Compound

Each individual choice in the Oracle project might have been defensible.

The initial £19M budget might have been reasonable for the scope proposed. The first increase to £38M might have reflected legitimate scope changes. The decision to continue after the first delays might have been correct given sunk costs and switching costs.

But no one captured those decisions in a way that reveals the pattern.

A decision audit trail would show: Here is what we knew at the time. Here are the options we considered. Here is why we chose this path. Here is what would need to be true for this to be the wrong choice.

Without that trail, you cannot see when the holes are lining up. You cannot recognize that the fifth “reasonable” decision to continue is actually the moment when the accumulated risk becomes unrecoverable.

Birmingham’s leaders made a series of reasonable-seeming choices. Each approval was isolated from the others. No one could see the compounding.

The Infrastructure Problem

This is not a meeting problem. It is not a governance problem. It is an infrastructure problem.

Birmingham had governance. The project was reviewed regularly. Committees met. Reports were written. Approvals were documented.

But the infrastructure captured outcomes, not reasoning. The reports showed what happened, not why decisions were made. The governance recorded votes, not tradeoffs.

When a decision is captured only as “approved,” you lose everything useful:

• What alternatives were considered?
• What constraints shaped the choice?
• What assumptions would invalidate the decision?
• What signals should trigger reconsideration?

A £90M approval tells you money was committed. It does not tell you whether the committee understood they were choosing between “continue despite overruns” and “cut losses now” and “pause for independent review.” It does not tell you which option each member favored, or why the minority was overruled.

The decision happened. The reasoning evaporated.

Three Things Governance Fails to Capture

Decisions that matter require three things most governance processes fail to capture.

Explicit alternatives. Not just the recommended path, but the options that were rejected. Why was “stop the project” not chosen? Why was “bring in external expertise” rejected? The alternatives reveal the constraints that shaped the choice.

Documented assumptions. Every decision rests on assumptions about the future. The Oracle project assumed implementation complexity, staff capabilities, vendor performance, and dozens of other factors. Recording those assumptions creates triggers for reconsideration when assumptions prove wrong.

Reversibility criteria. Under what conditions should this decision be revisited? If the project exceeds £50M, does that trigger automatic escalation? If implementation extends beyond 18 months, does that require independent review? Reversibility criteria turn decisions into experiments rather than commitments.

Birmingham’s process captured none of this. So when the £50M threshold passed, no alarm sounded. When implementation extended year after year, no automatic review was triggered. Each continuation decision was treated as new, disconnected from the pattern of previous failures.

The Lesson

A million Birmingham residents pay the cost of decisions no one can examine.

The council tax increase is real. The service cuts are real. The sold assets will not return. But the decisions that led here remain invisible.

This is the difference between having a process and having infrastructure. Birmingham had a process. Regular meetings, documented approvals, formal governance. What it lacked was infrastructure that captured reasoning, made patterns visible, and created checkpoints before failures could compound.

Aviation learned this lesson through crashes. Enterprise software projects keep learning it through bankruptcies. The lesson is the same: single failures are survivable, but compounding failures are catastrophic.

Decision audit trails prevent the compounding. They make each choice traceable, each assumption visible, each reversal possible.

Without them, you count the money afterward. You cannot trace the reasoning.

And the next organization makes the same invisible choices.

I’m building ChainAlign to create the decision infrastructure that Birmingham lacked. If you’re interested in what decision audit trails look like in practice, see what we’re working on.

This is a case study in the Architecture of Dissent series on decision infrastructure.