Catastrophic Birmingham City Council Oracle Fusion deployment went live despite numerous red flags

Council staff and suppliers damned by auditor’s report that reveals multiple failings over disastrous Oracle Fusion implementation

The cloud-based enterprise system was expected to cost less than £19 million. It has already cost £171 million and played a decisive role in pushing the council into bankruptcy.

Bankrupt Birmingham City Council went live on its new Oracle Fusion finance and pay system despite multiple red flags over the disastrous implementation. The failure of the cloud-based system, which had been expected to cost around £18.7 million, could now cost the Council as much as £200 million according to some estimates after all the rectifications have been completed.

Moreover, it won’t go into operation until 2026 at the earliest and, in the meantime, the Council is unable to produce reliable financial reports or even reliably account for income and spending, leaving the local authority exposed to fraud.

That’s according to the auditor’s report, published this week by Grant Thornton, which revealed a litany of failure and incompetence, not just at the Council, which lacked the in-house skills to manage and roll-out the software, but also by its contractors and advisors – Evosys, Socitm and Egress Group – who gave their approval to the Council to go-live, despite numerous red flags.

Indeed, the report lists failings throughout, from selection in 2019 to its disastrous go-live in 2022.

The auditors claim that the business case and programme governance were not adequately designed before the programme started. While attempts were made early on to revise and reconfigure the business case and programme after the work had started, “these were insufficient and contributed to delays and additional cost,” the report suggests.

End users were not engaged early on or effectively and, instead of adopting Oracle Fusion’s standard functionality, the organisation sought to adapt the software to the Council’s own existing processes – an oft-cited reason for the failure of ERP deployments.

The report reveals that on top of high staff turnover in both senior and operational roles, the organisation lacked “sufficient in-house skills, capacity and experience in key programme management roles” leaving it dependent on its contractors and suppliers.

Despite all this, the project’s leaders preferred to paint an optimistic picture of the roll-out with risks and issues not clearly communicated; rather, they were set out only in the detail of reporting, obfuscating the messages that needed to be comprehended at a higher level.

The suppliers, who ought to have had plenty of experience with such rollouts, also failed to raise warnings. “Senior officers and supplier staff with responsibility for the safe delivery of the programme faced potentially conflicting priorities to keep to budget, avoid further delay and protect individual and corporate reputations,” according to the auditors.

“This is likely to have contributed to the lack of transparent progress reporting and a reluctance to challenge.”

In addition to weaknesses in design, testing was also sub-optimal, further increasing the risks ahead of the decision to go live. At the same time, suppliers provided insufficient guidance. “As such, the decision to Go Live was taken with areas of risk (which were known to the programme) not being adequately mitigated,” adds the report.