# SCENARIO 07 — "BRIDGE" (a council ERP programme that went wrong) Difficulty: expert · 5 witnesses · 6 root causes · budget: 30 questions This scenario is fiction. The council, the supplier, the system, the detailed figures, the documents and every character are invented. The shape of the problem is drawn from publicly documented experience of large UK ERP implementations. ## BACKGROUND (known to the player) Westborough Metropolitan Council is one of the largest local authorities in England. In 2018 it decided to replace a finance and HR system more than twenty years old with a modern cloud ERP platform, Civitas One, delivered by Northstar Systems. The original business case: a budget of £20m, a timescale of 30 months, a scope covering Finance, Procurement, HR and Payroll, and one governing principle — "adopt, don't adapt": configure the system as standard and change the council's processes to fit it. The programme was to simplify processes, cut manual work and give leadership a single trustworthy source of financial data. The first go-live eventually happened in April 2022. Over the following months came problems reconciling accounts, difficulty establishing the true cash position, trouble with budget reporting, manual workarounds, delays closing the books, and thousands of hours spent on manual corrections. The cost of the programme climbed: £20m → £41m → £87m → a forecast £146m. The council then found itself in a much wider financial crisis and issued a Section 114 Notice. The ERP was not the sole cause of that crisis, but it badly damaged the organisation's ability to understand its own financial position and respond to problems. Four years later the council prepared what was in practice a second implementation, under the name Project Bridge. That new version has just gone live. Before the organisation closes the previous chapter, the Commissioners have commissioned an independent post-mortem. The player's task is not "who broke the system?". It is: why did the organisation allow a £20m project to become a programme of nearly £150m — and why, with the warning signs visible, was the first system switched on at all? ## THE HIDDEN TRUTH (never volunteer it) Six real root causes: 1. [CAUSE-ADOPT] **"Adopt, don't adapt" was abandoned — without anyone deciding to.** The programme formally began with the principle, but within months directors of individual departments began asking for the old system's processes to be rebuilt inside Civitas One. The Programme Director granted exceptions, arguing that "the organisation cannot survive changing the system and the processes at the same time". Eighteen months in, the programme had 173 non-standard user roles, 46 integrations, 118 approved solution changes, an elaborate custom purchasing workflow and a bespoke income reconciliation module. Not one formal decision was ever taken to abandon the principle — the strategy died through hundreds of small exceptions. The customisation raised the cost of development, testing and later support, and created dependencies the team could no longer test as a whole. 2. [CAUSE-GOLIVE] **Going live without evidence of readiness.** Six weeks before go-live the programme had 37 open High defects, four critical processes with no complete end-to-end test, unfinished reconciliation testing, an incomplete supplier data migration and unresolved problems in income management. The report to the Programme Steering Committee nevertheless showed AMBER/GREEN — "go-live achievable". Two weeks before the date, Internal Assurance issued a memo: "the council does not hold sufficient evidence to confirm the full financial readiness of the solution". The Programme Director judged that the risks could be handled "during hypercare". The real reason: extending the old system would have cost around £2.8m, required fresh procurement approval, and meant publicly admitting another delay. Locally, the rational decision was to go live and fix it afterwards. Systemically, it was catastrophic. 3. [CAUSE-CLIENT] **No intelligent-client capability.** The council had good IT people, but very few with experience of running a transformation of this class. In the critical areas the technical knowledge sat with the integrator. There was no strong, independent Design Authority able to say, consistently, "no — we are not building that". The same partner helped design the solution, estimated the complexity of changes, did part of the configuration and reported on progress. Formally the council decided; in practice the organisation did not always know enough to challenge the supplier's recommendation. 4. [CAUSE-TOM] **The system was designed before the target operating model existed.** The ERP and the transformation of how the organisation works were run as two separate programmes. The system was being designed before the council had agreed a Target Operating Model for Finance, Procurement and HR. The technology team kept asking "what is the future process?", the business kept answering "for now, do it the way we do it today" — and a system meant to transform the organisation began reproducing its history. The Target Operating Model was formally approved eight months after the main solution design was frozen. 5. [CAUSE-GOVERNANCE] **Governance that reported activity instead of readiness.** The Programme Board received plenty of information: workshops completed, processes configured, percentage of test cases executed, migration status, people trained. What it did not see clearly enough: which financial processes still did not work end to end, whether the council could reconcile its bank balance, whether an auditable balance sheet would be possible after migration, what proportion of critical tests had failed, and what the financial consequence of another delay would be. The programme looked 80–90% complete for the best part of a year. Senior leadership were shown a difficult but controlled project. 6. [CAUSE-SUNKCOST] **Funding by sunk cost — death by a thousand cuts.** There was no single moment at which the council approved "we are spending £146m instead of £20m". The cost accumulated in instalments: business case £20m → replan 1 (delay and heavier configuration) £41m → replan 2 (additional development, consultants, integrations) £63m → post-go-live stabilisation (hypercare, manual processes, experts, fixing income management) £87m → reimplementation, Project Bridge £131m → forecast programme lifecycle £146m. Each successive decision was justified by the previous spend: "we cannot stop now, we have already spent £X million". Nobody was ever formally obliged to ask again: "if we were spending the next £30m from scratch today, would we still choose this road?" **IMPORTANT — Section 114.** The Section 114 Notice was not caused by Civitas One alone. The council also had a structural budget deficit, rapidly rising social care costs, significant historic exposure to employment liabilities and insufficient structural savings. What the ERP did was amplify: it reduced the council's ability to monitor its budget credibly, reconcile data quickly, spot variances, produce auditable accounts and understand its real cash position. This is the trap in the scenario — a player who writes "the ERP drove the council into Section 114" has flattened the causation and should lose marks under "fact versus narrative". ## FALSE LEADS (narratives offered as "causes") - "The supplier sold us a faulty system." — The base product runs in many other organisations. The problem was how the council designed, modified, governed and launched it. - "The project was simply under-estimated." — The original business case was indeed optimistic, but that does not explain £20m becoming nearly £150m. Most of the escalation was generated by later decisions. - "Go-live could not have been delayed." — It could. It would have been expensive, politically hard and reputationally painful. That is not the same as impossible. - "The problem was customisation." — A half-truth. The real question is why an organisation that had formally adopted "adopt, don't adapt" kept approving customisation. - "It was an IT project." — No. The change touched finance, procurement, HR, payroll, governance and the way the whole organisation works. Treating it as a system replacement was part of the problem. ## THE WITNESSES ### 1. Helen Ward — Programme Director (Westborough Council) - Tone: calm, experienced, precise. Never says "mistake"; says "trade-off", "constraint", "programme reality". - Her narrative: "This was an extraordinarily complex transformation. Every decision had a good justification at the time." - Hides: the true state of the programme before go-live, and her own part in normalising each successive exception to "adopt, don't adapt". - Unlock conditions: she will not admit recommending go-live on incomplete assurance until the player asks who formally recommended launch, what go/no-go criteria existed, which of them were unmet, and what the alternative was and what it cost. - Partly right: the pressure was real, and each successive decision genuinely did look more reasonable locally than it does from the whole-system view. ### 2. Martin Shaw — Director of Finance - Tone: cool, numerical, defensive. - His narrative: "The technology made it impossible for Finance to do its job." - Hides: that Finance was one of the largest sources of customisation requests. The department refused to give up several historic processes, arguing that the standard workflow "does not meet the council's needs". - Volunteers unprompted: that the old system had been heavily customised over more than twenty years. - Unlock conditions: the question "which processes did Finance agree to change in order to fit Civitas One?". A request for the register of departures from the design principles puts him on the defensive. ### 3. Priya Nair — Enterprise Architect - Tone: technical, frustrated, specific. - Her narrative: "We tried to warn people. The programme was sunk by customisation." - Volunteers unprompted: that the Design Authority was repeatedly bypassed by decisions escalated straight to the Programme Director. - Hides: that she herself approved several large departures, because "if I had blocked everything, the business would have routed around architecture entirely". - Unlock conditions: questions about how many changes the Design Authority formally rejected, how many it approved conditionally, and who could overrule it. ### 4. Daniel Reed — programme partner (Northstar Systems) - Tone: highly professional, contractual. - His narrative: "We delivered the solution in line with the client's decisions." - Hides: that Northstar repeatedly flagged that customisation would raise cost and risk — while earning from the additional change requests, so it had no strong commercial incentive to say "stop ordering changes". - Unlock conditions: the player must ask how the contract was structured, who benefited financially from additional change requests, and whether Northstar carried any liability cap for architectural complexity. - Partly right: the council really did approve the changes. ### 5. Sarah Mills — Head of Internal Assurance - Tone: cautious, procedural. - Her narrative: "We identified the problems before launch." - Volunteers unprompted: the existence of the assurance memo issued two weeks before go-live. This is the key evidence against Helen's account. - Hides: that Internal Assurance was formally engaged very late. Sarah had known three months earlier that the programme carried significant risk, but her team did not force an earlier formal review. - Unlock conditions: "when did you first know there might be a problem?" followed by "and what did you do about it then?". ## CROSS-CONFRONTATIONS - **Sarah → Helen.** Sarah reveals the assurance memo. The player can ask Helen: "Two weeks before go-live, Internal Assurance wrote that there was not enough evidence of financial readiness. Who decided to launch anyway?" Helen can no longer answer in generalities. - **Priya → Martin.** Priya reveals the list of departures from "adopt, don't adapt". The player can confront Martin: "Finance raised 31 departures from the standard process. How does that sit with the claim that IT created the problem?" - **Daniel → Helen.** Daniel reveals that Northstar formally priced three options: standardise the process, customise, or delay. Helen chose customisation as the least politically painful. - **Martin → Helen.** Martin reveals that extending the old system was possible, letting the player dismantle the narrative that there was no alternative to going live. ## SUNK COST (this scenario's special mechanic) From question 15 onwards, some witnesses begin using the argument: "given what we had already spent, we could not pull out". Do NOT prompt the player that this is the sunk cost fallacy, and do not name the fallacy. If the player challenges the logic unprompted — asking, in effect, "if the earlier spend were already unrecoverable, was the next £30m still the best decision?" — unlock an additional document, **Investment Review — Month 26**. It shows that no further tranche of funding was ever assessed as a fresh investment decision: every business case was presented first and foremost as "the cost of completing the existing investment". ## DEBRIEF NOTES **The model answer.** The failure was not caused by one bug or one person. It was a system of mutually reinforcing decisions: no target operating model → historic processes retained → customisation → greater complexity → more changes and more testing → delay and rising cost → pressure not to move go-live → acceptance of a lower level of assurance → an immature system switched on → financial and operational problems → additional stabilisation cost → reimplementation. The central conclusion: £146m was not one bad decision. It was the result of several dozen locally rational ones, none of which looked like a catastrophe on its own. **This scenario's rubric (100 points).** - Systemic causes — 60 points, 10 each: (1) abandoning "adopt, don't adapt", (2) the go-live decision, (3) no intelligent-client capability and no effective Design Authority, (4) the ERP designed before the Target Operating Model, (5) governance reporting activity instead of readiness, (6) funding successive stages under sunk cost with no reset of the business case. - Fact versus narrative — 20 points. Full marks if the player rejects "blame the supplier", "blame the software", "delay was impossible", "the ERP caused Section 114" and "the budget was simply mis-estimated". - Recommendations — 20 points. Good ones include: an independent Design Authority with a real veto; a formal register of departures from the design principles; a Target Operating Model before ERP configuration; measurable go/no-go criteria; independent assurance before every key gate; reporting process readiness separately from test-execution counts; a mandatory business case re-baseline once cost thresholds are crossed; and a contract that limits the supplier's economic incentive to accept unbounded customisation. **The most likely player error:** "the programme failed because the system was customised too heavily". That is still too shallow. The right question is: why did an organisation that knew it wanted "adopt, don't adapt" build an environment in which every local decision pushed it towards "adapt"? That is the actual post-mortem.