The Dependency Tax: Why Connecting Two Projects Costs More Than Either One

Almost every portfolio has a project that was basically done for a surprisingly long time.

The build was finished. The team had moved on in spirit, if not on the timesheet. And yet the thing would not ship, because it was waiting: on a data feed from another project, on a shared platform team to cut a release, on a security review sitting in someone else's queue, on a decision that three other initiatives also needed. The work was complete. The connection was not.

We report a project like that as "ninety percent done, one dependency outstanding", as if the last tenth were a rounding error. It is almost never a rounding error. It is frequently where most of the calendar time, and most of the pain, actually lives.

This piece is about the thing that lives in that gap. Not the tasks, which every plan tracks obsessively, but the seams between them: the dependencies, handoffs and integration points where one stream of work has to wait for another. In a single project you can mostly manage the seams by hand. In a portfolio of projects competing for shared resources, the seams follow an economics of their own, and it is punishing in ways no individual project plan can see.

I am going to call that economics the dependency tax: the systematic, compounding and almost universally underpriced cost of connecting work that could have been kept apart.

Why a dependency does not look like it costs anything

Open any project plan and find a dependency. It is an arrow. Box A finishes, arrow, Box B starts. It consumes no budget line. It shows up as zero duration. Nobody is assigned to it. On the plan, connecting two pieces of work is the cheapest thing in the building. It is literally free to draw.

This is the first trap, and it is the same shape as the trap in The Utilisation Trap: the thing that is cheap and visible gets managed, and the thing that is expensive and invisible gets ignored, precisely because it is invisible.

Because here is what a dependency actually is. It is not an arrow. It is a synchronisation requirement: a promise that two independent streams of work, each with its own uncertainty, its own team and its own queue, will arrive at a shared point at the same time. And synchronisation, the act of making separate uncertain things line up, has a cost structure that human intuition gets consistently and badly wrong.

That cost structure has three parts. Take them one at a time.

Mechanism one: the tyranny of the last arrival

Start with the mechanism that does the most damage and gets the least attention.

When several streams of work must converge before the next thing can happen, three feeds into one integration, four workstreams into one launch, the convergence cannot start when the first one arrives, or the average one. It starts when the last one arrives. An integration point is a logical AND: every input must be present. Being early on four of five feeds buys you exactly nothing if the fifth is late.

This sounds obvious. Its consequences are not, because of what it does to the arithmetic of "on time".

Suppose you plan each feeding stream honestly, to a realistic estimate: the kind of estimate that has a genuine fifty-fifty chance of coming in on the date. One stream on its own has even odds of being ready by the target. Fine. Now converge several such streams, each independently planned the same honest way, and ask the only question the integration actually cares about: what is the chance that all of them are ready at once? You multiply the odds together, and they fall off a cliff.

• Two feeders: a half times a half, so roughly a 25% chance the convergence is on time.
• Three feeders: about 12%.
• Four feeders: about 6%.
• Five feeders: about 3%.

Read the bottom line. An integration point fed by five independently, honestly planned streams has roughly a 1-in-32 chance of not waiting on a straggler. Not because anyone estimated badly. Not because anyone slacked. Every single feeder was planned to a fair, realistic date, and the convergence is still late almost every time, because "on time" at a merge means everyone on time, and the odds of that collapse geometrically with the number of things being merged. The clean arithmetic assumes the feeders are independent; real streams are often correlated through shared resources and common causes, which shifts the exact odds. The mechanism survives either way: the merge waits for its last arrival.

Statisticians call this merge bias: the completion time of a convergence is governed by the maximum of its inputs, and the expected maximum of several uncertain durations is always later than any single expected duration, further out the more inputs you add. It is the same effect the critical-chain view of a single project warns about at the task level in Your Estimates Are Padded, and Your Projects Are Still Late. What almost nobody does is carry it up to the portfolio, where the streams being merged are whole projects owned by different people, and where the bias is therefore both larger and completely unowned.

Picture four feeding streams, each finishing on its own day, scattered across a fortnight. Every team points at its own finish and reports "on plan". The integration does not land on the average of those days, or the earliest. It lands on the very last one, every time. The gap between "the average feeder was on time" and "the integration was on time" is pure merge bias, and it is charged to whoever owns the seam, which, in most organisations, is nobody.

Mechanism two: dependencies turn independent risk into shared risk

The second mechanism is quieter and, over a whole portfolio, arguably worse.

Two unconnected projects carry independent risk. If Project A slips, Project B is unaffected; the portfolio has, in effect, diversified. One can have a bad month while the other has a good one, and the damage does not spread. This is the same reason a spread of investments is safer than a single bet: uncorrelated risks partly cancel out.

