A plan with a 4% chance

Two weeks ago we built a network by hand. Twenty-five days. Clean logic, honest durations, a critical path you could defend in a meeting.

This week I ran that exact schedule twenty thousand times, letting each duration land anywhere in its realistic range.

It finished within 25 days in 4% of them.

The plan wasn't wrong. It was just never a promise.

This is the uncomfortable truth under every single-point schedule. Not that the numbers are bad — but that they are numbers, presented as if they were facts.

Here's how the arithmetic quietly turns against you.

Why every chain being "fine" isn't fine

Remember the handover milestone from Week 11 — the one with four chains feeding it? Structure, MEP, facade, lift.

Say each of those is in good shape. Genuinely. You'd put each one at 90% to land on time. Four healthy chains, four green reports.

FOUR “SAFE” CHAINS, ONE MILESTONE Structure 90% MEP first fix 90% Facade 90% Lift 90% HANDOVER 66% 0.9 × 0.9 × 0.9 × 0.9 = 0.66 Every chain looks safe. The milestone they all feed is a coin toss with extra steps.
Figure 1 — Merge bias. Four chains, each 90% likely, feeding one milestone. The probabilities multiply — and the milestone lands about two times in three.

The milestone needs all four. So the odds multiply: 0.9 × 0.9 × 0.9 × 0.9. About 66%.

Every chain is healthy. The milestone is a coin toss with better marketing.

This is merge bias, and it's why experienced project managers get an uneasy feeling about handover dates that the schedule insists are fine. The schedule shows you four green bars. It never shows you the multiplication.

And it gets worse the more paths converge. Six chains at 90% each? Just over half.

Twenty thousand versions of your project

So how do you actually see this? You stop asking the schedule for the answer and start asking it for all of them.

Give every activity a realistic range instead of one number — excavation is 4 days if the ground is kind, 5 normally, 9 if we hit rock. Then let the computer build the schedule thousands of times, each run picking a random duration from within each range, and record the finish date every time.

That's Monte Carlo. There's no magic in it. It's just running your project twenty thousand times before you run it once.

Stack up all those finish dates and you get this:

TWENTY THOUSAND VERSIONS OF YOUR PROJECT 0% 25% 50% 75% 100% 24d 26d 28d 30d 32d 34d 36d your plan: 4% coin flip commit here 7 days of contingency — calculated, not guessed The plan everyone signed finishes on time in one run out of a hundred.
Figure 2 — The S-curve. The same 25-day network, simulated 20,000 times. The signed plan lands on time in 4% of runs. An 80% confident commitment needs 32 days.

Read it once and you can't unsee it.

The 25-day plan — the one everybody signed — happens in about 4% of the runs. Half the time the job takes 29 days or more. To be genuinely confident, you need 32.

How did honest durations produce a plan that's almost impossible? Two reasons, and they're both structural. Delays are asymmetric — excavation can run 4 days early or 4 days late, but rock costs you far more than good ground saves you. And every place paths merge, the maths above eats your optimism.

Nobody lied. The plan just quietly assumed that nothing anywhere would go wrong.

Contingency you can actually defend

Look again at that curve, because it answers a question people usually settle with a shrug.

How much contingency do we need?

Not "add 10%, that feels about right." Not "the client will only accept 5%." The gap between the plan you built and the date you can stand behind: 25 days to 32 days. Seven days. Calculated.

That number is defensible in a way "10%" never is. When someone senior asks why you want seven days, you don't say "to be safe." You say: because at 25 days we succeed once in a hundred, and at 32 we succeed four times in five — and here is the curve.

Two kinds of reserve, and don't mix them. Contingency covers the things you know can happen — rock, rain, a late delivery. It belongs to the project, and the project manager spends it. Management reserve covers what nobody saw coming. It sits above the project, and it isn't yours to spend.

The float that lies

One more thing the simulation shows you, and it's my favourite.

Count how often each activity ends up on the critical path across all those runs. It's called the criticality index, and it doesn't always agree with your printout.

HOW OFTEN IS IT ACTUALLY CRITICAL? Excavate float 0 100% Erect steel float 0 100% Foundations float 0 83% Fabricate steel float 3 17% Deliver steel float 3 17% Backfill float 4 0% Steel fabrication shows 3 days of float on your printout. It runs the project in one simulation out of six. Watch it anyway.
Figure 3 — The criticality index. Steel fabrication carries 3 days of float in the deterministic plan — yet it controls the project in one simulation out of six.

Steel fabrication has three days of float. On paper, it's safe. You could ignore it for a month and nothing bad happens.

Except in the simulation it lands on the critical path 17% of the time — because its range is wide, and a bad supplier week eats those three days without noticing.

Your float number assumes everything runs to plan. The criticality index asks what happens when it doesn't. An activity with small float and a wide range is more dangerous than one with big float and a tight one — and the deterministic schedule cannot tell you the difference.

"Hope is not a strategy."

— ENGINEERING PROVERB

Often heard, rarely applied

And here's what this buys you, which is bigger than any curve.

When the client demands a date the simulation says you'll hit 20% of the time, you no longer have to argue with a feeling. You put the curve on the table. Then there are three grown-up conversations: give me the resources to crash it, cut the scope to fit, or sign that you accept a 20% chance — in writing.

Any of those three is a professional outcome. Nodding and hoping is not.

Practical insight

You don't need software to start. Take the ten activities on your critical path and ask the foreman for three numbers each: best day, normal day, bad day.

Two things will happen. You'll find activities where the bad case is triple the normal case — and those are your real risks, no matter what the float column says. And you'll see how much of your programme is resting on everything going right.

Then look at your next big milestone and count the chains feeding it. Multiply. That number is your actual confidence, and it's usually a shock.

Key takeaways

✔ A single-point schedule is a forecast pretending to be a fact.
✔ Merge bias: four chains at 90% each give a milestone about 66% — probabilities multiply.
✔ Monte Carlo runs your project thousands of times before you run it once.
✔ The S-curve tells you the odds of any date — including the one you already promised.
✔ Contingency is the gap between your plan and your commitment — calculate it, don't guess it.
✔ Contingency covers known risks and belongs to the project; management reserve doesn't.
✔ The criticality index exposes float that only exists if nothing goes wrong.
✔ A wide range with small float is more dangerous than a tight range with big float.

What's coming next

That's the schedule built: structured, logical, estimated, resourced, compressed, and now honest about its own uncertainty.

Everything so far has been about planning. From next week, the project starts — and the schedule stops being a plan and becomes an instrument. We move into keeping the model alive: progress updates, the data date, out-of-sequence work, and the discipline of maintaining a schedule that still tells the truth in month eighteen.

Building the model was the easy part. Now we keep it honest.

Enjoyed this lesson?

Join with Google to get each new lesson the moment it's published — and help me see which topics matter most to you. No spam, one email a week, unsubscribe anytime.