It sounds like a small distinction. It is, in fact, the whole game. Most of what goes wrong with consultancy in the NHS - the spiralling extensions, the systems no internal team can operate, the institutional knowledge that walks out of the door when the contract ends - traces back to a single structural fact. The conventional consulting model is quietly incentivised toward dependency. The longer you need them, the better they do. And almost no one names this when the contract is being signed.

This piece makes the case for buying differently: for treating the capability a consultancy leaves behind as the real deliverable, and for measuring success by the day your own people no longer need the help. It's a particular point of view. But after a decade of NHS data programmes that delivered slideware and dependency in roughly equal measure, it's one the sector is increasingly ready to hear.

The dependency trap is structural, not malicious

Let's be fair to consultants. Dependency rarely comes from bad faith. It comes from incentives and habits that all point the same way.

A firm paid by the day has no commercial reason to compress its own engagement. A team focused on hitting delivery milestones has no time to slow down and teach. Knowledge accumulates in the supplier's heads because that's where the work happens, and documentation is the first thing cut when timelines tighten. Bespoke tooling gets built the supplier's way, configured to the supplier's conventions, comprehensible mainly to the supplier. None of this requires anyone to be cynical. It just requires everyone to do the obvious thing under normal pressures.

The result is a system that works beautifully right up to the moment the contract ends - at which point the trust discovers that the architecture runs, but nobody in-house fully understands why it runs, or how to change it safely. So the contract gets extended. And the dependency deepens. The trust hasn't been cheated; it has simply bought a model that was never designed to make it self-sufficient.

Why the NHS is uniquely exposed

Every sector has this problem. The NHS has it worse, for reasons specific to how it operates.

Public-sector pay scales make it hard to retain the scarce data and engineering talent that the private sector competes hard for, so internal capability is fragile and churns. Budgets are scrutinised line by line, which means a programme that quietly requires perpetual external support becomes a recurring political liability, not just a cost. And the structure of NHS procurement means trusts re-tender similar work repeatedly - paying, in effect, to re-learn the same lessons because nothing durable was retained the first time. A trust that ends each engagement no more capable than it started is on a treadmill: always buying, never building.

There's also a deeper point about mission. A commercial firm that outsources a function forever may be making a rational sourcing choice. A public body has a stewardship duty - to leave the institution stronger, more capable, and better able to serve its population over time. Permanent dependency on external suppliers for something as foundational as data architecture sits awkwardly with that duty.

2026 has sharpened the question

This conversation isn't new, but it has acquired a hard edge in 2026. The whole NHS data debate this year has been shadowed by anxiety about lock-in - about depending on platforms and suppliers whose terms, ownership, or future a trust does not control.  

That same instinct applies to consultancy, and trusts are starting to make the connection. If you wouldn't want to be locked into a platform you can't leave, why would you accept a consulting relationship you can't end? The capability agenda - the push to build durable internal skills rather than rent them indefinitely - has moved from a nice-to-have in the closing paragraph of a strategy document to a genuine procurement priority. Budget pressure has done the rest. "Buy us help we'll eventually stop needing" is no longer an idealistic ask; it's a fiscal one.

Reframe: the capability is the deliverable

The shift that resolves all of this is deceptively simple. Stop thinking of the architecture as the deliverable and the knowledge transfer as a nice extra. Invert it. The durable capability - the skills, the understanding, the documentation, the confidence - is the deliverable. The architecture is just its most visible artefact.

This reframe changes what "good" looks like at every stage. A discovery exercise isn't good because it produces a report; it's good because your team learns how to read and maintain the estate map afterwards. A migration isn't good because the data moved; it's good because your engineers can run the next one without help. A governance framework isn't good because it's compliant on handover day; it's good because your IG team can operate and adapt it a year later. The test is always the same: what can the trust now do that it couldn't before?

What "capability, not dependency" actually looks like

This is where buyers can get concrete - because the difference between a firm trying to leave and one trying to stay shows up in observable behaviours, not in the warm words of a proposal. Look for:

• Knowledge transfer built into every phase, not bolted on at the end. If "handover" is a line item in the final month, it's theatre. Real transfer is continuous - your people working alongside the consultants throughout, not receiving a document dump at the close.

• Documentation as a deliverable in its own right. Runbooks, architecture decision records, and plain-language explanations of why choices were made - not just what was built. Decision records are the difference between a system you can evolve and one you can only preserve.

• Standard, transferable tooling over bespoke cleverness. Solutions built on mainstream, well-documented technology your team can hire for and learn - not a uniquely configured edifice only the supplier understands.

• A named skills-gap assessment. A serious partner will help you understand what capabilities your team is missing and deliberately close those gaps, rather than quietly working around them.

• A clean exit by design. No data, credentials, or critical knowledge that only the supplier holds at the end. The relationship should be a defined interface you can step away from - not a dependency you have to unwind.

A firm comfortable with all five is a firm planning to leave you stronger. A firm that bristles at them is telling you something important.

How to buy for it

Capability doesn't happen by accident; you have to procure for it. Practical levers:

1. Write capability transfer into the evaluation criteria and the contract - with named, assessable outputs (documentation standards, embedded working, defined skills outcomes), not vague "we'll upskill your team" assurances.

2. Ask for the exit plan up front. A supplier confident in its model can describe, at the bid stage, exactly how the engagement ends and what you'll be able to do without them.

3. Require co-delivery, not delivery-to. Your people on the team from day one, learning by doing.

4. Measure capability, not just delivery. Track what your team can independently operate at each milestone - and treat that as a first-class success metric alongside the technical deliverables.

The test, restated

So return to the question at the top. When you assess a data consultancy, listen for whether they're describing how indispensable they'll become - or how cleanly they intend to leave you self-sufficient. One of those is selling you a dependency. The other is selling you a capability you'll keep long after they've gone.

For a public institution with a stewardship duty, a tight budget, and a hard-won wariness of lock-in, the better answer isn't subtle. Buy the help you'll eventually stop needing.

At VE3, we build NHS data capability by design - embedding knowledge transfer in every phase, leaving behind documentation and decision records your team owns, and engineering a clean exit so you're more capable, not more dependent, when we're done. If you'd like our short guide to writing capability transfer into a data procurement, get in touch.