Blog

Why good ideas in government struggle to scale

Government

Product & Delivery

View more blogs

In this blog, Opencast Director of Architecture & Engineering David Sarginson shares a summary of his talk at Global Government Forum Innovation 2026, explaining why innovation in government so often stalls and what sets apart the teams that successfully turn ideas into real public impact.

I'm David Sarginson, Director of Architecture and Engineering at Opencast, a technology consultancy that works extensively with UK government across HMRC, DWP, NHS England and the Ministry of Justice, to name a few.

I've been helping UK government departments create impactful software for the last 20 or so years. In that time, I've been a software engineer, an architect, and in some cases just a shoulder to cry on.

After more than two decades delivering in this space, I want to share honestly what we've learned about why the gap exists between good ideas and real delivery, and what actually closes it.

Naming the problem

From what I’ve seen, the UK government is genuinely good at innovation. We’ve built things the rest of the world studies. The NHS App. GOV.UK. And regardless of its political history, Universal Credit, which is a digital feat at extraordinary scale. GDS, when it launched, was a model that governments from Australia to Canada to Singapore came here to learn more about.

And yet, in January 2025, the Cabinet Office released their State of Digital Government report which showed that citizen satisfaction with UK public digital services had fallen from 79% to 68% over the past decade.

More pilots are running today than at any point in the history of digital government. Yet, fewer of them are impacting the people they were designed to serve. That gap, between the clever prototype and the live service that changes someone's life, is what I want to talk to you about today.

When I say proof of concept (PoC) or pilot here, I’m including citizen facing digital services, not just smaller internal solutions, as I believe we should always treat new services as PoCs until we have proven there is a citizen need and that we have solved their whole problem as per the GDS service standards.

A presenter stands at a podium in a conference booth area, speaking to a small seated audience. A large screen beside him displays a slide about his decade of work in the public sector. Audience members wear green‑lit wireless headsets, and the venue’s high industrial ceiling is visible above the white partition walls.

Crossing the gap — What actually works

In our experience, the teams that successfully scale a proof of concept to real public impact share three behaviours. And notably, none of them are technical.

Behaviour 1: They triage ruthlessly before they build

Not every proof of concept deserves to become a service. That sounds obvious, but it isn't practised nearly enough. The most effective teams we work with apply the following questions early on, before significant investment, before the sprint team is assembled, often before a line of code is written.

• Are we solving a problem that exists at scale? Not a problem that one or two vocal individuals or teams have, but a problem that touches real volumes of citizens or caseworkers in a way that a service improvement would meaningfully change.

• Is there an owner in the operational business who will be accountable for this after we leave? Not the innovation team. Not the digital directorate. Someone in the department who will be measured on the outcome in two years' time. If that person doesn't exist, or can't be identified, the PoC will not scale.

• Can we measure success in terms a minister, CTO or senior leader could defend? Not 'we shipped on time'. Not 'the team velocity was good’. Something like: claimants now receive their first payment four days earlier. Or, caseworkers spend forty percent less time on manual data entry.

If you can't articulate that before you start, you're building without a destination.

Behaviour 2: They scope for the operating environment, not the ideal state

The prototype was built in a controlled test environment with clean data and engaged stakeholders. By a dedicated team with the freedom to move fast.

Meanwhile, the service will live in a complex environment alongside legacy systems that predate the people running them, staff who didn't design the thing and weren't consulted about it, alongside a support model that doesn't exist yet and a procurement cycle that nobody factored in.

Scoping for scalability means designing for that reality from week one. Not as a phase two and not as a future consideration. Asking what are the production requirements? Who operates this in three years? What happens when the original team moves on?

We've learned, sometimes the hard way, to ask those questions at the start of an engagement rather than at the end of it.

Behaviour 3: They keep citizen outcomes visible throughout

The teams that scale are the ones where the citizen outcome stays visible on the wall, in the sprint review, in the board update, and throughout the entire delivery, not just at the business case stage.

