Delivered, Not Changed: The Capability Every Transformation Trades Away to Hit Its Dates

Essay·Giovanni Leonardi·April 2006·16 min read

An organisation that buys its way through every change, however well each individual programme is delivered, never becomes better at changing.

Executive Summary

Every large transformation carries two commitments that are rarely named as rivals. The first is external and visible: the deliverables, the dates, the benefits promised to a board and written into a business case. The second is internal and nearly invisible: the capability the organisation must hold afterwards, so that what has been built can be run, changed and improved by the people who remain. This essay examines why these two commitments pull against each other, why the tension is structural rather than a failure of discipline, and what an organisation’s response to it reveals about how change actually happens.

The argument, in brief, is that the fastest route to delivery is to concentrate the work in experienced external hands — a systems integrator, a firm of consultants, a bench of contractors — precisely because they arrive already able to do it. But capability is built by doing, not by receiving; so the very arrangement that protects the date starves the organisation of the learning it needed most. Knowledge transfer, the mechanism meant to reconcile the two, is treated as a terminal line item and is the first thing sacrificed when the plan compresses. The result is a recognisable class of programme: one that delivers its artefact and fails to change its organisation. New assets, unchanged capability, and a rising dependence that wears the costume of success.

I am not arguing that everything should be built in-house — that is its own error, and an expensive one. The essay turns instead on an older distinction: which capabilities are core, and must therefore be owned, and which are contextual, and can sensibly be bought. What organisations most often misjudge is not the sourcing of any single system but the sourcing of the capacity to change itself — the one competence a transforming organisation cannot afford to rent. Read that way, the dual-delivery problem is not a scheduling nuisance. It is a mirror held up to how change really works: through people who do new things and keep what they learn, or not at all.

The Thursday the Programme Was Declared a Success

The programme was declared a success on a Thursday. The steering committee saw a report that was green across the top row — scope delivered, budget held to within a rounding error, the final milestone signed off two days early. There were thanks recorded in the minutes, and afterwards a modest gathering with warm white wine in plastic cups. It had been three years of hard, capable work, and by the only measures the committee had been given, it had gone well.

What the report did not show, because no column had ever been built to hold it, was that of the roughly seventy people who could explain how the new arrangement actually worked, all but a handful were about to leave. They were the integrator’s people and the day-rate contractors, and their statements of work ended with the programme. Within ninety days the building would empty of nearly everyone who understood the thing that had just been switched on. The organisation had bought a capability and, in the same motion, arranged to forget how it worked.

This is not a story about a bad programme. It is a story about a good one — competently governed, honestly reported, delivered close enough to plan to be called a win — and that is exactly what makes it worth dwelling on. The failure was invisible not because anyone hid it but because the instruments were never designed to detect it. We had measured the delivery of the commitment and left the building of the capability entirely unmeasured, and then we were surprised, two years on, that we could not change the thing we had built without calling back the people who had built it, at a rate that no longer looked like a bargain.

Two Commitments, One Budget

Set the two commitments side by side and the trouble becomes clear. The external commitment is a promise to the outside of the programme — to the board, the sponsor, the customers, the regulator: this will exist, it will work, and it will be here by this date. It is specific, dated, and ferociously well governed. Every serious method we use — the stage gates, the milestone plans, the benefits maps — exists to protect it.

The internal commitment is a promise to the future of the organisation: when this is done, we will be able to run it, understand it, and change it ourselves. It is real, but it is diffuse. It has no date, no gate, and usually no owner. And here is the difficulty that no amount of goodwill dissolves: both commitments draw down the same scarce resource. Not money — the money can often be found. The scarce resource is the attention, the time, and the hands of the small number of internal people who are good enough to learn deeply while the work is being done.

The external commitment competes for exactly the people the internal commitment depends on — and the external commitment always wins the argument, because it is the one with a date on it.

Put your best internal engineer on the critical path and they deliver; put them next to the integrator to learn, and the critical path slows. Faced with that choice under time pressure — and it is always under time pressure — the rational programme manager makes the rational choice. They protect the date. They do it again the following week, and the week after, and by the end a hundred small rational choices have added up to an organisation that delivered everything it promised the outside world and kept almost nothing for itself.

Why the Bargain Is Structural

