Good Enough for Now
Why deploying always looks like delivering — until someone picks up the paper form
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.
My Opinion
I have been in enough procurement processes to know that the people who will actually use the system are rarely in the room when it is chosen. Requirements are gathered, but they are normally vetted by people who do not work with the system day to day — so what gets built reflects what the organisation said it needed, not what the work actually demands. Sometimes a system is deployed not because it is ready but to satisfy a contract: the way a UK train leaves a platform on time even when it isn’t. What is missing is oversight with teeth — people who have enough operational experience to know when something is wrong, and enough authority to stop it going live until it is right.
I’ve seen this done properly where in a hospital the IT Development team deployed a capability that clinical staff had been asking for. Then they got smart - they instigated a digital suggestions box for new features/services/products and the hospital staff embraced this as they got a voice on what was needed and important - not what the organisation thought it needed. The even smarter change was the IT Dev team wrapped this all with an agreed SLA for delivering selected capabilities and they stuck to it. What the users asked for they got when it was promised. The downside if it can be called one was the sheer volume of requests once staff saw it working.
Questions the contract never asked
The following questions are not academic. They are for anyone currently running a process that exists only because a system the organisation bought was never quite finished. The vendor moved on. The contract was satisfied. The workaround remained.
What workaround are you currently maintaining that exists only because a system your organisation bought was never quite finished?
If you had had to sign off on the cost of that workaround — in time, in error rate, in staff goodwill — when the contract was agreed, would the vendor still have won it?
When was the last time someone in your organisation said “this isn’t ready” and it made a difference?
What would it take to put “not ready yet” back into the vocabulary of public sector procurement?
The cost of perpetual beta is not paid by the organisations that sign the contracts or the vendors that provide them. It is paid by the person on the shift who picks up the paper form when the menu has moved again. That cost is real. It has just never appeared in a budget line.
Authors Note
Morgan is a fictional character. Their story is drawn from a combination of professional observation and personal proximity to real events. The experiences described are real. The person is not.
Sources & References
HMICFRS: Greater Manchester Police Integrated Operational Policing System Inspection, 2020. https://hmicfrs.justiceinspectorates.gov.uk/publications/greater-manchester-police-integrated-operational-policing-system-inspection/
Computer Weekly: “Police IT system failure creates significant backlogs”, 2020. https://www.computerweekly.com/news/252479783/Police-IT-system-failure-creates-significant-backlogs
Data Centre Dynamics: “Total cost of Birmingham City’s Oracle system failure to reach £216.5m by 2026”, 2024. https://www.datacenterdynamics.com/en/news/total-cost-of-birmingham-citys-oracle-system-failure-to-reach-2165m-by-2026-report/
The Register: “Birmingham City’s Oracle ERP system still not ‘legally safe’”, April 2024. https://www.theregister.com/2024/04/17/birmingham_city_councils_oracle_erp/
The Register: “Birmingham City Council goes under after Oracle disaster”, September 2023. https://www.theregister.com/2023/09/05/birmingham_city_council_oracle/
Security Brief UK: “NHS IT outages disrupt 274,620 patient interactions”. https://securitybrief.co.uk/story/nhs-it-outages-disrupt-274-620-patient-interactions
Tech Monitor / DSIT: “Legacy technology costs UK public sector £45bn annually”. https://www.techmonitor.ai/government-computing/legacy-technology-costs-uk-public-sector-45bn-annually/
Ivanti: 2025 Digital Employee Experience (DEX) Report, 2025. https://www.ivanti.com/company/press-releases/2025/tech-disruptions-cost-companies-millions-of-dollars-in-lost-productivity-annually-according-to-research-from-ivanti
You’re reading The Next Evolution by Neil Catton, articles that explore the human world and the intersection of technology, they try and ask difficult questions - not to scare - but to inform. If someone forwarded this to you, you can subscribe free at neilcatton.substack.com.
Neil Catton is the author of The Next Evolution, The Cognitive Crucible and The Shadow System - available on Amazon, and writes at the intersection of technology, ethics, and human purpose.