It sounds simple, but it's surprisingly easy to lose. When you’re two months into a complex delivery and you’re neck deep in API contracts, complex Boolean logic and data migration scripts, the original 'why' can quietly disappear from the conversation.

The discipline of keeping that citizen impact statement front and centre is one of the most practical things a delivery team can do to protect against building something that technically works but doesn't actually matter.

Why the complexity of Government makes this harder

I want to be honest about the structural realities that sit behind those behaviours. Because the reason they're hard to sustain isn't because digital teams lack capability or commitment. It's because the system around them is not designed for scaling innovation. And we, as partners, are part of that system.

Structural reality 1: Procurement discontinuity

Even when a proof of concept succeeds, procurement rules often require a full retender before the work can continue. The team that understood the problem, built the relationships, earned the trust, and knows where the complexity is buried gets broken up at the exact moment of maximum risk.

Despite handover/takeover and hundreds of confluence pages, institutional memory walks right out the door when it is most needed. The new partners start again and the timeline slips. The amazing momentum built through the pilot evaporates.

I want to be careful not to sound self-interested here, because there are legitimate reasons competitive procurement rules exist. But I think we must be honest that in the context of scaling innovation, the current rules create a structural discontinuity that is genuinely costly. And responsible suppliers should be naming that problem with their clients at the start of an engagement, not discovering it together at the end.

Structural reality 2: Ownership ambiguity

This is the one point I'd ask you to take away from this piece if you take nothing else.

Who owns the thing after the PoC?

In my experience, that question makes people uncomfortable at the start of a project, because the honest answer is often 'we haven't decided yet'. The innovation team is moving on. The digital directorate is focused on the next pilot. The operational teams didn't design it and don't feel accountable for it. The partner’s contract has come to an end.

The ownership gap is where most pilots fall into. And the single biggest predictor of whether a PoC scales is whether there is a named, accountable senior responsible owner in the operational business, not in the innovation team, before build starts.

Not at go-live. Before build starts.

Structural reality 3: Budget discontinuity

We’ve seen innovation funded from one pot, scaling from another. And the two systems operate on completely different cycles, governed by different people, with different success metrics.

A proof of concept can find money in a digital transformation fund, a departmental innovation budget, or a spend control exception. That money moves relatively quickly. It's designed to be spent on new things.

Getting that same capability into business as usual (BAU) requires a spending review allocation. That means a business case that competes with every other priority in the department. A timeline measured in financial years, not sprints. Approval from people who were not in the room when the prototype was built and may have no context for what it does.

In our experience, if you do not identify the path to BAU funding before the PoC starts, you are almost certainly building something that will die. Not because it failed but because nobody planned for it to succeed.

The honest partner reflection

I've described three structural problems present when delivering in the complexity of government. I want to finish by acknowledging that we as partners are part of this too.

We are incentivised for new starts. We celebrate the prototype demo. We put the pilot in the award submission. We staff up for the PoC and quietly move those people on when the contract ends. If we're genuinely serious about public impact, and I believe we should be, we need to measure ourselves differently.

That means designing for scalability from day one, not as a phase two promise. It means measuring success by the citizen outcome, not the delivery milestone. And it means being willing to say, before a PoC starts, when the conditions for scaling simply don't exist. Even when that's uncomfortable.

Opencast has a values-led model. We hold B Corp status. That means something in practice, not just in our marketing material. It means we think it is our job to have these conversations with our clients, not to wait until the painful retrospective.

Audience members sit in rows of chairs at a conference session, all wearing green‑lit wireless headsets. Most attendees are looking down at their phones or listening quietly. The space is set within white partition walls, with a high industrial ceiling visible above.

Conclusion

The journey from proof of concept to public impact is not a technical journey.

It is a relational, structural and commercial journey. It requires governments and partners to make different agreements than the ones that currently exist and are encouraged.

Innovation in government is real. The ambition genuine and the capability exists. What is missing, far too often, is the design of conditions in which that innovation is allowed to matter.

That is not a technology problem. It is a choice. And it is a choice that we are positioned to make.