Transformation doesn't fail because of technology

The myth: blame the technology

Technology is often the most visible part of a programme and the easiest to point at. A system that goes down or produces the wrong numbers is concrete. A steering committee that approved a go-live it didn't fully understand is not. So boards and executive committees tend to diagnose failure at the level they can see: the vendor underdelivered, the platform wasn't ready, the timeline was unrealistic.

Those explanations are sometimes true. Even then, they often don't explain why the problem wasn't caught, escalated or acted on in time. That takes different questions: who owned this decision, what did they know when they made it, and who had the authority to stop it?

Monzo: growth outran governance

Monzo isn't a failed technology transformation, and the FCA didn't assess it as one. That's what makes it useful: it is a technology-led bank that built its own platform. According to the FCA's Final Notice, its customer base rose from about 590,000 in February 2018 to 5.8 million in February 2022. The case shows that a technologically capable organisation can still fail to build the governance, accountability, specialist capacity and controls its growth requires.

On 7 July 2025 the FCA fined Monzo £21,091,300. The penalty covered failings in its financial crime controls between October 2018 and August 2020, and repeated breaches of a voluntary requirement (VREQ)[1] that, from August 2020, barred it from opening accounts for high-risk customers. Without the 30% settlement discount, the fine would have been £30,130,475.

The Final Notice records the cause as Monzo reported it. Monzo told the FCA that the law firm it had engaged to review the breaches had concluded that the overarching root cause was an "insufficiently robust governance framework to manage the implementation and operation of the VREQ." That is the law firm's conclusion as recorded by the FCA, not a separate FCA finding. The notice's next paragraph adds: "it was unclear at times who within Monzo was accountable for different aspects of the VREQ's implementation. Certain key employees were not aware of the VREQ including its regulatory significance and limited specialist staff had been available to work on implementing the VREQ controls."

Monzo's MLRO[2] left in October 2018, and the responsibilities were held on an interim basis by other senior staff until April 2020. The notice also describes an onboarding approach designed to keep friction to a minimum, and records that Monzo had promoted its lack of address verification on its website and online channels.

Read as a transformation story, this is a firm whose growth outran its control framework. The engineering capability to build better onboarding controls plainly existed. What was missing, on the account in the notice, was clear accountability, enough specialist capacity and a governance framework strong enough to make a regulatory commitment hold. That growth and control were competing objectives, and that for a period growth won, is our inference from the notice rather than a finding in it.

Birmingham: known risks, green status reports and a go-live anyway

Birmingham City Council's replacement of its SAP finance and HR system is a public-sector case, but it translates directly to any bank, insurer or Private Equity-backed business replacing a core finance platform. The mechanics of a finance-system cutover are broadly similar across sectors.

The council went live on Oracle Fusion in April 2022. By January 2026 the programme's forecast total cost to 2027/28 had reached £144.4 million, compared with an original estimate of about £19 million, as reported by The Register.

In February 2025 the council's external auditor issued a public interest report under the Local Audit and Accountability Act 2014. As reported by Computing, it found that "the decision to Go Live was taken with areas of risk (which were known to the programme) not being adequately mitigated." The programme had also reversed its original plan: instead of adopting Oracle's standard functionality, it customised the system to fit existing council processes.

According to Local Government Lawyer's coverage, the report found that "Members, for the most part, did not appreciate the complexity and level of risk in the programme", that reporting set risks out "in the detail of reporting" rather than in the key messages, and that "the culture of the Council at that time appears to be one where either bad news was not welcome, or officers felt uncomfortable to communicate bad news." The Register reported that cash management had been rated green in reports to the steering committee despite unresolved issues.

The council then rebuilt the programme with Oracle Fusion still as the core platform, this time using standard processes and third-party income management software in place of the original bank reconciliation component, and in January 2026 postponed the planned April relaunch to give staff more time to adapt. The new system went live in August 2026. An external auditor's report covered by The Register on 24 September 2026 said there were no outstanding business-critical or priority 1 or 2 issues on the new system.

It's too early to call the relaunch a success, and one go-live can't prove what made the difference. The auditor still expects to be unable to give an opinion on the council's accounts for several years, a legacy of the original failure. But the evidence so far is consistent with the argument. The core platform remained Oracle Fusion. What changed was how it was implemented, governed and prepared for. Transformation is a socio-technical problem, where technology, process, people and governance interact, and Birmingham's second attempt changed more than the software.

