22 May 2026
The Restaurant Problem: Why Your Initiative Won't Land on Time
Your initiative has ten dependencies. Here are the odds of it finishing without delay:
0.1%
Let me explain with a simple analogy.
The restaurant
You’re meeting friends at a restaurant. You can’t be seated until everyone arrives.
- Waiting for 1 friend: 50% chance of no delay
- Waiting for 2: 25%
- Waiting for 5: 3%
- Waiting for 10: 0.1%
Every dependency doubles the chance of delay.
Now look at your biggest initiative. Count the dependencies — every team, every system, every handoff that needs to land before your thing can ship.
In one portfolio review, we found critical deliverables bundled with 15+ dependencies. On paper, they looked perfectly achievable. The maths said less than a 1% chance of landing without delay.
Those teams weren’t failing because of lack of talent or effort. They were failing because the odds were stacked against them before the work even began.
The maths is a simplification — and it doesn’t matter
Yes, this assumes each dependency has an independent 50% chance of causing delay. In reality, some dependencies are nearly certain and some are correlated. Adjust the base probability to 30% chance of delay per dependency and ten of them still gives you less than a 3% chance of no delay.
The simplification understates the problem for unreliable dependencies and slightly overstates it for reliable ones. But the directional insight — that dependencies multiply risk exponentially, not linearly — holds regardless. And that’s the bit most teams don’t intuitively grasp.
Why we don’t see it
Nobody counts. I’ve sat in dozens of planning sessions where initiatives were approved with twenty, thirty, even forty dependencies. Nobody calculated the probability. The plan looked reasonable. Each individual dependency seemed manageable. But the compound probability was essentially zero.
Teams weren’t failing because they were bad at execution. They were failing because the structure of the work made success almost impossible. And then they got blamed for “not delivering.”
What to do about it
Three things:
-
Count your dependencies. Just the act of writing them down changes the conversation. When a stakeholder can see that their initiative has a 0.1% chance of landing without delay, they engage differently.
-
Sequence rather than parallelise. Do dependent items in series instead of hoping they’ll all land at the same time. It feels slower but it’s dramatically more reliable.
-
Reduce the batch size. Break big dependent items into smaller ones that can complete independently. This is also why MVP and regular releases work so well — they naturally limit dependencies per release, so the probability maths works in your favour instead of against you.
The restaurant analogy comes from a conversation with my business partner Kieran Neeson. I was grumbling about organising a family meal for fourteen people. He showed me the maths. I stared at it and realised: that’s not a restaurant problem. That’s every initiative I’ve ever watched miss its deadline.
How many dependencies does your most important initiative have right now?
Seeing this in your organisation?
I help teams and leaders surface the behavioural signals that predict delivery problems before they hit the dashboard — through fractional CTO work, behavioural consultancy, and the IMIRT framework.
If something here resonated, I'd like to hear about it.
andrew@andrewlocatelliwoodcock.com