The Job No One Invoices

A director described their project to us last spring: a mobile application, a public website, a back office, a budget of around three hundred thousand euros. They had been told they needed a strategy agency, a design studio, a development company, a hosting provider, and a project management consultancy to coordinate the other four. Five contracts for one product.

Their question was not whether this was expensive. It was whether this was normal.

We are badly placed to answer it. Synograph takes projects from end to end, which gives us a direct commercial interest in the answer being “just one”. That is precisely why nothing below is our own argument. We use other people’s numbers.

What has already been written about this

A great deal, and almost entirely by people who sell the answer.

In English, the literature is a run of agency posts titled “single vendor versus multiple vendors”, each concluding in favour of whatever the publisher happens to do for a living. The arguments are symmetrical and familiar: one point of contact simplifies communication, several suppliers give you the best of each speciality. None of these texts produces a single piece of data.

In France the dominant answer is stranger. Faced with a project split across several suppliers, the convention is to add an independent consultancy whose job is to coordinate them. The solution to the problem of five parties is therefore a sixth party. That answer is sometimes right, and we will say below when; it is rarely presented as what it is, which is one more layer.

There is serious data on this exact question. It is not published by agencies, but in two fields decision makers do not read: the economics of outsourcing and the economics of projects.

The threshold exists, and someone measured it

Ravi Bapna, Alok Gupta, Gautam Ray and Shweta Singh analysed 49,057 IT outsourcing arrangements signed between 1989 and 2014, averaging 58 million dollars each. As far as we know it is the only large-scale empirical work on the choice between one supplier and several. Three of its findings deserve to be known by anyone buying a project.

The first is a curve, not a rule. The more distinct services an arrangement covers, the more likely multiple suppliers become, but only up to around five services. Past that point the coordination costs exceed the gains from specialisation, and a single supplier becomes the rational choice again. So there is a threshold, and it sits lower than intuition suggests.

The second finding is the important one, and no agency post mentions it. What decides is not the size of the project, it is the capability of the client. Splitting work across suppliers assumes you can specify what you expect from each of them, monitor what they deliver, coordinate their schedules and integrate their deliverables. The authors call this the client’s outsourcing capability. Where it exists, the client acts as its own integrator and genuinely profits from specialisation. Where it does not, the same decision produces the opposite effect.

The third finding is a penalty. Across 1,588 contracts with known outcomes, a mismatch between the situation and the sourcing choice predicts contract failure: cancellation or renegotiation. This is not a matter of organisational preference. It is material.

One caveat is owed, and we would rather raise it ourselves. These contracts average 58 million dollars. Yours is worth three hundred thousand. The mechanism transfers, the number does not. And if the threshold moves, it most likely moves down: a mid-sized company has less integration capability than a large group, not more.

What you are buying when you split

A project handed to n suppliers contains n(n-1)/2 pairs that may need to talk to each other. This is not a study, it is arithmetic.

suppliers   pairs to hold together
    2                 1
    3                 3
    4                 6
    5                10

In practice not all of those pairs talk. The trouble is that you do not get to choose which ones will, and you find out late: the day the payment provider imposes a behaviour the mockups never anticipated, or the day the hosting provider discovers the application writes to a directory that does not exist on their machines.

The real cost is not there, though. It is in the translation. Every contractual boundary is a place where a user’s problem gets rewritten as a deliverable. The design studio delivers screens that conform to the design brief. The development company delivers features that conform to the development brief. Both are in order. Nobody signed for whether anyone can actually get through it.

Who decides, and on what grounds

Yingying Ge

I will take an ordinary example, because projects are always lost on ordinary things.

A payment screen. The designer wants one page, because people drop out between two pages and we have watched it happen in testing. The developer wants two pages, because the payment provider requires a redirection, and a single page would force us to hold data we would rather not hold. Both are right. This disagreement has no theoretical solution.

Inside one team it is settled in an afternoon. We do not look for who is right, we go back and look. Our rule is simple: a disagreement about what people do is settled by watching people do it, never in a meeting. If nobody has a recent observation, we go and get one. It takes two days, rarely more. We call this arbitration by observation, and it is the only authority we recognise inside a project: not the job title, not the seniority, not whoever spoke last.

Across two contracts the same disagreement is not settled this way. It travels upward. It arrives with the client, which is to say with the person who holds the least information of the three, and who now has to arbitrate between two suppliers who each have a contractual reason to be right. The decision is then made on leverage, on the calendar, or on fatigue.

