Range-based scheduling: a realistic alternative to CPM

Walk onto a site and ask an experienced site manager when you'll be closed in. He answers in three seconds, without opening anything. "End of October." And he's usually right — not by luck, but because thirty sites have taught him what this one is going to do. Then you open the schedule. It says 11 December. Everyone in the room trusts the man, not the file.

That gap isn't a planning failure. It's what happens when the best information on a project has nowhere to go.

CPM doesn't guess. That's exactly the point.

Ask any planner why they use CPM — the Critical Path Method — and you'll get a good answer: because a date should be calculated, not felt. Durations and dependencies go in, the finish date comes out, and you can trace exactly which chain of work produced it. That's a real ambition, and Primavera and MS Project are excellent at delivering it. Nobody should pretend otherwise.

But the calculation is only worth as much as the network underneath it. And a network that genuinely earns the computation needs a level of detail that a mid-sized site cannot reach — and, more importantly, cannot maintain. The sequence changes weekly. A subcontractor swaps two floors around. A delivery slips and three trades reshuffle themselves without asking anyone.

So the planner simplifies. He has to. Activities get aggregated, durations get rounded, links that would take a full day each to establish properly get dropped or approximated. Every one of those decisions is reasonable on its own. Together, they hollow out the mechanism. At some point the network stops describing how the work actually depends on itself and becomes a container for round numbers — while the computation runs on, perfectly, over something that no longer represents the site.

Below a certain level of detail, the calculation isn't a computation any more. It's a guess wearing a suit.

This is why CPM works beautifully on very large projects and struggles on mid-sized ones. Not because the method is weaker — because the conditions are different. A €400M project can afford the planning team, the detail and the discipline to keep the network honest. A €15M residential project can't, and never will. That isn't a maturity gap that better software or more training closes. It's an economics gap. CPM isn't wrong. It's out of range.

The best estimate on your site has no way in

There's a second problem, and it's structural rather than economic.

CPM computes an end date. It cannot be told one. The traffic runs one way: durations and links in, date out. So when the site manager says end of October and the network says 11 December, there is no legitimate slot for his judgment to enter through.

What happens next is familiar to everyone who has maintained a schedule. The planner works backwards. He trims durations, overlaps activities, adds or removes links until the computation lands on the number everyone already believes. It usually takes an afternoon.

Two things break at once. The network now holds durations nobody accepts and links that exist only to force a result. And the expert judgment — the single most reliable input on the project — has been laundered into a shape that hides where it came from. Six weeks later, when someone asks why the date is end of October, the answer isn't in the file. It's in a man's head, unrecorded.

What range-based scheduling actually is

The alternative starts from a different premise: if the honest answer is a window, store a window.

A range-based schedule works on the key activities of the project — a dozen or so, not four hundred — and gives each one three scenarios instead of one pair of dates. Foundations, for example:

• Optimistic — 3 October to 15 December
• Most likely — 3 October to 4 January
• Pessimistic — 10 October to 25 January

The start moves too, not just the finish. If things go badly you don't begin on time either — whatever holds up the start usually stretches the work as well.

A milestone is the same object with no duration: three dates instead of three ranges. Closing in, handover, the client's first visit. Same logic, shorter shape.

And all three scenarios are true. They simply carry different amounts of uncertainty. That matters, because the first thing anyone asks is "so which one is the real one?" — and the answer is that the question is wrong. You communicate differently depending on who's in front of you, without ever picking one number and hiding the other two.

They aren't padding. Padding buries uncertainty inside a duration and then presents the output as exact. Three scenarios state the uncertainty out loud, where everyone can see it and argue about it.

Note what isn't there: a dependency network. That's the real difference — not the word "activity", but the fact that a dozen key activities are something a site manager already holds in his head, while hundreds of linked lines are something nobody can maintain. He produces the first in ten minutes and reads it in ten seconds. That alone decides whether a schedule survives contact with a real project.

As the site advances, the three scenarios narrow and converge. Early on they sit far apart — correctly, because a lot is still open, and the distance between optimistic and pessimistic is itself information about how much. Three weeks out, they've collapsed onto each other. A single computed date can never express that.

