Estimation: Ranges, Not False Precision

Breaking Work Down and Building a Plan turned a vague goal into a list of concrete tasks with a shape. Now someone asks the question every plan eventually faces: how long will it take? Or how much will it cost? You feel the pull to answer with a single confident number — “three weeks,” “forty thousand dollars” — because that is what people seem to want.

This page argues that the confident single number is usually the least honest answer you can give. Estimation is guessing about a future you cannot see, and the future is genuinely uncertain. The skilled move is not to guess better and pretend the guess is a fact. It is to be honest about the uncertainty: give a range, buffer for the unknown, lean on what actually happened last time, and hand over your assumptions along with your number so it can be corrected as reality unfolds.

Why estimation is genuinely hard

Start with the plain truth people skip over: an estimate is a prediction about work that has not been done yet. If the work had been done, you would not be estimating — you would be reporting. So estimation is inherently a statement about the unknown, and the unknown does not cooperate.

Two things make it harder than it looks.

First, most non-trivial work contains things you cannot see from the starting line. The task list from the previous page is your best current picture, but it is a picture of what you know about. The delayed supplier, the requirement that turns out to mean something different, the person who gets sick during the crucial week, the “quick fix” that unearths a deeper problem — these live in the gap between your list and reality. Nobody put them on the plan because nobody knew they existed yet.

Second, and more insidious, we are systematically over-optimistic about our own plans. This is not occasional carelessness; it is a reliable, well-documented pattern. When you imagine a task, you picture it going smoothly — the version where everything connects and nothing interrupts. You rarely picture the interruptions, because interruptions are, by nature, unimagined. So your mental estimate is really an estimate of the best case, quietly mislabeled as the expected case.

The evidence — the planning fallacy

Researchers Daniel Kahneman and Amos Tversky named this the planning fallacy: the tendency to underestimate how long our own tasks will take, even when we have plenty of experience with similar tasks running long. Studies across student projects, home renovations, and large public works generally find the same lopsided pattern — real durations land at or beyond the optimistic estimate far more often than they beat it. The striking part is that experience does not cure it. You can miss the same kind of deadline ten times and still feel confident about the eleventh, because each time it feels like this one will be the clean one. The fallacy is baked into how we imagine the future, not into how careful we are.

The consequence is worth stating bluntly: your gut estimate is not a neutral guess that might be high or low. It leans low, on purpose, without asking you. Any honest estimation habit has to correct for a thumb that is already on the scale.

There is a third force worth naming, because it comes from outside your own head. The person asking often signals the answer they want. “This is pretty quick, right?” or “We really need this by month-end” is not a neutral request for information — it is a nudge, and under that nudge estimates shrink. A good estimator learns to notice the pull and separate the honest guess from the hoped-for one. The question “how long will it take?” and the question “how long do you wish it would take?” have different answers, and the whole value of an estimate collapses if you quietly answer the second while pretending you answered the first.

Ranges beat single numbers

A single number carries a hidden lie. When you say “three weeks,” you imply you know it is three weeks — not two, not five. But you don’t. The reality is a spread of possibilities: it could go fast, it could go slow, and the most likely outcome sits somewhere in a band. Collapsing that band into one number throws away the most useful information you have, which is how uncertain you are.

So the first upgrade is simple: estimate in ranges, not points.

  Instead of:  "It'll take three weeks."

  Say:         "Likely two to four weeks. Best case if nothing
               goes wrong, a bit under two. If the vendor is slow
               or the data's messy, it could stretch to five."

The range does two jobs at once. It gives the listener a realistic picture, and it tells them how confident you are. A tight range (“nine to eleven days”) signals “I’ve done this many times and I know it well.” A wide range (“one to four months”) signals “there’s a lot I can’t see yet” — which is a true and important thing to say out loud, not a weakness to hide.

Confidence bands make the uncertainty explicit

A useful refinement is to attach rough confidence to the ends of the range. You are not doing statistics; you are being honest about likelihood.

  Task: migrate the customer records to the new system

  90% confident it's done within .......... 6 weeks   (my "safe" number)
  Most likely ............................. 4 weeks   (if it goes normally)
  10% chance it's done as fast as ......... 2.5 weeks (everything lines up)

Now the person receiving the estimate can choose which number to plan around based on how much risk they can tolerate. Promising a customer? Use the safe end. Sketching a rough internal timeline? The middle is fine. The single-number habit forces everyone to plan around the same figure whether or not it fits their situation. The range hands the judgment back to the people who have to live with the consequences.

In practice — the range that survived contact

A cafe owner planning a second location was asked by her bank “when will it be open?” Her instinct was to say a date — “March” — because a date is what forms want. Instead she gave a band: “Most likely April, as early as March if the fit-out and permits go smoothly, as late as June if inspections lag.” The bank, far from seeing weakness, tightened her loan terms to match the realistic window. When the health inspection did slip by five weeks, there was no crisis conversation — June had been on the table from day one. A neighboring owner who had promised a single hard date to his landlord spent that same slip apologizing and renegotiating. Same delay, two completely different experiences — decided entirely by whether the uncertainty had been named up front.

