--- title: "Estimating without lying: ranges, confidence, and the buffer talk" source: https://www.taim.io/project-management/estimating-without-lying published: Sat May 09 2026 10:51:13 GMT+0000 (Coordinated Universal Time) updated: Thu Jun 04 2026 17:17:10 GMT+0000 (Coordinated Universal Time) description: "Most project estimates are wrong, but the bad ones are wrong in predictable ways: too low, too confident, and presented as a single number that turns into a deadline. Honest estimating doesn't mean being a pessimist — it means giving the pe" --- # Estimating without lying: ranges, confidence, and the buffer talk Most project estimates are wrong, but the bad ones are wrong in predictable ways: too low, too confident, and presented as a single number that turns into a deadline. Honest estimating doesn't mean being a pessimist — it means giving the people who depend on your number enough information to make real decisions. Most project estimates are wrong, but the bad ones are wrong in predictable ways: too low, too confident, and presented as a single number that turns into a deadline. Honest estimating doesn't mean being a pessimist — it means giving the people who depend on your number enough information to make real decisions. ## What you'll learn - Why ranges and confidence levels beat single-number estimates - A simple breakdown that prevents the most common estimation errors - How to have the buffer conversation honestly with stakeholders ## Ranges and confidence beat single numbers When someone asks *"how long will this take?"*, the worst answer is *"three weeks."* Single numbers feel decisive; they're also almost always wrong, and they get treated as commitments. A better answer: *"Three to five weeks. I'm maybe 70% confident in that range."* This communicates three things a single number doesn't: - The uncertainty is real and bounded. - You've thought about how it could go long. - The listener can plan against the high end if it matters. For longer projects, structure the estimate as three numbers: best case, expected, worst case. Best case assumes nothing surprises you. Expected is what you'd bet money on. Worst case assumes one or two specific things go wrong. The stakeholder who actually needs your number can usually use this directly. The one who insists on a single number is the one most likely to be unhappy when the single number turns out to be wrong. ## Break the work down before you estimate The single most reliable improvement to estimates is breaking the work down before you estimate. Top-of-mind estimates rely on a vague mental model of the project; broken-down estimates rely on a list of concrete pieces, each of which you can size more honestly. A workable breakdown: 1. **List the chunks.** Five to fifteen pieces of work that, summed, deliver the project. Not tasks — *chunks*, each two days to two weeks. 2. **Estimate each chunk** as a range or three-point estimate. 3. **Sum** the expected values, but don't sum the worst cases. Worst cases don't correlate; the project worst case is rarely the sum of the chunk worst cases. 4. **Add an explicit buffer** for integration, testing, code review, and the unforeseen — typically 20–30% of the expected total. 5. **Identify the riskiest chunk** and ask whether de-risking it first would shrink the variance of the whole project. The breakdown surfaces hidden chunks (deployment, migrations, third-party integrations) that single-number estimates skip. Those skipped chunks are the source of most overruns. ## The buffer conversation Buffers are real. Pretending they aren't — quoting an unbuffered estimate to make stakeholders happy — is dishonest, and the unbuffered estimate becomes the deadline that gets missed. The healthier conversation: *"Based on the chunks, I'd expect this to take four weeks if everything goes smoothly. Realistically, with code review, testing, integration, and the inevitable surprises, I'd plan against six weeks. If you need to commit to a date publicly, I'd commit to the six-week date."* This works because it: - Shows the stakeholder how you got there. - Distinguishes the optimistic case from the planning case. - Names the buffer as buffer, not as padding hidden in the estimate. - Gives them a date they can defend. If the response is *"can you do it in four weeks?"*, the honest answer is usually *"I can if nothing surprises us, but I wouldn't bet on it. What needs to be true for the four-week date to be safer?"* That's a real conversation. The fake conversation — agreeing to four weeks anyway — ends in a missed date and lost credibility. ### Quick reference #### Range, not number Quote a range with a confidence level. Single numbers become deadlines. #### Three-point estimate Best case, expected, worst case. For larger projects. #### Break it down Estimate 5–15 chunks, sum expected values, then add buffer. #### Buffer 20–30% For integration, review, testing, surprises. Named explicitly. #### Don't sum worst cases Worst cases don't correlate. The project worst case is smaller than the sum. #### Buffer talk Tell stakeholders the optimistic case and the planning case separately. ### Common questions #### What if I genuinely don't know enough to estimate? Say so, and propose a time-boxed investigation. *"I can't estimate this responsibly without two days of investigation. Let me do that, then I'll come back with a real range."* Most stakeholders will agree; the ones who won't are setting you up to fail anyway. #### How do I handle stakeholders who only want a single number? Give them the high end of the range as the "single number," and explain that's what you'd commit to publicly. They get the simplicity they want; you get the buffer you need. #### Should I add buffer per task or at the end? At the end. Per-task buffers tend to compound silently and produce estimates that are wildly conservative. A single named buffer at the end is more honest and easier to defend. #### What about Agile / story points? Story points work well for relative sizing within a team that's calibrated. They translate poorly to dates with stakeholders who don't share the team's calibration. For external commitments, convert to ranges and confidence levels. ### Bottom line Honest estimates use ranges, not single numbers; break the work into chunks before estimating; add a named buffer of 20–30%; and have the buffer conversation openly with stakeholders. Single-number estimates feel decisive but produce missed dates. Ranges with confidence produce trusted teams. ### Next steps - On your next estimate, break the project into 5–15 chunks before you quote anything. - Quote your next estimate as a range with a confidence level. Note the stakeholder reaction. - For an active project, name the buffer explicitly to your team. See if the conversation gets more honest.