Key Highlights
- Governments everywhere are spending heavily to escape ageing systems, but the harder problem lands after the new system is built: whether hundreds of thousands of public servants can use it.
- The scale is global. The US federal government spends more than $100 billion a year on IT, around 80 per cent of it simply operating and maintaining existing systems, some 8 to 51 years old (GAO). In the UK, the government’s own review found around a quarter of central systems outdated, with departments pushed to hire contractors for basic technical tasks (State of Digital Government Review).
- Adoption is harder in the public sector than almost anywhere: vast, diverse workforces, frontline and deskless staff, and a thin bench of digital specialists, since public-sector pay struggles to compete.
- And it is more exposed. A rollout that staff cannot use becomes a headline, an audit finding, and a value-for-money question, which makes readiness something you have to prove, not just hope for.
The same programme, defended in every capital
Picture a scene that repeats in capital cities everywhere. A senior official sits in front of a scrutiny body to account for a major system programme. The questions are about cost, timescale, and delivery confidence. Behind those headline concerns sits a quieter risk that rarely gets the same airtime, and it is the one most likely to decide the outcome: whether the tens of thousands of caseworkers, clinicians, clerks, and officers who will use the new system every day can do so without slowing the service to a crawl.
The pressure to modernise is real, and the numbers are strikingly similar across countries. In the United States, the federal government spends over $100 billion a year on IT, with roughly 80 per cent going just to operate and maintain existing systems, several of them decades old and still running languages like COBOL (GAO). In the UK, the government’s own State of Digital Government Review found that roughly a quarter of central systems are outdated, and that departments have been pushed to bring in contractors for basic technical work rather than full-time staff. Only a minority of the government’s major projects earn the top delivery-confidence rating from the Infrastructure and Projects Authority. Different flags, same story: the case for change is not in doubt. Whether the people on the receiving end can adopt what gets delivered is.
The debate is about technology; the risk is about people
Almost all of the public conversation about government modernisation is technical: ageing platforms, COBOL, cloud migration, interoperability. Those things matter. But a new system delivers nothing until people use it well, and that is where transformations consistently come undone. McKinsey’s research finds that large organisations capture only about a third of the value they expect from their digital transformations, and the recurring cause is not the technology but weak change management and adoption. Governments spend years and headlines getting a system built, then treat the human side as the part to trim when the budget tightens.
The pattern is the one every large organisation faces, only bigger and more public. The system goes live, and daily work does not move into it. Staff avoid the unfamiliar parts, revert to old habits and spreadsheets, and raise tickets for tasks that should be routine. The efficiency the programme promised arrives late, if at all, and the gap sits in operational budgets no one connects back to the rollout.
Why adoption is harder in the public sector
Three things make the public sector a harder place to land a new system than most, and they hold in nearly every country.
Scale and diversity come first. A government rollout can touch tens of thousands of people across agencies and regions, from desk-based analysts to frontline and deskless staff with very different levels of digital confidence. One-size training reaches none of them well.
Then there is the talent gap. Public-sector pay rarely competes with the private market for digital and data skills, so there is often no deep bench of internal specialists to build and maintain training. The UK’s State of Digital Government Review found departments leaning on contractors and consultants for basic technical tasks for want of in-house staff, and few public administrations anywhere keep a deep bench of digital specialists. The tooling therefore has to let non-technical staff do the work.
And there are the systems themselves. Governments run old and often bespoke applications that commercial training tools were never designed for. In the US, critical federal systems range from 8 to more than 50 years old (GAO). Any credible approach has to work on legacy and homegrown systems, not just a shiny new platform.
The scrutiny that raises the stakes
In the private sector, a botched rollout is an internal problem. In the public sector it is a public one. When staff cannot use a new system, the citizen-facing service degrades, and a visible failure becomes a headline and a finding by a national audit office. Public satisfaction with services is already fragile, and trust erodes further when a rollout degrades the service in front of citizens. The political instinct after a public failure is caution and delay, which is how the next modernisation gets pushed back.
That scrutiny changes what good looks like. It is not enough to run training and hope. You have to be able to show that people were ready, which turns readiness from a soft outcome into evidence you can put in front of an auditor.
Rolling out a major system across a public-sector workforce? Our Adoption Readiness Framework helps you assess how prepared your people are before go-live, not just whether the technology is ready.
What closes the gap
The way to protect a public-sector rollout is to treat adoption as core infrastructure, not a training box to tick. Two things carry most of the weight: rehearsal before go-live, and help inside the system afterwards.
Rehearsal comes first. Staff practise the actual tasks on an anonymised, editable clone of the system, making mistakes safely until the workflow is familiar. Because Assima captures applications at the object level, including any web-based or green-screen system without needing source code, this works on the legacy and bespoke platforms government runs, not only modern software. The authoring is no-code, so subject-matter experts can build and maintain the content without the scarce technical specialists a department may not have.
Two details matter especially here. Citizen data never has to be exposed: Assima replaces sensitive data with risk-free data before content is published, and for the most sensitive environments, screen analysis can run locally rather than sending screen data to a server, which keeps a rollout inside the data-sovereignty and security constraints public bodies work under. Once live, Assima Assist guides a user through a step at the point of need, and Assima In-App Search surfaces the department’s own instruction on the screen they are working in, so an unfamiliar task does not become a support call or a stalled case.
Plan International has already run this exact play. The children’s charity, working in more than 50 countries, replaced costly, hard-to-support legacy systems with SAP across 275 sites in 53 countries. Sending professional trainers to every country was out of the question, and many of its users, the people delivering services on the front line, were also the least confident with technology. Working with Assima, the charity built interactive lessons on clones of the live system, localised them into English, Spanish and French by extracting and re-inserting the on-screen text, and trained around 4,000 users through a cascade: managers learned at regional events, then trained local staff from the same lessons, so the content stayed consistent instead of drifting as it spread. It is a distributed, multilingual, public-benefit workforce that looks a great deal like a government’s.
The pattern repeats inside government itself. At Caisse des Dépôts, the French public-sector financial institution, training on the core account-holder systems makes up a third of all training, delivered to 1,100 agents spread across France. Its trainers are banking administrators rather than IT specialists, yet they built the e-learning for ten applications themselves, retired a costly training sandbox, and over three years cut maintenance costs while raising quality.
Prove readiness, because someone will ask
Login counts and course completions will not satisfy an auditor, and they should not satisfy you. They record attendance, not capability. A better measure is whether a caseworker, clinician, or officer can carry a real task through the new system from start to finish, unaided, before go-live. That answer tells you how the launch will go, and it doubles as the evidence a scrutiny committee will eventually ask for. Measuring capability is both good practice and good defence.
Conclusion
No government is short of reasons to modernise, or of money pointed at the technology. The part that decides whether that spending pays off is quieter and easier to cut: whether the workforce can use what gets built. In the public sector that adoption challenge is larger, harder, and more exposed than in any private enterprise, in every country that attempts it, which is exactly why it deserves to be planned as deliberately as the migration itself. Rehearse the real work before go-live, support people inside the system after, prove they are ready, and a modernisation stands a chance of delivering what was promised. Leave adoption to chance, and the new system joins the long list that worked in testing and failed in public.
See it on your own systems. Book a demo and we will show you how Assima turns your live
Frequently Asked Questions
Let’s Answer Some of Your Questions.
Rarely because of the technology alone. Large organisations capture only about a third of the value they expect from digital transformations, and the recurring cause is weak change management and adoption. In government the effect is amplified by scale, workforce diversity, and thin digital staffing, so the human side of a rollout is both harder and more often underfunded.
Because the workforce is larger and more varied, with many frontline and deskless staff of differing digital confidence; because public-sector pay struggles to recruit the digital specialists who would build training; and because the systems are often old or bespoke, from decades-old federal platforms to legacy departmental tools that many commercial training products cannot handle.
Directly. When staff cannot use a new system well, the services citizens rely on slow down or break, and trust in digital public services erodes. A rollout that staff struggle with becomes a public failure, not just an internal one.
Yes. Training can be built on an anonymised clone of the system, with sensitive data replaced by risk-free data before publishing. For the most sensitive environments, screen analysis can run locally rather than sending screen data to a server, keeping training within the data-sovereignty and security rules public bodies must follow.
By capability, not attendance. Test whether a caseworker or officer can complete a real task in the new system unaided before go-live, rather than counting logins and course completions. That measure predicts how the launch will go and provides the readiness evidence auditors and scrutiny committees will ask for.
