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.