It would be comforting to file this under weak management, because weak management can be replaced. But the pattern recurs across organisations that are not weakly managed at all, which tells us the cause is structural. Several forces hold the bargain in place, and they reinforce one another.

  • The business case rewards artefacts, not capacity. A business case counts the system delivered and the benefit booked. It has no line for “the number of our own people who can now do this unaided,” so that quantity is managed by no one and protected by nothing.
  • The fastest path to delivery concentrates the work externally. An integrator’s staff arrive fluent. Your own people arrive willing but slow, because they are learning. Under a deadline, fluency wins every allocation decision, and fluency is exactly what you are renting rather than growing.
  • The measurement is asymmetric. A slipped milestone is visible on Monday morning. Eroding internal capability produces no alert, no red cell, no escalation — it shows up years later as a change that is strangely expensive, by which time the programme is long closed and no one connects the two.
  • The clocks run at different speeds. Commitments are due quarterly. Capability compounds over years — it is the slow accumulation of people who have done the thing and can do it again. A quarterly instrument will always sacrifice a multi-year asset it cannot see to protect a dated one it can.
  • The provider’s incentive points the other way. This is not villainy; it is arithmetic. A firm whose revenue continues only while you remain dependent has no structural reason to make itself unnecessary quickly. That is not a conspiracy — it is simply what a rational supplier does when the contract rewards presence rather than departure.

Notice that none of these forces is a mistake. Each is the sensible local response to a real pressure. That is precisely why the tension is durable: it is manufactured by the ordinary, competent operation of the system, not by its breakdown. Anyone who believes they will dissolve it with better intentions has misunderstood what they are dealing with.

The Illusion of Knowledge Transfer

The standard answer to all of this is a phrase that appears in almost every large contract: knowledge transfer. There will be a phase, usually near the end, in which the departing experts hand over what they know. Documentation will be produced. Sessions will be held. Somebody will sign to say it happened.

The phrase deserves more suspicion than it gets, because it smuggles in a false picture of what capability is. It imagines knowledge as a substance — a fluid that can be decanted from a full vessel into an empty one — and treats a working capability as though it were the same kind of thing as a document. But most of what makes someone able to run and change a complex system is not written down and cannot be. It lives in judgement: knowing which warnings matter and which are noise, remembering why a particular decision was taken and what it would break to reverse it, sensing where the fragile joints are. This is tacit knowledge, and its defining property is that it is acquired by doing, not by being told.

“You cannot hand over a capability at the end. You can only build it throughout, or not at all.”

Which is why the terminal knowledge-transfer phase so reliably fails even when it is honestly attempted. Two weeks of shadowing at the close of a three-year programme cannot deposit three years of accumulated judgement, and the calendar guarantees it will be the first casualty of any slippage — it sits at the end, after the go-live that everyone actually cares about, and end-of-plan contingency is always spent by the time you reach it. The organisation is left holding what can be written down — the manuals, the diagrams — and missing the very thing that separates someone who can operate a system from someone who merely possesses its documentation.

There is a subtler loss too. When your own people are kept off the hard problems so the schedule can be protected, they are denied not just the answers but the experience of having wrestled with the questions — the trail of wrong turns and corrections that is how understanding is actually laid down. They inherit the conclusions without the reasoning, which means they can recite the design but cannot safely change it, because they never learned the argument that produced it.

What the Make-or-Buy Question Really Asks

None of this argues for building everything yourself. That is the opposite error, and it is just as costly. An organisation that insists on growing every capability in-house is slow, parochial, and forever re-learning at its own expense lessons that an experienced outside hand already carries. External providers bring something genuinely valuable: pattern knowledge from having seen the same problem in twenty other places, and the plain capacity to do more than a single organisation could ever staff for itself. Hoarding all delivery internally is not a virtue; it is a different way to fail.

So the real question was never build or buy in general. It is the older and sharper question of which capabilities are core and which are contextual — and the discipline lies in telling them apart honestly. A contextual capability is one you need to have available but have no reason to own; there is no advantage in being the organisation that runs it best, and renting it is simply efficient. A core capability is one on which your ability to compete and to adapt depends. That one you must own, because to rent it is to place the thing you most need to control in hands whose interests are not yours.

Contextual capability Core capability
Needed, but confers no advantage by being owned Your ability to adapt depends on it
Sensibly rented; efficiency is the only question Must be owned; control is the whole point
Losing the know-how afterwards costs little Losing the know-how afterwards is the real failure
Buy it, and be glad someone else keeps it sharp Build it while delivering, or you have not really acquired it

