Good Enough for Now

Morgan comes on shift at 11pm and the menu is gone. Not crashed — gone. The update that rolled out at 6pm moved it somewhere else, and the section of iOPS that handles electronic file transfer to the Crown Prosecution Service is no longer where it was yesterday. There is a person in the custody suite waiting to be processed. Morgan has a legal time limit. Morgan picks up the paper form.

This is Greater Manchester Police in July 2019. iOPS — the Integrated Operational Policing System — went live sixteen months behind schedule. The custody module, which was supposed to manage custody records and transfer files electronically to the CPS, was not working as specified. The announcement had said it was ready. The go-live had happened. Nobody said out loud that it wasn’t done.

It wasn’t done.

Deployed, not delivered

The workaround that custody sergeants had been using for three months no longer worked. The update had changed the interface without adequate retraining. There was no mechanism to refuse the tool — the option was to make it work, improvise a new workaround, or escalate a complaint that had no clear landing point. Officers improvised.

GMP’s own independent review named the consequences: technical shortcomings, inadequate training, and operational disruption that left vulnerable people without referrals to support services. Referrals for high-risk domestic abuse victims fell by 50%. Referrals to Greater Manchester Victims’ Services fell by 87%. Officers spent time running duplicate paper processes alongside the digital system that was supposed to replace them. The system did not help the workforce do the work — it created a second job beside it.

iOPS had gone live not because it was ready but because the organisation needed it to have gone live. Sixteen months of delay had a contractual cost, a political cost, and a considerable cost in credibility. Ready was redefined as deployed, and the workforce inherited the gap between the two.

Why no one says it isn’t ready

A software product that is finished cannot justify an ongoing roadmap. It cannot retain an engineering team. In a subscription market, completion is a liability — a done product is one that doesn’t need what comes in the next release cycle. Agile methodology and continuous deployment gave the industry a vocabulary for this: not unfinished, but iterating. Not incomplete, but evolving. The language made incompleteness sound like a sign of rigour.

Organisations accepted this because the alternative was more expensive. To say the system was not ready meant saying the procurement decision was wrong. GMP’s contract had already been signed, extended, and renegotiated. Admitting the custody module was unfit meant unpicking an obligation that was difficult to unpick. Deploying and adapting was easier.

There was no real mechanism to refuse. The tool was the tool. The workarounds became part of the job. The cost was absorbed shift by shift by custody sergeants who had no power to put it back where it came from.

The cost that didn’t appear in the contract

Birmingham City Council signed a contract for an Oracle ERP system projected at £19 million. By 2026 the total cost is forecast to reach £216.5 million. Two and a half years after go-live, the system was still not, in the auditors’ own words, safe and compliant. In September 2023 Birmingham declared bankruptcy — the largest local authority insolvency in UK history. The system was never ready either.

NHS IT outages disrupted more than 274,000 patient interactions across six major trusts in a single year. In each of those incidents, clinical staff reverted to paper. Not because paper was preferred, but because the digital system had failed and the paper process was the only thing keeping the work going. More than a quarter of UK central government digital systems are now classified as outdated, at an estimated cost to the public sector of £45 billion annually in foregone productivity.

Office workers endure an average of 3.6 technology interruptions a month — software updates, system failures, workarounds required. Nobody counted this cost when the contracts were agreed, because the cost landed on the worker. The vendor’s contract was satisfied. The product had been delivered. That it didn’t work as specified was the next problem, billable separately.

What it was designed for

The most basic test for any system deployed to workers is whether it actually helps them do the specific work it replaced. iOPS failed that test on the night the update moved the workflow officers had learned. The tool stopped being a tool and became an obstacle with extra steps. The work still needed doing. Staff found a way to do it. The system got the credit for a deployment that happened.

The next test is whether what the vendor calls an improvement actually improves anything for the person using it. iOPS received updates. Each notification used the word “improvement.” Custody sergeants had not requested the features those updates added. The gap between what the vendor was building and what the workforce needed is not a failure of communication. It is the expected result of a development roadmap driven by the vendor’s commercial cycle, not by the legal obligations of a sergeant at 11pm.

The final test is whether the system responds to the specific person in front of it, or expects the person to fit. iOPS updated on the vendor’s schedule. Its release windows did not account for shift patterns, operational hours, or the consequences of breaking a workaround mid-cycle. The specific circumstances of night-shift custody work — legal time limits, vulnerable people waiting — were not part of the specification for when an update went live. The system was not designed around the people using it. They were expected to fit.