Escaping the ‘Innovation’ trap: setting up projects to deliver real impact

Every leader wants ‘innovation’, yet public sector projects routinely end up either pedestrian or bogged down in the delivery swamp. You can break that cycle, with a clearer definition of ‘innovation’, a sharper focus on the user, and smart use of constraints.

If you lead Product or sit as a Senior Responsible Owner (SRO) in the UK public sector, you’ve probably sat in a meeting recently where someone demanded ‘more innovation’. You may have even been the one demanding it: we all want innovation.

But a year into most projects, leaders often find themselves looking at one of two scenarios:

The Pedestrian Solution: A new web form sitting on top of the exact same broken, legacy back-end process. A lot of work, but no real efficiency gains.

The Delivery Swamp: An ambitious initiative completely bogged down in delivery, flagged ‘Amber/Red’ by the Infrastructure and Projects Authority (IPA), trapped in an endless cycle of assurance gates, 100-page risk logs, and scope creep.

It’s a familiar failure pattern. Year after year, the National Audit Office (NAO) and the Public Accounts Committee (PAC) publish reports echoing the same structural diagnosis: government digital programmes rarely fail due to a lack of technical ambition. They fail because of optimism bias, rigid procurement, heavy-handed governance, and losing sight of underlying user needs under the weight of burdensome feature requirements.

No matter how smart or motivated the team, there are three traps that they often fall into.

Trap 1: The ‘innovation’ banana skin

The first trap is that ‘innovation’ is a slippery word. We’re not sure what it is, we hope we know it when we see it.

When we demand innovation, we’re rarely clear about what we’re asking for. Do we want a slightly better web portal, or do we want to automate entire casework decisions using machine learning? Those two things require fundamentally different resources, mindsets, and governance structures.

To set up a project for innovation we need to be clear about what we mean. We can do that by asking: are we serving an existing need, with existing tech; or a new need with new tech?

1. Incremental Innovation:
   • What it is: Small improvements to something that already works.
     Examples: Digitising a paper process, reducing fields on a form, or improving content clarity.
   • Governance needed: Standard Agile delivery, standard GDS Service Standard checks.

2. Sustaining & Architectural Innovation:
   • What it is: Improvements that set the stage for future success.
   • Examples: Moving legacy databases to cloud infrastructure, breaking up monolithic supplier contracts, or adopting API-first architectures.
   • Governance needed: Requires technical patience and decoupling from immediate, flashy front-end ROI.

3. Disruptive Innovation:
   • What it is: Reframing an existing problem, and applying existing technology.
   • Examples: The early days of GOV.UK Notify—a simple, transformative way for the government to communicate, built on standard, existing tech.
   • Governance needed: Focus heavily on changing user behavior and policy operations, rather than tech build.

4. Radical Innovation:
   • What it is: Fundamental re-thinking of service delivery.
   • Examples: Think ‘using automated eligibility engines to eliminate the need for citizens to apply for benefits altogether’.
   • Governance needed: Requires “sandbox” rules, relaxed business case gates, and a genuine, institutional tolerance for early failure.

In other words, each type of innovation requires a different approach to risk and governance. 

In practice, government departments don’t make those choices. They routinely subject disruptive ideas to the most rigid Green Book governance that is designed for predictable infrastructure. Demanding detailed upfront certainty on scope and return crushes innovation and delivers pedestrian, low-risk solutions.

Trap 2: Focussing on ‘materials’ instead of outcomes

There’s a second reason government innovation goes off the rails: we confuse materials with outcomes.

Tech-driven innovation is notoriously hit-and-miss. Outcome-driven (User-Centered Design) innovation hits the target consistently.

Decades of delivery data back this up. The Standish Group’s global tracking of over 50,000 IT projects shows that nearly 65% of features built in traditional tech-first projects are rarely or never used. Meanwhile, studies by McKinsey consistently show that 70% of digital transformations fail to hit their targets—not because the software failed, but because the team built a solution for a problem the user didn’t actually have.

Why? Because technology based innovation focuses on the materials (cloud platforms, AI, blockchain, low-code tools). User-Centered Design focuses on the outcome (solving a real human problem for a citizen or a caseworker).

Focusing on materials is like buying a pile of expensive bricks and tools without knowing what house you want to build. You end up with costly white elephants looking for a problem to solve. It’s a classic trap: buying an AI contract or a new tech platform before understanding what public value it is meant to unlock.

Technology can put new possibilities in reach, but it’s User Centred Design that turns possibility into public value. Successful innovation begins with a laser focus on the user.

Trap 3: The wrong constraints

When projects start to flounder, the instinct in government is often to throw more money, stakeholders, and features at the problem.

This is entirely backward. True innovation rarely comes from unlimited budgets, bloated requirements; it comes from demanding radical outcomes with tightly constrained resources.

Scarcity forces focus. When resources are constrained, teams are stripped of the luxury of over-engineering. They cannot build every ‘nice-to-have’ requirement demanded by internal committees. They are forced to look at the raw, underlying user need and find the leanest possible way to achieve it.

Contrast this with procedural constraints:

• Resource constraints (Good): Tight budgets, small cross-functional teams, and aggressive timeframes force focus, speed, and ruthless prioritization.
• Procedural constraints (Bad): Endless sign-off layers, mandatory feature parity with 20-year-old legacy systems, and risk avoidance force conformity.

Procedural constraints force outcomes to look like whatever came before. Resource constraints force people to find a new way.

Saying ‘no’

To create the conditions for innovation, you have to be willing to say ‘no’ to stakeholders.

Government projects get weighed down because every department, policy team, and oversight group wants their specific requirement baked into the new system. The result is a camel—a horse designed by committee.

If you want an innovative outcome, you need to establish what doesn’t matter. You need to be prepared to descope legacy features, ignore low-value stakeholder requests, and actively build “governance cover” for your delivery teams so they can experiment, learn, and iterate.

The Innovation Checklist

Before you write your next business case or sign off on your next delivery roadmap, sit down with your leadership team and ask four questions:

1. What type of innovation are we actually asking for? Are we making an incremental tweak, re-platforming architecture, or trying to disrupt a service model?
2. Does our governance match the risk profile? Are we forcing a flexible, exploratory project through a rigid, up-front business case process?
3. Are we focussing on technology or outcomes? Are we falling in love with a shiny new technology, or are we obsessed with solving an underlying user problem?
4. What are we prepared not to do? What stakeholder requirements, legacy rules, or non-essential features are we actively willing to jettison to keep the team fast and focused?

If you can answer those questions honestly, you’ll stop chasing the illusion of ‘innovation’—and start delivering real public value.

About the Author