Last Updated on February 24, 2026 by Shrestha Dash
Birmingham City Council’s Oracle ERP saga has become one of the most extensively documented ERP reimplementation failure risk in UK public sector history. The original Oracle implementation, which triggered financial chaos when it went live, forced the council to pursue a full-scale reimplementation. Yet the latest findings from a January 2026 audit committee meeting reveal the same structural problems that caused the first failure are still present in the second attempt.
What started as a £19 million Phase 1 investment has now ballooned to a total forecast programme cost of £144 million through 2027/28. The go-live window has shifted from July 2026 to potentially September 2026. And external auditors from Grant Thornton have formally identified insufficient data quality, limited resources, and governance under pressure as live risks threatening the entire programme. This blog breaks down exactly what is going wrong at Birmingham, why these are not Birmingham-specific problems, and what any organisation currently running or planning an ERP reimplementation should take from this as a direct checklist.
The Birmingham Timeline: A Cost Escalation Nobody Can Ignore
To understand the stakes, you need to understand the journey.
- Original Phase 1 budget: £19 million
- Total programme cost forecast through 2027/28: £144 million
- Target go-live: July 2026, potentially slipping to September 2026
- Probability of programme abandonment (auditor estimate): 5%, which Grant Thornton cautioned should not be treated as insignificant
- Direct staff on the reimplementation programme: Over 100 full-time employees
- Status of those staff: Many removed from substantive roles, with agency staff covering their day jobs
That cost trajectory — from £19 million to £144 million, is not the result of a single catastrophic decision. This cost reflects compounding ERP reimplementation failure risks that teams could often foresee and prevent. Each phase created new dependencies, new technical debt, and new organisational fatigue that made the next phase harder to execute cleanly. This is what unmanaged ERP risk looks like over time. Not an explosion. A slow, expensive escalation.
Risk #1: Insufficient Data Quality Governance
At the audit committee, Grant Thornton principal consultant Thomas Foster explicitly warned that the process for documenting data quality standards and ensuring data readiness for migration was not well-established, particularly for finance systems. This is a critical finding because it indicates the programme moved into implementation without one of the most fundamental pre-requisites of ERP migration being fully in place.
Why Finance Data Is the Highest-Stakes Dataset in Any ERP
Finance data is not just another data domain. It underpins every transaction, every report, every audit trail, and every compliance obligation the organisation has. When finance data quality standards are undefined going into migration, the consequences cascade across:
- Chart of accounts integrity — Legacy GL codes mapped incorrectly or inconsistently cause reporting failures from day one
- Supplier and vendor master data — Duplicates and outdated records create invoice processing errors, duplicate payments, and procurement chaos
- Budget and commitment data — Incomplete or misaligned budget structures mean the new system cannot replicate existing financial controls
- Open purchase orders and contracts — Migrating uncommitted or expired data creates phantom commitments that distort financial position
- Historical transaction records — Incomplete history breaks audit trails and prevents period-to-period comparisons
The Data Readiness Gate That Most Projects Skip
The single most common ERP reimplementation failure risk in data migration is treating data cleansing as a task rather than a gate. Here is what a genuine data readiness gate looks like — and what Birmingham’s audit suggests was missing:
- Documented data quality standards per domain, agreed between business owners and the programme team before any technical migration begins
- Formal data profiling of every legacy source system to identify duplicates, nulls, format inconsistencies, and orphaned records
- Data migration test cycles with defined pass/fail criteria — not just “we ran the migration, and it seemed fine”
- Business owner sign-off on data quality before each migration cycle, not just a technical sign-off from the programme team
- A data governance lead with authority to block go-live if data standards are not met
None of this is complicated in principle. All of it requires time, budget, and business commitment that programme timelines frequently crowd out. And when you treat data quality as a background activity rather than a programme gate, you migrate problems rather than solve them. Dirty data in a new system is just dirty data with a new interface.
ERP Selection Requirements Template
This resource provides the template that you need to capture the requirements of different functional areas, processes, and teams.
Risk #3: Governance Integrity Under Deadline Pressure
This is the finding from Grant Thornton that deserves the loudest alarm bell. This is the risk teams most often overlook amid schedule pressures. Foster explicitly urged the audit committee to maintain robust governance processes even when the programme is under pressure to meet deadlines. His reasoning was blunt: Teams risk undermining governance standards more than they risk the financial or reputational impact of further schedule delays.
Read that again. The auditor is saying a delay is less risky than a governance failure. That is a striking position for an external auditor to take publicly.
What ERP Governance Failure Actually Looks Like in Practice
Governance failure in ERP reimplementation does not announce itself. It arrives through a series of small, reasonable-sounding accommodations:
- Change request approval becomes informal — teams risk undermining governance standards more than they risk the financial or reputational impact of further schedule delays
- Defect classification standards shift — issues that were P1 blockers three months ago are reclassified as P3 “post-go-live fixes” to protect the deadline
- Teams compress testing phases – cutting the integration test cycle from four weeks to two and deferring performance testing entirely.
- Teams close or downgrade risk register entries — they remove risks that haven’t materialised from the active log to present a cleaner status to leadership.
- Programme teams rush business readiness sign-offs — department heads approve readiness checklists they haven’t fully reviewed because the programme team needs the tick-box before the steering committee meeting.
In many ERP programmes, teams make governance appear compliant by gradually weakening standards to accommodate deadlines, a risk the current programme must actively guard against. It is the most dangerous form of ERP reimplementation failure risk precisely because it is invisible until the system goes live and the consequences arrive.
Macpherson noted that the team has set threshold criteria around defects to manage post-go-live expectations. This is the right instinct, but only if teams define those thresholds to reflect genuine quality standards rather than reverse-engineering them from deadline requirements.
ERP System Scorecard Matrix
This resource provides a framework for quantifying the ERP selection process and how to make heterogeneous solutions comparable.
Risk #4: Interpreting Change Management as Operational Monitoring
In response to direct questions about the change management programme, executive director Carol Culley referenced monitoring metrics. Such as, how many staff are raising purchase orders and how leave approvals are being processed. These are useful operational health indicators. They are not a change management programme.
What Change Management for an ERP Reimplementation Actually Requires
Change management is one of the most consistently underfunded and underdelivered workstreams in large ERP programmes, and it is consistently cited as one of the top three reasons ERP implementations fail to deliver expected outcomes, even when the system itself works technically. Here is what a comprehensive programme looks like:
Stakeholder impact assessment by role, not by department
The impact of a new Oracle ERP system on a purchase ledger clerk is fundamentally different from its impact on a budget holder, a category manager, or a payroll processor. Generic “change communications” do not serve any of these groups adequately. Each role requires a specific assessment of what changes, what they lose from the current system, what they gain, and what the transition process looks like for their specific workflows.
Role-specific training that maps to real job functions
System training that walks users through screens and menus is not enough. Effective ERP change management includes process-based training that shows users how their existing job tasks translate into new system workflows, including the edge cases and exceptions that make up 40% of daily activity but are never in the training materials.
Business champions embedded in each service area
Champions are not system superusers. They are trusted colleagues within each business area who receive deeper training, act as the first line of support for their peers, and provide feedback to the programme team about adoption issues in real time. Without champions, problems are either not reported or are reported too late to resolve before they compound.
Communication that explains the why, not just the what
Staff who understand why the ERP reimplementation is happening, what went wrong with the original system, why this matters for the council’s financial resilience, and what success looks like, are more likely to invest in learning the new system and less likely to develop workarounds that recreate the complexity the new system was meant to eliminate.
Post-go-live adoption monitoring with corrective response
Monitoring PO volumes and leave approvals tells you whether the system is being used. It does not tell you whether it is being used correctly, whether users have found workarounds, or whether there are latent defects in the process design that will only surface at period-end. Genuine adoption monitoring requires process compliance metrics, exception rate tracking, and structured feedback channels from front-line users.
What Birmingham Should Have Structured Differently
The Birmingham situation is not a failure of intelligence or intent. It is a failure of structure, and specifically, a failure to enforce the discipline that ERP reimplementation requires against the constant pressure to move faster and spend less.
Before the reimplementation began:
- In programmes of this scale, a full data audit of every legacy source system is typically treated as a mandatory pre-condition rather than an assumption
- Data quality standards for each migration domain should have been formally documented and agreed before any technical build commenced
- An independent readiness assessment should have been commissioned before go-live on the original implementation, and before go-live on the reimplementation
During the reimplementation:
- Resource planning should have included a post-go-live capacity model as a formal deliverable, not an afterthought
- Governance standards should have been fixed at programme charter level, with explicit provisions preventing compression under deadline pressure
- Change management should have been a standalone workstream with its own budget, dedicated lead, and reporting line to the programme board, not a sub-component of communications
At every stage:
- The dependency between data quality readiness and go-live authorisation should have been enforceable, not advisory
- Business owners should have had formal sign-off authority over readiness, and formal authority to block go-live if their domain was not ready
- External challenge is most effective when it is continuous rather than periodic, particularly on programmes of this duration and complexity
The 5% Abandonment Risk Is Not the Number to Watch
Councillors focused on the probability of abandonment. Foster described 5% as a low estimate. But abandonment is actually not the primary ERP reimplementation failure risk here. The bigger risk is a go-live that happens on schedule with inadequate data quality, under-resourced post-go-live support, and users who are not genuinely prepared for the new system. That is precisely what happened with the original Oracle implementation. And the cost of recovering from that, not abandonment, but a bad go-live, is what has driven the total programme cost to £144 million and counting.
A delayed go-live with properly cleansed data, a well-resourced support model, and staff who genuinely understand the new system is worth far more than an on-time go-live that creates the conditions for a third cycle of remediation. Birmingham has already learned that lesson once. The question is whether the current programme structure is designed to ensure it is not learned again.
Conclusion
Every one of the risks Grant Thornton has flagged — data quality, resourcing, governance integrity, and change management, was identifiable before this programme began. They are not surprises. These predictable failure modes recur in large-scale ERP reimplementations, and internal teams under deadline and budget pressure are least equipped to challenge them.
This is the core argument for engaging independent ERP advisors before implementation begins, not when the audit committee starts asking difficult questions. Independent advisors bring the pattern recognition of organisations that have navigated these exact failure modes across multiple programmes, the credibility to challenge governance compromises that internal teams cannot, and the benchmarking capability to ground resource and readiness decisions in what actually works rather than what the vendor or system integrator is proposing.
If your organisation is currently planning an ERP implementation or is mid-programme and recognises any of the patterns described in this blog, the team at ElevatIQ provides independent advisory support across ERP selection, implementation governance, data readiness, and programme recovery, at exactly the inflection points where external challenge makes the most difference.
This analysis combines publicly reported facts with independent interpretation based on common ERP reimplementation failure risk patterns observed across multiple large-scale programmes.
ERP Selection: The Ultimate Guide
This is an in-depth guide with over 80 pages and covers every topic as it pertains to ERP selection in sufficient detail to help you make an informed decision.
FAQs
Related Posts:
