6 July 2026 · Insight

The Price of Yes: What One More Project Really Costs

A senior leader is offered a new project.

The business case is good. The client is credible, the margin is healthy, and the work is a natural fit for the team. Someone checks the resourcing and reports that the key people are running at about eighty percent, so there looks to be room. The project is approved.

On paper, this is good management. A promising opportunity, a quick decision, a team that is not sitting idle.

Here is the problem.

The cost of that decision does not appear anywhere on the new project's business case. It lands somewhere else entirely, on the work that was already in flight, and by the time it shows up as slippage nobody connects it back to the yes that caused it.

This is one of the most expensive habits in project-led organisations, and almost nobody prices it. This piece is about how to.

The cost does not sit where you are looking

When you approve a project, you evaluate it on its own terms. Its revenue, its cost, its return. That is what a business case is: a self-contained argument for one piece of work.

But a project does not run on its own terms. It runs on shared people.

Every delivery promise is a draw on constrained capacity. The moment you say yes, your senior engineer, your lead analyst, your one person who actually understands the integration, all get another claim on their time. That claim competes with everything else they were already committed to.

So the real question is not whether the new project is worth doing. It is whether the new project is worth doing instead of, or on top of, everything already in the queue. Those are completely different questions, and the business case only answers the first one.

Flow Economics has a name for the habit of judging a project as though it were the only one drawing on your people. It is called the Project Illusion, and you can read the fuller treatment in the framework. For now, the point is narrower and more practical: the price of a new project is mostly paid by the projects you already have.

Why a busy system punishes new work so heavily

The reason the cost is so easily missed is that it does not scale in a straight line. It accelerates.

At low load, adding work is roughly free. If your specialists are genuinely at fifty percent, a new task slots in, gets done, and nothing else moves. This is the world most approval processes assume they are living in.

Past a certain point, that stops being true. Add work to a system that is already busy and it does not simply take longer to finish the new work. It takes longer to finish everything, because the new work now sits in a queue alongside the old, and every item waits behind the others.

This is not a failure of discipline or effort. It is a property of loaded systems, and it is well understood in queuing theory. As utilisation climbs toward one hundred percent, waiting time does not rise gently. It rises steeply, then vertically. The last ten percent of "available" capacity is where the delays are manufactured.

A useful picture is a motorway. Traffic flows freely at moderate density. Push the density higher and, past a tipping point, everyone slows down at once, even though no single car did anything wrong. Nobody caused the jam. The load did.

Your portfolio behaves the same way. A specialist reported at eighty percent is not eighty percent safe. They may already be on the steep part of the curve, close to slowing the whole portfolio down. The reported number tells you how full they are. It tells you almost nothing about what the next commitment will cost.

Delay is not neutral. It has a price.

If added work only meant a bit more waiting, you could shrug it off. It does not. Delay carries a cost, and that cost is the part organisations almost never put a number on.

Stephen Devaux gave us the cleanest way to think about this. He defines drag as the amount of time an activity adds to a project's completion, and drag cost as the value that delay destroys. If finishing a project a month later costs you a hundred thousand pounds in delayed revenue, forgone savings, or a missed market window, then a month of drag is worth a hundred thousand pounds. It is a real number, not a soft one.

Now hold those two ideas together.

A new project adds load to a busy system. That load delays the work already in flight. And that delay has a cost, because the value of finished work is time-sensitive. Value delivered in March is not the same as the identical value delivered in August.

So the true cost of saying yes is not just the cost of doing the new work. It is the cost of the new work plus the delay it imposes on everything else. That second term is usually invisible, always unbudgeted, and often larger than the first.

Put it in rough numbers. Suppose a new project promises two hundred thousand pounds of value. Suppose that adding it pushes three in-flight projects out by six weeks each, and each of those, delayed, quietly loses eighty thousand pounds of time-sensitive value. The new project still shows a clean two-hundred-thousand-pound case on its own page. The portfolio, taken as a whole, is worse off by forty thousand. You approved a loss and recorded it as a win, because the gain and the cost were written on different pages.

That gap between the two pages is the Execution Gap: the space between the strategy an organisation has chosen and what its constrained system can actually deliver. Most organisations try to close it with more effort. It closes with better decisions.

What organisations do instead, and why it makes things worse

When the in-flight work starts to slip, the instinct is to find the culprit.

Someone asks why the delayed projects are behind. The teams are asked to firm up their dates, to work a bit harder, to stop letting things drift. Pressure goes up. Sometimes a couple of contractors are brought in to help.

None of that removes the queue.

Pressure does not change the fact that too much work is chasing the same few people. It usually makes things worse, because chased teams start multitasking across everything at once, and switching between projects is one of the most reliable ways to slow all of them down. Adding people helps only if the new people can do the constrained work, which, for your genuinely scarce specialists, they usually cannot. You cannot hire your way out of a queue for the one person who is not replaceable.

The deeper problem is that all of this is happening after the fact. The system is trying to recover from a cost it accepted months earlier, at the approval meeting, when the true price was never put on the table.

The cheapest place to prevent overload is before the date is promised. Everything after that is damage control.

The better question to ask before you commit

The fix is not a tool and it is not a heroics culture. It is a change to the question you ask at the gate.

Stop asking: is this project worth doing? On its own terms, almost every project that reaches an approval meeting is worth doing. That question has no power to say no, which is exactly why portfolios silently overload.

Start asking three questions instead.

First, what does this new work draw on? Name the specific constrained people or capabilities it needs, not the team in general. The cost lives at the constraint, so that is where the analysis has to point.

Second, what is already in the queue for that same constraint, and what is that in-flight work worth if it finishes on time? You cannot price a delay to work you have not valued.

Third, is the value of the new project greater than the value it pushes back? If yes, take it, and take it deliberately. If no, you have just avoided approving a loss, and you can either decline it or make room by stopping something else first.

That last move, making room, is the one most organisations skip. A portfolio has a finite amount of constrained capacity. Adding to it without removing from it is not ambition. It is arithmetic that does not balance.

None of this requires more data than you already have. It requires looking at the whole system instead of one project at a time, and being willing to let the answer be no.

A project's business case tells you what it is worth. Only the portfolio tells you what it costs. This is where schedule becomes economics.

---