The moment you draw a dependency from A to B, you destroy that diversification. B now inherits every source of delay that A carries, on top of its own. A's staffing problem is now B's staffing problem. A's scope creep is now B's slipped launch. You have taken two independent uncertainties and wired them in series, and risks in series add up instead of cancelling. Push dependencies through a whole portfolio and you get chains: A feeds B feeds C feeds the launch, and the launch now carries the accumulated wobble of everything upstream of it, whether or not the launch team ever knew those upstream projects existed.

This is why a portfolio can feel far more fragile than the state of any individual project would suggest. Every project is green, yet the whole thing lurches, because the dependencies have coupled the projects into one large correlated system. A single upstream problem no longer stays local. It radiates along every arrow leading out of it. A dependency is a decision to stop diversifying a risk. Almost no one makes that decision on purpose, or prices it when they do.

Mechanism three: the queue you cannot see because it lives between plans

The third mechanism is where the dependency tax meets everything else in flow economics.

A cross-project dependency is, at bottom, a handoff: work leaves one team's world and needs something from another team's world. And a handoff to a shared team is a request that joins that team's queue. If the platform group, the data team, the security reviewers, whoever sits on the other end of your arrow, are busy, and by The Utilisation Trap the more "efficient" they look the busier they are, then your request does not get served on arrival. It waits.

Here is what makes this queue uniquely dangerous: it appears on neither project's plan. Your project's plan shows your work. Their project's plan shows their work. The waiting your request does in their queue is a real, often multi-week stretch of pure calendar time that exists in the space between the two plans, which is to say, in no plan at all. It is invisible for the same structural reason the whole corpus keeps returning to: single-project tools follow the worker, not the work item. Trace a work item across a seam and you find it sitting in a queue nobody is looking at. This is exactly the mechanism behind the routinely single-digit flow efficiency described in The Efficiency Paradox: most of a dependency's life is spent waiting to be picked up, on the far side of a boundary neither side owns.

So a single dependency can carry all three taxes at once: it waits in an invisible queue, it couples your fate to the upstream team's, and if it is one of several feeds into a convergence, it drags the whole merge to the last arrival. The arrow that looked free is doing all of this.

A worked example

Numbers make the tax concrete.

Take a launch that integrates four workstreams: a product build, a data migration, a partner integration and a compliance sign-off. Each is run by a competent team. Each is planned to an honest, realistic date, a genuine coin-flip chance of hitting it.

The plan's implicit claim is simple. Every stream is on track, so leadership reads the launch as on track. Four green lights, one launch date.

Merge bias says otherwise. The launch fires only when all four arrive, and the probability all four hit their date is a half to the fourth power, about 6%. So there is roughly a 94% chance the launch waits on a straggler, even though every individual plan was reasonable. The launch date on the slide is not a forecast. It is close to a best case with a 1-in-16 chance of happening.

Now add the queue. Two of those streams, the data migration and the compliance sign-off, depend on shared teams that also serve the rest of the portfolio and run hot. When each request lands, it waits three weeks in a queue that appears on no plan before real work even starts. That three weeks is in nobody's estimate. It lives in the seam.

Now add coupling. The partner integration slips a fortnight for a reason entirely outside your organisation. Because it feeds the merge, that fortnight is not absorbed locally. It becomes two weeks on the launch, and on everything the launch was going to free up capacity for next.

Nothing here is a failure of execution. Every team did roughly what it said it would. The launch is still comfortably a month or more later than the plan implied, and every week of that slip carries its cost of delay, multiplied across whatever the launch was gating. That month did not come from any task. It came from the seams between the tasks, precisely the place no one was managing, because on the plan the seams were free.

That is the dependency tax, in one arithmetic.

Why single-project management is structurally blind to this

If the effect is this large, why does nearly every organisation walk into it?

For the same reason cost accounting walks organisations into the utilisation trap: the discipline that governs the decision cannot see the cost the decision creates.

Project management, as practised, is organised around the individual project. Each project has a plan, an owner, a status, a baseline. Within that frame a dependency is an external fact, an input you are waiting on or an output you owe, and the frame's job is to track your project against its baseline, not to price what the connection costs the system. Every project can therefore be run impeccably, each defending its own plan, while the merge bias, the coupled risk and the inter-plan queues accumulate in the spaces between the projects, which is to say in the one place the project-level frame has no way to look.

