The invoice does not draw the boundary.

Picture two contracts on a conference table, each still folded in thirds the way it came out of the envelope. The first is a statement of work for a new customer platform. It lists the build, the functional testing and the scripts that will load the data, and its last line reads: interface to the payments gateway, specification supplied by customer. The second is a statement of work for the payments gateway. It lists the gateway, its testing and the cutover plan, and its last line reads: connection to the platform, per the interface defined by the platform supplier. Both contracts are signed. Both are, in their own terms, complete. The two documents are invented, but anyone who has run a large program with more than one supplier will recognize the arrangement. Each contract hands the interface to someone else, and the customer has paid for everything on both pages except the thing that has to work between them.

What the customer bought is contracted execution: specified work, delivered and tested against terms written in advance. What the customer kept, whether or not anyone noticed, is retained coordination responsibility: the job of making that work fit with everything else the business runs, including the work of other suppliers. My argument is that outsourcing moves a deliverable across a contractual boundary without moving the dependencies that connect it to the service. The buyer should keep the competence, the evidence and the decision rights needed to govern those dependencies, in proportion to what a failure would cost.

This is not an argument against buying. Specialists often do the work better, faster and more cheaply than the buyer could, and an organization that insisted on building everything itself would pay for its pride in other ways. Nor is it a claim that every software purchase needs a governance apparatus; a routine, reversible purchase should be governed lightly. The claim is narrower. The invoice tells you where the supplier's obligations end. It does not tell you where yours do.

A specification is not a forecast

A statement of work is a specification. It names outputs, acceptance tests, dates and the party responsible for each. Done well, it is precise about the work it covers, and precision is its virtue: the supplier knows what it must deliver, and the buyer knows what it can reject. What a specification cannot be is a complete description of the future. It does not anticipate every change the business will make while the work is underway, every defect in a neighboring system, or every assumption one supplier makes about another. Those gaps are not drafting failures. A contract that foresaw everything would cost more to write than the work it described, and it would still be out of date by the time it was signed.

The gaps matter most where one contract meets another. Inside a single statement of work, the supplier has both the incentive and the authority to sort out its own surprises. At the boundary between two statements of work, neither supplier can change the other's work, and each can point, accurately, at its own document. The interface in Figure 1 is the simplest case, since each contract assigns it elsewhere. More often the gap is quieter. One supplier assumes the test data will be ready by a date, another assumes the shared environment will be stable, and the buyer assumes the two suppliers have talked. Each assumption is reasonable. None is anyone's deliverable.

That is the sense in which coordination is retained. It appears on neither invoice, so it is easy to believe it has been bought. But a dependency between two contracts belongs to whoever holds both of them, and in a program with several suppliers, that is the buyer.

What Williamson compared

The economist Oliver Williamson spent a career on a version of this problem. His 1985 book, The Economic Institutions of Capitalism, carries the subtitle Firms, Markets, Relational Contracting, and it set out the approach that became known as transaction cost economics.¹ When he received a share of the 2009 Nobel prize in economics, the citation was "for his analysis of economic governance, especially the boundaries of the firm." The announcement summarized his central claim: markets and firms are alternative ways of governing a transaction, which differ in how they resolve conflicts of interest, and transactions are more likely to move inside a firm as the assets involved become more specific to the relationship.²

In his prize lecture that December, Williamson began with the question that started the field, and he put it in terms a CIO would recognize: what decides, on grounds of efficiency, whether a firm produces a good or service for itself or buys it from outside.³ His answer was not a rule favoring either side. It was a method. Describe the transaction, compare the alternative modes of governance, of which markets and hierarchies are two, and align each transaction with the arrangement that handles it most efficiently. He called transaction cost economics "an ex post governance construction," meaning that its attention falls on what happens after the deal is signed, when the contract meets circumstances it did not foresee.³

That is the useful part for a technology buyer. The question is not only whether to outsource but how the relationship will be governed once the specification runs out. Work that is standard, easy to check and easy to move to another supplier can be governed mostly by the contract. Work that is entangled with the buyer's other systems, hard to verify and costly to unwind needs something more: a party on the buyer's side who can adapt the arrangement as events unfold.

The framework deserves its critics too. Used mechanically, it can make every relationship look like a contest between self-interested parties, and it can understate what the parties learn from each other, the trust that long relationships build, and the advantages of scale and specialization that make suppliers worth hiring in the first place. Nor does it imply that bringing work in-house solves the problem. Hierarchies have coordination costs and weak incentives of their own, and an internal team can miss an interface as easily as two vendors can. So the recommendation here is not vertical integration by default. It is a governed boundary: buy the execution, and keep enough of the coordination to make the boundary hold.

A migration on the record

Over the weekend of April 20 to 22, 2018, the British bank TSB moved its customers' services and data off the IT platform it had been receiving from Lloyds Banking Group, its former parent, and onto a new platform called Proteo4UK.⁴ The platform had been designed, built and tested by an IT services provider, SABIS, which also migrated the data and was to operate the platform afterward.⁴ The bank had 5.2 million customers. The problems that followed reached them directly: between the migration and April 2019, TSB received 225,492 complaints, about 4.3 percent of its customer base, and paid about £32.7 million in redress.⁴

