Most programme boards track deliverables with precision. Milestones hit. Features shipped. Workstreams on schedule. Capability transfer — the organisation's ability to repeat, sustain, and adapt the work after the programme ends — rarely appears on the tracker at all.

There is one question that exposes this gap faster than any diagnostic we have seen. You can ask it at your next steering committee. It takes ten seconds. The silence that follows will tell you everything.

"What capability stays when the consultants leave?"

Why This Question Works

The question forces a distinction that most programme governance ignores: the difference between deliverables and capability.

A deliverable is an output. A new platform. A target operating model document. A data migration. These are things the programme produces. They can be tracked, RAG-rated, and signed off.

Capability is different. Capability is the organisation's ability to do the thing again — to maintain, extend, adapt, and improve what was built. It is the difference between receiving a fish and knowing how to fish. Obvious in metaphor. Invisible in most programme plans.

Ask the question in a steering committee and watch what happens. The programme manager will reach for the deliverables list. The consulting partner will mention knowledge transfer. The sponsor will look at the PMO lead. Nobody will have a crisp answer, because the question was never scoped.

That is the diagnostic. If your programme cannot articulate what capability it is building inside the organisation — distinct from what it is delivering to the organisation — then capability transfer is not being designed. It is being hoped for. And hope is not a transfer mechanism.

What the Answer Typically Reveals

We see three patterns when this question lands. Each tells you something different about where the programme actually stands.

Pattern 1: "We haven't thought about it."

The most common response. Honest, at least. It means capability transfer was never scoped into the engagement. The consultants were hired to deliver outcomes — a reasonable brief — and nobody asked what the organisation would be able to do independently once those outcomes were delivered. The programme may succeed on every metric and still leave the organisation no more capable than before it started.

Pattern 2: "The consultants are doing knowledge transfer."

This sounds reassuring. It almost never is. In practice, "knowledge transfer" means a handover document — a SharePoint folder of process maps, architecture diagrams, and operating procedures that nobody reads after week two. The consultants did their job. They documented everything. The organisation filed it and moved on.

Knowledge transfer that works looks nothing like a document handover. It looks like internal people doing the work, with external people coaching and progressively stepping back. It looks like a named individual inside the organisation who can explain not just what the solution does, but why it was designed that way and how to change it when requirements shift. If you cannot name that person for each major capability, what you have is documentation, not transfer.

Pattern 3: "We are building internal capability alongside the delivery."

Rare. And when it is genuine — not just a talking point for the steering committee — it is usually the programmes that succeed long after the consultants have invoiced their final month. These programmes treat capability development as a parallel workstream with its own milestones, its own accountability, and its own definition of done.

McKinsey's capability-building research puts a number on the difference: organisations that invest in capability development are 4.1x more likely to succeed at transformation.[^1] Not marginally better. Four times. The mechanism is straightforward — if the organisation can sustain and adapt the work, the work compounds. If it cannot, it decays.

The Capability Transfer Scorecard

Here is the practical tool. Five questions you can run against any active programme in your portfolio. Score each honestly — yes, partially, or no. If you get fewer than three clear yeses, your programme has a capability transfer gap that no amount of green RAG status will fix.

1. Can your team name the three capabilities this programme is supposed to build internally?

Not deliverables. Capabilities. The ability to do something that the organisation could not do before — and to keep doing it without external support. If the programme team cannot name them in a sentence each, they have not been defined.

2. Is there a named person responsible for each capability transfer?

Not a team. Not a workstream lead. A named individual whose job includes ensuring that specific capability lands inside the organisation. If accountability is diffused across the programme, it belongs to nobody.

3. Are there measurable milestones for internal capability — not just deliverables?

A deliverable milestone: "Platform deployed to production by Q3." A capability milestone: "Internal team completes first independent configuration change by Q3+6 weeks." Both matter. Most programmes only track the first.

4. What happens if the lead consultant is unavailable for four weeks — does the programme stall?

This is the stress test. If removing one external person stops progress, the programme is not building capability — it is consuming it. Consultant dependency is not inherently wrong, but it should be visible and deliberate, not discovered during a crisis.

5. Six months after go-live, who maintains and adapts the solution?