Here is the turn the whole essay has been working towards. When we ask which capabilities are core to a transformation, we usually answer in terms of the subject matter — the new system, the new process, the new operating model. But the deepest core capability a transforming organisation holds is not any of those. It is the capacity to change itself: to absorb a new way of working, to keep the understanding that a change deposits, and to be more able to make the next change because of it. That capacity is the one competence a transforming organisation cannot coherently outsource, because outsourcing it means paying an external party to hold the very thing transformation is supposed to be building. An organisation that buys its way through every change, however well each individual programme is delivered, never becomes better at changing. It simply becomes a more experienced buyer of other people’s ability to change it.

A Worked Illustration

Make it concrete. Consider a programme with a budget of forty million pounds over eighteen months, staffed roughly seventy per cent by an integrator and specialist contractors and thirty per cent by the organisation’s own people — a wholly ordinary ratio for work of this size. It delivers. The report is green; the benefit case holds. By every governed measure it is a success, and it is right to call it one.

Two figures tell the other half of the story. The first is the annual cost of the managed service that keeps the new arrangement running afterwards — say six million pounds a year — a cost that does not fall over time but drifts upward, because the internal team never reaches the point of being able to take the work back, and a supplier under no pressure to leave has little reason to help them get there. The second figure appears the first time the business needs a genuine change to what was built. A modification that ought to be modest turns out to take three or four times as long and as much as it should, and to require the return, at a premium rate, of a handful of the original experts — because no one who remains can safely touch the design without them.

Put those two numbers where the programme’s balance sheet can see them and the picture inverts. The eighteen-month delivery was not the whole cost of the transformation; it was the deposit. The real price is the multi-year annuity of dependence that follows, and that annuity is the exact financial shape of a capability that was never built. It was, in a precise sense, the cheapest thing to cut during the programme and the most expensive thing to be without after it.

  1. During delivery, capability-building looked like an overhead — the slower path, the two people learning instead of shipping.
  2. After delivery, its absence looked like a permanent tax — every future change dearer and slower than it needed to be, indefinitely.
  3. Between the two sat a single quiet decision, taken under deadline pressure and recorded nowhere: to protect the date by spending the capability.

What Changing Organisations Actually Do

If the tension is structural, it cannot be abolished; it can only be governed. The organisations that come out of transformation genuinely changed — rather than merely re-equipped — are the ones that treat the internal commitment as a real commitment, with the same seriousness they already grant the external one. That is less a technique than a change of stance, and it shows up in a few consistent habits.

They make capability a deliverable in its own right, with its own milestones and its own line on the status report, so that “how many of our people can now do this unaided” is a number someone owns and is answerable for — not a hope pinned to a phase at the end. They build the learning in from the first day rather than saving it for the last, accepting a deliberately slower path early because they understand what the fast path silently costs later; they put their own people on the hard problems, shadowed by the experts, rather than the reverse. They watch the ratio — how much of the critical understanding sits with people who will leave against people who will stay — and they treat a bad ratio as a risk to be escalated, not an accounting detail. And they contract for departure rather than for presence, structuring the arrangement so that the supplier is rewarded for making itself unnecessary, which is the only version of knowledge transfer that has ever actually worked.

None of this makes the programme faster or cheaper in the quarter. It is, honestly, a tax on delivery — and that is the point. The organisation is choosing to pay visibly and now, in a slightly slower plan, rather than invisibly and later, in a dependence that compounds. That is a judgement a steering committee can only make if someone puts the second commitment in front of it in language it can weigh. Left unspoken, the internal commitment loses every argument to the dated one, not because anyone decided it should, but because only one of the two was ever allowed to speak.

Which returns us to the Thursday, and to what the whole pattern reveals. We tend to picture organisational change as something done to an organisation — a new system installed, a new structure imposed, a target state reached. But an organisation is not changed when its assets change; it is changed when its people can do something they could not do before and retain the ability to do it again. A transformation that delivers a flawless artefact into hands that cannot work it has changed what the organisation owns without changing what it is. The dual-delivery problem is uncomfortable precisely because it forces that distinction into the open. Real change was never the thing we handed over. It was the capacity we either built along the way — or contracted away, one rational Thursday at a time.


More from Transformation