I learned this work in Shanghai, in teams where the question did not arise, because the person answering customer messages sat in the same room as the person writing the code. This is not about culture. It is about distance: the time an observation takes to reach somebody who is allowed to act on it. Every additional contract lengthens that time, and it is easier to measure than to fix.

A coordinator does not buy back the risk

Adding a party whose job is to coordinate the others feels almost free: it changes nothing about the work, it only adds oversight. That assumption has been tested elsewhere, on an adjacent question.

DORA’s research on software delivery organisations looked for evidence that a formal, external approval process lowers the rate of failed changes. They found none. Worse, such processes slow delivery down, which leads to larger batches shipped less often, and therefore raises the very risk they were meant to reduce.

That result does not say oversight is pointless. It says that oversight exercised by someone who did not do the work produces no safety, only delay. Applied to coordinating suppliers, it gives a useful distinction: a coordinator who cannot build cannot arbitrate a technical trade-off, they can only pass it on. And a trade-off passed on comes back to the client.

There are situations where an independent coordinator is the right call, and they are recognisable. When several suppliers are imposed and irreducible, an ERP already in place, a bank, a legacy system nobody will replace, coordination becomes a discipline of its own and is better given to someone who is not judge and party. What does not work is using that role to repair, after the fact, a split that should not have been made.

The risk is in the tail, not in the average

That leaves the question a decision maker actually asks: does any of this change the outcome?

Bent Flyvbjerg and co-authors assembled 5,392 IT projects and examined the distribution of their cost overruns. The ratio of actual to estimated cost has a median of 1.0 and a mean of 1.8. In plain terms: half of all projects roughly hold their budget, and the average is close to double. The entire gap is in the tail.

That tail is not a sampling accident. It follows a power law, and over part of its range the exponent is such that neither the variance nor the mean is defined. The authors put it without hedging: the average cost overrun of IT projects does not exist. Disasters are not anomalies, they are the extreme values of a perfectly regular distribution.

A more recent paper by the same authors, released online in May 2025 in Project Management Journal, compares IT with twenty-two other project types. The verdict is unambiguous: IT has a fatter tail than any other category, bridges, tunnels and power plants included. Four standard explanations are reviewed: immaturity, intangibility, goal ambiguity, and stakeholder resistance.

The inference that follows is ours rather than theirs. Two of those four causes, intangibility and goal ambiguity, are exactly what a contractual boundary multiplies. Every additional contract is a place where what you are building gets written down again, often months later, and often by people who were not in the room on the day it was decided.

For a buyer the consequence is direct. Comparing three quotes means comparing three medians. What destroys a project sits in the tail, and the tail appears on no quote. It does not depend on the price but on a different question: who answers when it arrives.

Five questions before signing

None of them presumes the answer. They apply to us exactly as much as to five suppliers.

1. Who integrates? Have a person named, not a company, and have the name written into the contract. If nobody is named, the integrator is you.
2. What happens when the designer and the developer disagree? A supplier who answers “we talk it through” has no method. Ask for the last time it happened, and how it ended.
3. How many interfaces, and which ones? Count boundaries, not suppliers. A clean boundary documented by somebody else, a payment provider for instance, costs almost nothing. A boundary through the middle of the product costs continuously.
4. What do we keep if we stop tomorrow? The code repository, the infrastructure described as code, the accounts and domain names in your own name, the operating procedures written for somebody who was not there.
5. Who gets called at night, and on what number? It is the only question whose answer cannot be shared between five companies.

The principle behind all five fits on one line: split where the interface already exists and somebody else maintains it, do not split the product itself.

What this position costs us

Arnaud Beaussier

It has a price, and leaving that unsaid would be dishonest.

A team that holds the whole chain cannot be the best at every link. We will never have the lab of a specialised usability practice, nor the depth of a thousand-developer company on one particular technology. There are projects for which we are the wrong choice, and we would rather say so before signing than in the sixth month.

There is also something we owe the client in return, and it is technical. Taking the whole chain means accepting that we become a point of dependency. The only honest answer to that is reversibility, and reversibility is built rather than promised: the repository is yours from day one, the infrastructure is described as code rather than configured by hand, the accounts and domain names are in your name, the operating procedures are written for somebody who was not there. A team that cannot be replaced is not a partner, it is a debt.

So the right indicator is not the number of suppliers on your project. It is the number of people who have to agree before anyone can fix something for a real user. Count it before you sign. That number usually decides the rest.