The common trap — precision that pretends to be accuracy

“The project will cost $47,320” feels more trustworthy than “roughly forty to sixty thousand.” It shouldn’t. Precision is how exact a number looks; accuracy is how close it is to the truth. A number can be extremely precise and completely wrong. When an estimate is decorated with false precision — exact dates months away, budgets to the dollar — it signals rigor it does not have, and it invites everyone downstream to treat a guess as a commitment. The honest range looks less impressive and is far more useful. Be suspicious of any estimate more precise than the thing being estimated could possibly justify.

Honest buffering versus hidden padding

Because you know things will go wrong that you cannot yet name, a good estimate includes room for the unknown. This is buffering, and it is not cheating — it is accuracy. The mistake is to estimate only the work you can see and then act shocked when the invisible work shows up. A buffer is your acknowledgment that the invisible work is real even though you can’t itemize it.

But there is a version of this that quietly poisons trust, and the difference matters enormously.

• Honest buffering is visible and explained. “The tasks add up to four weeks. I’m adding two weeks of buffer because integrations with that vendor have always thrown surprises. So: six weeks.” Everyone can see the buffer, see the reason, and challenge it if they think it’s wrong.
• Hidden padding is a buffer smuggled inside the numbers. You privately think it’s four weeks, you’re afraid of being held to it, so you say “eight” and pocket the difference as insurance. Nobody knows the padding is there.

The two look similar from the outside and are worlds apart in effect. Hidden padding feels safe in the moment, but it corrodes everything. When people sense that your numbers are inflated, they discount them — cutting your eight back to five, which is now worse than the honest four-plus-two you could have given. Padding also hides the real risk: the reason you needed slack (the flaky vendor) never gets discussed, so it never gets fixed. And it teaches the whole team that estimates are a negotiation to be gamed rather than information to be trusted.

In practice — the padding spiral

A ward manager, tired of being pushed to promise faster staffing rota changes, started padding her estimates: a two-day change became “a week.” Her director, who had learned she padded, began automatically halving her numbers. So she padded more to compensate. Within a few months neither of them believed any timeline either one said, and every schedule was a silent tug-of-war between inflation and discounting. The fix was not better numbers — it was one honest conversation: “Here’s the real estimate, here’s the buffer, and here’s why.” Once the buffer was on the table instead of under it, the halving stopped and the numbers started meaning something again.

The rule of thumb: buffer generously, but never secretly. A buffer you can defend in daylight builds trust. A buffer you have to hide destroys it.

Use past actuals, not hopeful guesses

The single most powerful correction for over-optimism is embarrassingly simple: look at how long this kind of thing actually took before. Kahneman called this taking the outside view — instead of imagining your specific task from the inside (where it always looks clean), you step outside and ask, “How long do tasks like this one usually take, for people like us?”

The inside view says, “This report is straightforward, I’ll have it Friday.” The outside view says, “The last four reports I called straightforward each took about ten days. This is probably a ten-day report.” The outside view feels pessimistic. It is usually just accurate — it has quietly absorbed all the interruptions you keep forgetting to imagine, because those interruptions are already baked into the historical record.

This is why keeping a record of actuals — how long things really took, not how long you predicted — is one of the highest-leverage habits a team can build. You don’t need a fancy system. A running note of “task type → estimated → actual” turns your own history into a correction factor.

  Task type            Estimated    Actual     Ratio
  ------------------    ---------    ------     -----
  New report build       5 days      9 days     1.8x
  Vendor integration     2 weeks     5 weeks    2.5x
  Small config change     1 day     1.5 days    1.5x

  Lesson: our reports run ~1.8x, our integrations run ~2.5x.
  Next integration estimate? Take the honest guess and multiply.

That ratio column is gold. It doesn’t tell you to guess better; it tells you by how much your guesses are wrong, which is a far easier thing to fix. If your integrations reliably take 2.5 times your first instinct, you stop arguing with your instinct and start multiplying it.

Notice too that the outside view protects you from a subtle version of the planning fallacy: decomposition doesn’t cure optimism. Breaking a project into twenty small tasks and estimating each feels rigorous, but if every one of those small estimates leans optimistic — and they will — the errors don’t cancel, they stack. Twenty tasks each a day short is twenty days short. The historical ratio catches this because it was measured on whole real efforts, interruptions and all, not on a tidy sum of imagined pieces. Use the detailed breakdown to understand the work; use the outside-view ratio to sanity-check the total.

Case study — the Sydney Opera House

The Sydney Opera House was estimated in 1957 to cost about 7 million Australian pounds and open in 1963. It opened in 1973 — a decade late — and cost on the order of 100 million, more than ten times the original figure. Much of the overrun came from starting construction before the design was settled, so the “estimate” was really a hope attached to a building nobody yet knew how to build. The lesson is not that the planners were foolish; it is that a confident number produced under deep uncertainty is a confident fiction. When you genuinely cannot see the work — as with a novel design — the honest output is a wide range and a plan to re-estimate as the unknowns resolve, not a single number that will be quoted against you for fifty years. (Treat the exact figures as illustrative; the shape of the miss is the point.)

Communicate the estimate with its assumptions

An estimate without its assumptions is a number with no handle — you can’t grip it, and you can’t update it. Every estimate secretly rests on a set of if-thens: it will take four weeks if the vendor responds within two days, if the data is as clean as the sample, if we don’t lose Priya to the other project. Those conditions are the load-bearing structure. When you state the number and swallow the conditions, you hand over something that looks solid and is actually resting on assumptions nobody can check.

So attach the assumptions to the number, explicitly:

  Estimate: 4 to 6 weeks.

  Assumes:
    - Vendor turns around access requests in ~2 days
    - The full dataset is as clean as the sample we saw
    - Priya stays on this and isn't pulled to the launch
    - Scope stays as agreed on Tuesday — no new regions added

  If any of these breaks, the estimate changes — tell me early
  and I'll re-estimate rather than silently miss.

This turns a dead number into a living one. If the vendor goes quiet on day one, everyone already knows the timeline is at risk — no awkward surprise at the deadline, because the trigger was named in advance. Assumptions also protect you fairly: you committed to four-to-six weeks under stated conditions, so if someone adds three new regions, it is obvious to all that the estimate was invalidated by a change, not by you missing.

The deeper habit here is treating an estimate as a forecast you revise, not a promise you’re chained to. The weather forecast updates as the storm moves; nobody accuses the forecaster of lying when Tuesday’s outlook changes on Monday. Estimates should work the same way. Give your best current range with its assumptions, and re-issue it whenever the assumptions shift or the fog clears. An estimate that never changes across a long project isn’t disciplined — it’s stale.

How it connects

Those assumptions are really a list of risks in disguise — “the vendor might be slow” is a risk you’ve flagged, and Risk Management: Identify, Assess, Mitigate picks up exactly there. The pressure to shrink an estimate after the fact — “can’t you just do it in three?” — is the front edge of Scope Creep and the Iron Triangle, where you’ll see why time, scope, and cost can’t all be squeezed at once. And re-issuing estimates as reality unfolds is the daily rhythm of Execution: Tracking Progress Without Micromanaging.

Try this

Take one estimate you owe someone this week — a task, a deadline, a cost. Before you give a single number, do three things. One: write it as a range, with a most-likely middle and an honest “if things go wrong” upper end. Two: find one comparable thing you or your team did before and check how long it actually took versus what you’d have guessed — then adjust your range toward reality. Three: list the three assumptions your estimate depends on, and hand them over with the range. Notice how differently the conversation goes when the uncertainty is on the table instead of hidden inside a false-precise number.

Reflect

1. Think of a recent estimate you gave as a single number. What range would have been honest — and how wide would it really have been?
2. When you estimate, do you picture the smooth version or the realistic version? Where has over-optimism cost you before?
3. Do you buffer openly or pad secretly? What are you afraid would happen if your buffer were visible?
4. Do you keep any record of how long things actually take, versus what you predicted? What would that record teach you about your own guesses?
5. The last time an estimate was blown, was it because the work was genuinely bigger — or because an assumption quietly changed and nobody named it?

Show reflections

1. The gap between the number you gave and the honest range is a measure of how much certainty you were faking. Wide ranges aren’t a failure to answer; they’re an accurate report of genuine fog. The goal is to feel comfortable saying “two to five weeks” out loud rather than forcing a false “three.”
2. Almost everyone pictures the smooth version — that’s the planning fallacy at work, not a personal flaw. The useful move is to notice your gut estimate is a best-case in disguise, and deliberately ask “what would the realistic version, with interruptions, look like?”
3. This one rewards honesty. Hidden padding usually comes from a rational fear of being held to a number. Naming that fear points to the real fix: an environment where a visible, explained buffer is accepted — which is safer for you and more accurate for everyone.
4. Most people keep no record and rely on memory, which conveniently forgets the overruns. Even a rough “estimated vs. actual” log reveals a personal correction ratio — and discovering that your instinct is reliably, say, 1.8x low is more actionable than resolving to “guess better.”
5. This separates two very different failures. Genuinely-bigger work is an estimation problem to learn from; a silently-changed assumption is a communication problem — the estimate was fine, but the trigger wasn’t watched. Knowing which one it was tells you whether to improve your ranges or your assumption-tracking.