The plain-English guide
How to estimate a project without lying to yourself
A single number is a guess in disguise. The honest way to estimate a project is to stop predicting one date and start describing the range the truth will land in — then bank the difference.
From the studio behind ganttchart.ai · a 6-minute read
To estimate a project is to answer one question honestly: how long will this take? The mistake is answering it with a single number. Real work does not have a duration — it has a spread of possible durations, and any one number you pick is just a bet on where inside that spread today will land.
So a good estimate is not a prediction, it is a range: the fast version, the normal version, and the version where everything fights you. Once you accept that, estimating stops being fortune- telling and becomes something you can actually do well — break the work small, size each piece three ways, and add it up along the chain that decides the finish. That chain is the critical path, and it is where every honest estimate eventually points.
Why the number is always low
The planning fallacy
Ask anyone how long a task will take and they picture it going right — the version with no interruptions, no surprises, no waiting on someone else. That imagined run is the optimistic end of the range, and we quote it as if it were the middle. It has a name, the planning fallacy, and it is stubborn: knowing about it barely helps.
What does help is refusing to answer with one number at all. When you are forced to name the pessimistic case too, the optimistic bias has nowhere to hide — you have written down, in your own hand, that the bad day is possible. The range is not pessimism. It is the only honest shape an estimate can take, and it is the whole trick.
Size it three ways
An estimate is a band, not a point
The same bakery-website launch, with its three critical tasks sized as ranges. Each band runs from the optimistic day to the pessimistic day; the bright notch is the likely case. The wider the band, the less you really know yet.
Quote the middle — 21 days — and hold the 16-day gap up to pessimistic as one buffer, not as padding hidden inside every task.
The method, in five moves
How to estimate, honestly
No software required to do it right — only the discipline to size small pieces, name three numbers instead of one, and keep the uncertainty where you can see it.
- 01
Estimate the pieces, never the whole
Nobody can size "build the website" — the number is a guess wearing a suit. Break the job into a work breakdown first, down to tasks a person could finish in a day or few, and estimate those. Small pieces are the only pieces you can be honest about.
- 02
Give each piece a range, not a number
For every task, write three durations: the day everything breaks right (optimistic), the day it goes normally (likely), and the day it fights you (pessimistic). A single number pretends to a certainty you do not have. A range is just the truth — and the gap between its ends is how much you actually know.
- 03
Add up the likely, not the hopeful
Total the middle estimates along each chain of dependent work — not the optimistic ones you will be tempted to quote. If you want one blended number per task, the classic weighting is (optimistic + 4×likely + pessimistic) ÷ 6, which leans on the likely case but refuses to ignore the bad day.
- 04
Find where a slip actually hurts
Trace the critical path — the longest chain of tasks that wait on each other. That chain, and only that chain, sets the end date. A wobbly estimate on it moves the whole project; a wobbly estimate off it has slack to absorb the slip for free.
- 05
Bank the uncertainty in one buffer
Do not pad every task — hidden padding evaporates, because the work quietly expands to eat it. Take the gap between your likely total and your pessimistic total, keep a visible slice of it as one buffer at the end of the critical chain, and protect that. One honest buffer beats twenty invisible ones.
Want to see honest estimates drawn onto real plans? See the worked examples →
What the range buys you
A number you can defend
The point of estimating in ranges is not caution — it is that a range survives contact with reality and a single number does not. When the hard day comes, you are not wrong; you are inside the band you named, and the buffer you set aside is right there to spend.
It also changes the conversation. "Six weeks" invites an argument about whether you are padding. "Most likely six weeks, and here is the run of tasks that could push it to eight" invites a decision — which is what a plan is for. Lay that estimate on a Gantt chart and the argument gets even shorter, because the critical path shows exactly which tasks the whole date is riding on.
Then re-estimate as you learn. The first number is your widest; every task you finish narrows the ones still ahead. An estimate is not a promise you made once — it is a bet you keep revising as the unknowns turn into facts.
Common questions
Estimating, briefly
How do you estimate a project, in one sentence?
Break the project into small tasks, give each task a range instead of a single number (an optimistic, a likely, and a pessimistic duration), add up the likely durations along the longest chain of dependent work, and hold the difference between "likely" and "pessimistic" as one buffer at the end. The range is the estimate; the single number people quote is just the middle of it with the honesty filed off.
Why are my project estimates always wrong?
Because a single number cannot be right — it can only be lucky. Real work has a spread of outcomes, and people quote the optimistic end of that spread by default: this is the planning fallacy, and it is remarkably stubborn even when you know about it. Estimating in ranges fixes most of it. You stop trying to predict the one true duration and start describing the band the truth will land in, which is a question you can actually answer.
What is a three-point estimate?
A three-point estimate replaces one guessed duration with three: optimistic (everything breaks your way), most likely (a normal run), and pessimistic (it fights you the whole way). You can keep the range as-is, or blend it into a single expected number with the PERT weighting — (optimistic + 4×most-likely + pessimistic) ÷ 6 — which trusts the likely case most while refusing to pretend the bad day cannot happen. It is the simplest honest estimate there is.
Should I add a buffer to every task?
No. Padding sprinkled across every task is the surest way to lose it — work expands to fill whatever time it is given, so twenty small hidden buffers quietly disappear one deadline at a time. Gather that uncertainty into a single, visible buffer at the end of the critical chain instead. Then a slip has one shared reserve to draw from, and everyone can see how much of it is left.
How accurate can a project estimate really be?
Early on, honestly not very — and pretending otherwise is where plans go wrong. A useful rule of thumb is the "cone of uncertainty": at the very start an estimate can be off by a factor of two or more in either direction, and it tightens only as the work becomes real and the unknowns get answered. So estimate in ranges, re-estimate as you learn, and treat the first number as a bet you will revise — not a promise you have made.
Every planning term above is defined, jargon-free, in the plain-English glossary.
Let the chart do the adding
Describe your project in plain English and ganttchart.ai lays out the tasks in dependency order, highlights the critical path, and totals the durations for you — so the only thing left to be honest about is the estimates themselves.
Draw my planOr keep reading: how to plan a project · the critical path method