A senior leader is offered a new project.
Most project selection processes score the opportunity on its own merits: revenue, strategic fit, team availability. That is normal, and it is not wrong as far as it goes. What it leaves out is what Flow Economics calls the Price of Yes: the cost a new commitment lands on the work already in flight, which never shows up on the new project's own business case. This piece prices that cost.
Project selection normally scores a new opportunity on its own merits: revenue, strategic fit, team availability. Flow Economics calls the missing half the Price of Yes, the cost a new commitment lands on work already in flight. That cost never appears on the new project's own business case, because it is paid by the projects it delays.
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 80%, so there looks to be room. The project is approved.
On paper, this is good management, a fast piece of project selection. 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 organizations, and almost nobody prices it. This piece is about how to.
Why doesn't project selection catch the real cost of a new project?
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 50%, 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 utilization climbs toward 100%, waiting time does not rise gently. It rises steeply, then vertically. The last 10% 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 80% is not 80% 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 organizations 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 $100,000 in delayed revenue, forgone savings, or a missed market window, then a month of drag is worth $100,000. 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 $200,000 of value. Suppose that adding it pushes 3 in-flight projects out by 6 weeks each, and each of those, delayed, loses $80,000 of time-sensitive value. The new project still shows a clean 200,000-dollar case on its own page. The portfolio, taken as a whole, is worse off by 40,000. 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 organization has chosen and what its constrained system can actually deliver. Most organizations try to close it with more effort. It closes with better decisions.
What organizations 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.
What should project selection ask before saying yes?
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 organizations 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.
| Question | What it checks |
|---|---|
| What does the new work draw on? | Names the specific constrained people or capability it needs |
| What is already in that queue? | Values the in-flight work it would push back |
| Is the new value greater than the value it displaces? | Decides whether to take it, decline it, or free capacity first |
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.
---
Flow Economics is the discipline of understanding how value actually moves through an organization when its resources are constrained, and of making decisions that maximize what the whole system delivers rather than what each project looks like on its own. If the way you approve work is closer to the first than the second, the Flow Economics framework is a good place to see the full picture.
Leave a Reply