This is the Project Illusion again, in its purest form: the belief that if every project is individually well run, the portfolio must be healthy. Dependencies are the sharpest counterexample there is. You can have a portfolio of uniformly green, competently managed projects that reliably delivers late, and the entire discrepancy can live in the seams. Portfolio performance is not the sum of the projects. It is the projects plus the cost of everything wired between them, and that second term is the one nobody budgets.

Flow economics insists on making the second term visible. A dependency is not free infrastructure. It is a liability with a running cost, and like any liability it should be counted, priced and, wherever the value does not justify it, retired.

What to manage instead

You cannot eliminate dependencies; real value usually requires combining things. The goal is not zero connections. It is to stop treating connections as free, and to manage the seams as deliberately as you manage the tasks. A handful of levers do most of the work.

1. Count your seams. Dependency density is a portfolio metric. You almost certainly track how many projects are in flight. You almost certainly do not track how many dependencies are in flight, yet that number predicts fragility far better. Count the cross-project and cross-team dependencies in your portfolio. Watch the convergence points where many feeds meet, because those are where slip is manufactured. A high dependency count on a launch is a risk signal you can read before anything goes red, unlike a status colour, which by The Watermelon Report tells you only after.

2. Reduce the number of feeds into any one convergence. Because on-time probability falls as roughly a half to the power of the number of feeders, every feed you can remove from a merge improves the odds geometrically, not linearly. Two feeders into a launch instead of five is not a bit safer. It is the difference between one-in-four and one-in-thirty-two odds of a clean landing. Prefer a few well-defined interfaces over many fine-grained ones. Sequence work so that fewer things have to arrive at the same instant.

3. Resolve dependencies before you start, not during. A project released before the things it depends on are in place does not progress. It stalls at the first seam and waits, holding resources while it does. This is the portfolio-level case for Full Kit: the right time to start work is when its dependencies can actually be satisfied, so the seams are crossed by design instead of discovered under pressure. Front-load the risky convergences; retire the scary dependency first, while there is still room to react.

4. Decouple deliberately. A stable interface is an economic asset. The most powerful move is to make the dependency not need to be synchronised in real time. A stable, versioned interface; a documented contract; a small buffer of ready output that the downstream team can draw on without waiting for the upstream team's next release. Each of these converts a live synchronisation, expensive by all three mechanisms, into a loose coupling that is cheap. Architectural decoupling is not a technical nicety. It is the act of not paying the dependency tax, and it is worth real investment to achieve.

5. Buffer the integration point, not each feeder. Padding every feeding stream is the estimation mistake all over again: the safety gets consumed locally and protects nothing at the merge. Instead, protect the convergence with a shared feeding buffer sized for the merge bias, exactly as critical-chain thinking protects a project's finish. One pooled buffer at the seam beats safety scattered across the feeds, for the same statistical reason pooling always beats padding.

6. When a dependency crosses to a shared team, treat it as joining a queue, and manage that queue. A handoff to a busy shared resource inherits that resource's queue and its utilisation curve. If you must depend on the platform team, the constraint of their schedule now sets your date. Make that queue visible, give the shared team protective capacity so requests do not wait behind a near-vertical wall, and prioritise the queue by portfolio value rather than by who shouted last.

The objection you are already forming

"Dependencies are just reality. Everything depends on everything. Are you telling me to break my systems apart to avoid an arrow on a chart?"

No. The reframe is this: the arrow was never free, and pretending it is has been setting your delivery dates all along. You are not choosing between connected and disconnected work; much of the value only exists because things are connected. You are choosing between dependencies you have counted, priced, sequenced and buffered, and dependencies you have left invisible to fend for themselves in the seams. The first kind is a managed liability. The second kind is where your portfolio is silently late.

Every mature flow discipline has, in its own language, arrived at the same conclusion: the hard part is never the boxes, it is the lines between them. Lean obsesses over handoffs. Critical chain buffers the merge, not the task. Modern software architecture spends enormous effort on decoupling for exactly this reason. They are all paying down the same tax.

Stop reading a plan as a set of tasks with some free arrows between them. Start reading it as a set of tasks plus a set of synchronisation requirements, each of which forces a wait on the slowest contributor and couples risks that used to be independent. The tasks are where the work is. The seams are where the time goes. The first is what your plan shows you. The second is what your plan is costing you.

This is a foundations piece in the Flow Economics series. If it changed how you read the arrows on your own plan, the natural next questions are which of your dependencies actually cross your constraint, taken up in How to Find the One Resource That Sets Your Delivery Speed, and what a week of delay at that seam is really worth. Those are the threads that connect this piece to the rest of the series.