Seven organisational failure modes

Across these two cases, seven organisational failure modes stand out. They aren't a substitute for technical diagnosis. They're the conditions that determine whether technical and operational problems are identified, escalated and acted on.

•    Unclear ownership. Nobody is accountable for the whole outcome, or accountability is split so finely that nobody holds it. Monzo's Final Notice records this in almost those words.

•    Competing incentives. The programme's goal conflicts with a target someone is paid to hit, whether growth, cost or a date.

•    Poor decision-making. Decisions are taken on incomplete information, or not taken at all. Going live with known, unmitigated risks, as Birmingham's auditor described, is a clear example.

•    Weak sponsorship. Sponsors approve the business case but don't stay engaged, or change too often to hold anyone to account. High turnover in senior roles was one of the weaknesses reported at Birmingham.

•    Bad sequencing. Controls, clean data, testing or user readiness are scheduled after the point where they're needed.

•    Resistance. The people who'll use the new system aren't engaged early enough to shape it or trust it.

•    Weak governance. Steering forums receive green status reports and can't, or don't, look behind them.

What I've learned

In the integrations, carve-outs and transformation programmes I've been involved in, one pattern stands out, and Birmingham's go-live decision appears to fit it. Once a go-live date is announced, it becomes the one decision everyone is willing to defend, and every other decision gets bent to fit it. When a date carries political or organisational commitment, evidence about readiness becomes something the programme is expected to explain away rather than something that can change the decision. The people closest to the work often know where the gaps are. What's missing is someone with the authority, and the standing, to say the date should move. That's a decision problem before it's a technical one, and it's where Aulay's method starts.

The method: complexity, decisions, execution

Aulay's method for addressing these failure modes has three steps.

Complexity: name what you're actually dealing with. Programmes tend to describe scope in systems and modules. The harder complexity is often organisational, regulatory, process and delivery complexity: how many processes will change, who loses control of what, which regulatory commitments are in play and which targets pull against the programme. Monzo's VREQ was a regulatory commitment that, on the notice's account, lacked clear ownership. Birmingham's members, by the auditor's account, did not appreciate the complexity and risk they were overseeing. The output of this step is a short, honest list of what's hard, with a named owner for each important risk.

Decisions: make them early, and make them stick. Every programme has a handful of decisions that shape everything else: adopt standard processes or adapt the software, big-bang or phased, what gets stopped to fund the change, and the go-live criteria. For each, be clear who can decide, what evidence they need and what would cause the decision to be reversed. Go-live criteria in particular should be agreed before a date is announced, not negotiated in the final weeks. A steering committee that can't say what would make it stop a go-live isn't governing the programme.

Execution: sequence and govern the delivery. Sequence to actual readiness, not to the calendar: controls before growth, clean data and tested processes before cutover, trained users before switch-on. Report readiness as evidence, such as test results, open defects, control testing and user adoption, rather than as a colour. And build governance that surfaces bad news early and protects the person who raises it.

What should a CEO do on Monday morning?

•    Ask for the name of the one person accountable for each of the programme's five biggest decisions. If the answer is a committee, accountability is probably still unclear.

•    Ask what evidence would stop the next go-live, and who has the authority to call it.

•    List the business targets that conflict with the programme and decide explicitly which one wins.

•    Ask the programme team for the technical or operational problem they haven't escalated yet. How the room reacts to the question tells you as much as the answer.

Aulay's point of view

Technology matters, and technical problems need technical fixes. But buying better technology, changing vendors or blaming the platform doesn't by itself solve a transformation problem. The leadership work is to understand the complexity, make the critical decisions, establish clear accountability and govern execution against evidence. That's the work Aulay does, in the space between an approved business case and a result.

If you're a CEO, COO, transformation lead or Private Equity operating partner with a programme that's approved, funded and still not landing, get in touch through aulayco.com.

---

[1]VREQ: voluntary requirement, a restriction a firm agrees with the FCA to place on its own business. Monzo's, from August 2020, stopped it opening accounts for high-risk customers.

[2]MLRO: money laundering reporting officer, the senior individual accountable for a firm's anti-money laundering reporting.