It isn't PERT, and it isn't QSRA

Anyone with scheduling background will ask, and the distinction matters.

PERT (Program Evaluation and Review Technique) and QSRA (Quantitative Schedule Risk Analysis) aren't alternatives to CPM — they're layers on top of it. They take the activity network, attach uncertainty and risk to its durations, and run Monte Carlo simulations across it. The output looks like a range, but it's a range derived from the network. Remove the network and there's nothing left to simulate.

Which means every distortion in the network propagates upward, now wearing a confidence percentage. Simulate the durations that were reverse-engineered to hit end of October, and you get a very respectable P80 on a fiction. The maths is sound. The input was laundered.

And critically: it still can't accept the site manager's call. It can only vary what's already inside the network. The best estimate on the project is still locked outside — now one layer further from the surface.

A range doesn't sit on anything. It can be stated, held, attributed and revised without a single dependency link existing anywhere.

An estimate nobody asked twice

Here's the part that gets overlooked: the veteran's call was excellent — and made once, in week 3.

Nobody asks him again in week 14. If they did, his updated answer would be just as good. But there's no moment in the process that prompts the question, and no place to put the answer if he gave it.

And this isn't about missing expertise. Mid-sized sites often do have a planner — rarely full-time, but genuinely skilled. That makes the point stronger, not weaker. The problem isn't the person. It's that the update cycle is structurally slower than the site: a skilled planner working two days a month still hands you last month's picture on a Tuesday morning when you need to decide something today.

Re-evaluated from what your site is already saying

Your site produces the signal already. A photo of a slab poured a day early. A message that the façade subcontractor is two men short this week. A delivery confirmation. A snag in apartment 304 that quietly puts the finishing works under pressure.

Under CPM, that information reaches the schedule weeks later, if it reaches it at all. Biilby reads it as it arrives and continuously re-evaluates the remaining probability on each key activity — from the same reporting people are already doing, with no new data entry to impose on anyone. It's the same single message feeding several systems at once that we described in an earlier post.

Biilby proposes. You decide.

When the picture moves, Biilby doesn't move your schedule. It puts a revised window in front of you:

Biilby: The façade is running two men short for the second week. Closing-in most likely now 22–29 October, pessimistic 31 October–7 November. Update?

You accept it. Or you adjust it. Or you ignore it entirely and make your own fresh call — because you spoke to the subcontractor this morning and you know something the messages don't say. Your call becomes the new position, recorded as yours.

That's the difference between a schedule you can live with and one you fight. The judgment stays with the people who have it. Biilby's job is to bring the right question at the right moment and do the arithmetic around it — the same deliberate line we draw everywhere else in the product.

Three scenarios, three honest readings

Because all three are true, one dataset can be read three ways without anyone lying.

Your client sees the pessimistic scenario — the commitment. Your teams work against the optimistic one — the target. The most likely scenario is the shared reality both sides actually plan around.

Today those numbers live in two separate documents that quietly contradict each other, and everyone involved knows it and says nothing. Ranges make them one artifact with three faces. Nobody is misled, and nobody is surprised at handover.

Keep the history. Keep the story.

Formal baseline change management on a mid-sized project is theatre nobody has the hours to perform. So it doesn't get performed — and the schedule drifts with no record of why.

The answer isn't more procedure. It's keeping the story. Every revision recorded, attributed and explained: the October call came from the site manager in week 3, revised in week 11 after the façade delay, revised again in week 19 when the lift order was confirmed. You can trace how the project got where it is, and so can your client.

That's only possible because the estimate entered the system as itself, from a named person, on a known date. A judgment reverse-engineered into durations has nowhere to leave a signature.

Back to the man on site

He was right in week 3. He'd be right in week 14 too, if anyone asked him.

The point was never to replace his judgment with a better algorithm. It's that the schedule finally has a shape that can hold it — and keep holding it, week after week, as the site moves underneath.

Want to see what that looks like on a project like yours? Get a demo.