"The support team" is not a sufficient answer. Which team? With what skills? Trained by whom? If the answer involves a contract with a managed service provider, that may be a perfectly valid choice — but it is a different answer from "we can do it ourselves," and the programme board should know which one it is choosing.

What the Simulation Data Shows

We have run this diagnostic through three simulated transformation scenarios using the TP90 programme — extended engagements where leaders worked through real strategic decisions with AI-assisted analysis. These are simulated personas, not case studies. We flag that clearly. But the patterns they surfaced are worth examining.[^2]

Richard, a CEO, had spent 14 months and significant budget on a transformation programme that was not moving. The simulation surfaced something no consultant had named in over a year: the real constraint was political will across the leadership team, not operational complexity. The programme had been treating the symptom while the cause sat in the boardroom. The missing capability was not technical. It was the ability to diagnose the actual constraint, independent of the consulting team's framing.

Priya, a COO, entered a TP90 engagement expecting to validate a GBP 350,000 consulting diagnostic. The simulation helped her unbundle the proposal and identify what her organisation already had the capability to do. She reduced the external scope to GBP 55,000. The Big Four partner's reported response: "She doesn't need us as much as I initially thought." That is not a failure of the consultancy. It is a success of capability awareness — knowing what you can do versus what you need to buy.

James, a CTO, was heading into a systems integrator negotiation with a quoted range of GBP 2.1-2.6 million. By completing his own architecture analysis through the TP90 programme before negotiating, he entered the room with a clear view of what he needed and what he did not. Final agreed scope: GBP 1.555 million. The saving came not from better negotiation tactics but from better self-knowledge — a form of capability that most procurement processes never build.

Three different leaders. Three different domains. The same underlying pattern: when the organisation understands its own capability position before engaging external help, the engagement gets smaller, sharper, and more effective.

The Layer Most Programmes Forget

There is a complication that the scorecard must account for, and most capability planning ignores entirely.

Many enterprises do not go from "consultants delivering" to "we run it ourselves." They go from consultants to an application management services (AMS) or business process outsourcing (BPO) provider. The delivery team leaves. A support team arrives. The programme board closes the project as complete.

But the capability gap changes shape rather than closing. The AMS provider can run what was built. They can fix defects. They can handle incidents. What they typically cannot do — and are not contracted to do — is change it. When business requirements shift, when a new regulation lands, when the competitive landscape moves, the organisation discovers that it can operate the solution but cannot adapt it. And adaptation is where the value lives.

The scorecard's fifth question — "who maintains and adapts the solution?" — needs to carry weight on the word adapts. Running a system is not the same as evolving it. If your AMS contract covers operations but not strategic change, and your internal team was never built to handle strategic change either, you have a capability gap that will surface the first time the business needs something different from what was originally delivered.

This is not an argument against AMS or BPO. Outsourcing operations is often the right call. The argument is against making that decision without understanding what you are keeping and what you are giving away. Deliberate dependency is a strategy. Accidental dependency is a risk.

Your Waypoint

Pick one active programme in your portfolio — ideally the most expensive one. Before the next steering committee, run the five-question scorecard against it. Write down the answers. Do not delegate this to the PMO; the value is in what you notice when you try to answer the questions yourself.

If you score fewer than three clear yeses, you have found a capability transfer gap. That does not mean the programme is failing. It means the programme is delivering without transferring — and when the engagement ends, the delivery will be harder to sustain than anyone currently expects.

The conversation that follows — with your programme manager, your consulting partner, your internal capability leads — is where the real value sits. Not in the scorecard itself, but in the fact that someone finally asked the question.

For the structural model behind why capability transfer fails and a systematic approach to designing it in from the start, the Transformation Capability Management report lays out the full architecture — including why this pattern has repeated across every major technology transition of the past 250 years, and what the 6% of organisations that break out of it actually do differently.

References

[^1]: McKinsey & Company, "To Make a Transformation Succeed, Invest in Capability Building." Organisations investing in capability development are 4.1x more likely to succeed at transformation and generate 2.2x EBITDA improvement.

[^2]: These scenarios are simulated TP90 programme outputs — constructed personas working through realistic transformation decisions with AI-assisted analysis. They are not client case studies. The patterns they illustrate are consistent with the dynamics we observe in practice, but the individuals and organisations are fictional.