What Is Estimation, Really?
Spoiler: it's not a single number, and you're probably worse at it than you think.
How Good an Estimator Are You?
Before we talk about software estimation, let's test your general estimation skills with a quick exercise from Steve McConnell's Software Estimation.
For each question below, give a range that you are 90% confident contains the correct answer. Don't look anything up — the point isn't to know the answers, it's to calibrate how wide your ranges are.
Interactive Exercise
Why Estimation Matters
You might think estimation is just about predicting the future. It's actually about project control — determining whether your targets are realistic enough to allow the project to be managed effectively.
Guess the Stat
What percentage of software projects do you think are delivered on time and on budget?
Drag the slider to your guess, then click reveal.
The software industry has a dismal estimation track record. The average project overruns its schedule by 25–100%. And about 40% of software defects stem from schedule pressure caused by poor estimation.
"The primary purpose of software estimation is not to predict a project's outcome; it is to determine whether a project's targets are realistic enough to allow the project to be controlled to meet them."
— Steve McConnell
Estimates Are Not Single Numbers
Here's a fundamental misconception: most people think of an estimate as a single number. "It'll take 3 months." But a true estimate is a probability distribution — a range of possible outcomes with different likelihoods.
Point Estimate vs. Probability Range
Click each tab to see the same project estimated two different ways:
The point estimate problem: "3 months" sounds precise and actionable. But it hides all uncertainty. Are we 50% confident? 90%? If things go wrong, how bad could it get? A single number can't answer these questions.
McConnell defines an estimate as: "a prediction of how long a project will take or how much it will cost," but crucially, it should be expressed as a range with an associated probability. "I'm 90% confident this will take between 2 and 4.5 months" is an honest estimate. "3 months" is a guess dressed up as certainty.
Estimates vs. Targets vs. Commitments
One of the most important (and most ignored) distinctions in project management. These three things are frequently confused, and the confusion causes real damage:
Estimate — A prediction of how long something will take or cost. Based on analysis. Can be revised as you learn more.
Target — A business goal. "We need this by March for the trade show." Driven by need, not analysis.
Commitment — A promise to deliver defined functionality by a specific date. Made by a person or team, carrying accountability.
"You can negotiate commitments, but don't negotiate estimates."
— Steve McConnell
Sorting Exercise
Drag each statement into the correct category:
Why does this distinction matter so much?
When an estimate ("this will take 5 months") collides with a target ("we need it in 3 months"), the healthy response is to treat the gap as a risk that requires action — cut scope, add resources, adjust the date.
The unhealthy response (and the common one) is to simply change the estimate to match the target. The project then runs on a fantasy schedule, and the inevitable overrun surprises everyone — except the engineers who knew the original estimate was right.
The Cone of Uncertainty
One of the most powerful concepts in estimation: the Cone of Uncertainty describes how the accuracy of estimates improves as a project progresses through its phases.
Early in a project, estimates can be off by a factor of 4x in either direction. As decisions are made and uncertainty is resolved, the cone narrows.
Explore the Cone
Click on each project phase to see how the estimation range changes:
Critical Insight
"The Cone doesn't narrow itself." Simply waiting doesn't improve estimates. The cone narrows only through concrete decisions — defining requirements, choosing an architecture, deciding what not to build. Each decision eliminates variability and makes the estimate more precise.
Key Takeaways
What We Learned
- We are systematically overconfident in our estimates — our ranges are too narrow
- An estimate is a probability range, not a single number
- Estimates, targets, and commitments are three different things — conflating them leads to dysfunction
- The Cone of Uncertainty means early estimates can be off by 4x — and that's normal
- Estimation's real purpose is project control, not fortune-telling