More than four years later, on December 20, 2022, the Financial Conduct Authority and the Prudential Regulation Authority issued final notices fining TSB a combined £48.65 million: £29.75 million from the FCA and £18.9 million from the PRA, each after a 30 percent discount for settling.⁴⁵⁶ The findings are about governance, and much of the governance in question was about the supplier. The FCA found that TSB's identification of risks did not explicitly address its outsourcing to SABIS, a provider with no experience of managing service delivery from a large number of UK subcontractors; that the bank did not, at the outset, formally and comprehensively assess whether SABIS had the ability and capacity to deliver; and that SABIS relied on 85 third parties of its own, which the regulator called TSB's fourth parties.⁴

The readiness evidence is the most instructive part. In the two weeks before the migration, TSB sought formal assurance that SABIS was ready, and received a letter confirming it.⁵ The FCA concluded that the letter and the supplier confirmations behind it were to some extent "forward looking statements of good intention or expectation" rather than statements of fact, and that TSB had not asked SABIS for further formal comfort from the critical third-party suppliers before going live.⁴ In April 2023, the PRA separately fined the bank's former chief information officer £81,620, finding that he had assured TSB's board that the key supplier was prepared for migration without ensuring that TSB had itself obtained sufficient assurance from that supplier.⁶ That action concerns one person's conduct, and I have nothing to add about it. What it shows is the shape of the gap: a readiness claim that passed from supplier to bank to board without anyone on the bank's side holding the evidence to test it.

Three cautions keep the case in proportion. The findings concern one bank, and a regulated bank's duties for managing outsourcing are not every software buyer's legal duties. The case shows that governance failed around one migration; it does not show that outsourcing usually fails. And the notices record what the bank did and did not do, not anyone's motives, about which I have nothing to say. What they do show, in the regulators' own terms, is the retained half of the arrangement. The bank had bought the platform and the migration. It had kept the job of knowing whether its supplier could deliver, and of testing the evidence that it had.

The retained seat

The remedy is not to rebuild the supplier's team inside the buyer. It is a retained capability, usually small, whose job is the coordination that no single contract covers. Think of it as a seat at the table with three powers. The person in it can challenge evidence: read a supplier's test results and readiness claims well enough to tell a fact from an intention, and ask for the fact. They can resolve dependencies between suppliers: own the interface specifications, the shared test environments and the order of work when two contracts point at each other. And they can say whether the customer service, not just each component of it, is ready, with the authority to stop a go-live when it is not.

How much capability that takes depends on what a failure would cost. The worksheet below sketches three kinds of work, from a routine service to a major migration, and lists for each what the supplier shows to prove its own work and what the buyer must check before accepting it. The rows are illustrative: an operating proposal, not an industry standard and not a reconstruction of TSB's program, and there is no ratio of retained staff hidden in them. Drag across the sheet, or tab to it and use the arrow keys.

Notice which list grows. The supplier's evidence changes a little from one kind of work to the next, because it is mostly reports about the supplier's own work. The buyer's evidence grows quickly, because each step up in consequence adds boundaries to cross and fewer chances to recover. For a routine service, the retained seat is a named owner who actually reads the report. For a major migration, it is a team with the standing to reject evidence, plus independent assurance for the questions the team cannot answer on its own.

Change what the steering meeting asks

Most program steering meetings measure progress the way the contracts do: percent complete by workstream, milestones met, a column of red, amber and green. Those numbers describe contracted execution, and they can all be green while the service is not ready, because the risk lives between the workstreams. A meeting that wants to govern the boundary has to ask about it directly.

Three questions do most of the work. What is true today only because another party is expected to act, and has that party agreed? Who can authorize an exception when two suppliers' plans conflict, and do both suppliers know who that is? Which tests cross an organizational boundary, and who owns each of them from start to finish? A list of unresolved assumptions, each with an owner and a date, is a less comfortable report than a column of percentages. It is also closer to the truth about whether the service will work.

Objections, considered

We outsource precisely because we lack the expertise. That is often the right reason, and it does not change the conclusion. The buyer does not need to master every implementation detail. It needs enough capability to judge the service: to ask the right questions, to recognize an evasive answer, and to know when to commission independent assurance for the parts it cannot assess itself. A buyer with no capability at all cannot even tell whether it has chosen the right supplier.

The contract transfers the liability. Some of it, perhaps. A claim may shift part of the financial consequences of a failure back to the supplier, after the fact. It does not restore the service, keep customers served while the outage lasts, or coordinate the response among suppliers who each have their own contract and their own lawyers. Liability is a way of dividing losses afterward. It is not a way of preventing them or managing them while they happen.

More governance slows delivery. Badly designed governance does. Proportional governance should make delivery faster, because its purpose is to surface unresolved assumptions early, when they are cheap to fix, rather than on the weekend of the go-live. And proportion cuts both ways. A routine, reversible purchase should not inherit the controls of a bank migration; the first column of the worksheet asks for a named owner and a decision on the record, and nothing more.

You can buy the work without buying your way out of coordinating it.

Before the next signature

• Who understands the interfaces? Not who drew them: who would notice if one changed.
• Who can reject readiness evidence? And has that person ever done it.
• What is true only because someone else will act? Write each assumption down with an owner and a date.
• Who decides when two contracts point at each other? Name the person before the conflict, not during it.
• Which tests cross a boundary? Each needs one owner from start to finish.

Back to the two contracts on the conference table. Neither has to be rewritten. What is missing is a third line, written on the buyer's side: the interface between the platform and the gateway belongs to our integration lead, who will test it end to end and who can say it is not ready. The suppliers will still deliver what they were paid for. The difference is that someone will be responsible for making it work together.