Owning projects
Estimate vs commitment
An estimate is a range under uncertainty. A commitment is a date you agree to hit, usually by cutting scope. Do not give one when asked for the other.
Every estimate is a forecast under uncertainty. Software is mostly new work: if you had done the exact same thing before, you would copy it. So single-point promises ("done Friday") systematically lie.
Stakeholders are not asking you for prophecy. They are asking whether to staff the bet, what to cut, and when to warn customers. A fuzzy but honest range with named risks beats a precise date you do not believe — every time.
The big idea
Concept
An estimate is a probability distribution over completion time. A commitment is a date you agree to hit, often by cutting scope or adding people. Confusing the two — giving a commitment when asked for an estimate — is how engineers get painted into corners.
Steve McConnell popularized the cone of uncertainty: early in a project your error band is huge (often a factor of ~4 either way); it narrows only as you learn. Treating a day-one guess as a commitment is the root of most schedule drama.
Why estimates are wrong
Four recurring causes:
- Unknowns. You have not seen the legacy auth path, the flaky third-party API, or the migration that needs dual-write. Unknown work does not appear in the first sketch.
- Optimism. Humans underweight integration, review cycles, meetings, and "just polish." Joel Spolsky's observation still holds: people estimate the happy path and ignore the rest of the calendar.
- Integration and review time. Writing the feature is often less than half the elapsed time. Code review, QA, staging, docs, and waiting on another team fill the rest.
- Scope that moves. A "simple" button grows a permissions model, analytics, and an admin escape hatch. Without non-goals, the estimate was for a different project.
Walking through a bad meeting
Leadership asks "can we hit Friday?" You have not broken the work down. Two answers:
| Answer | What it actually is |
|---|---|
| "Yes" | A commitment with no estimate behind it |
| "I'll break it down and reply by end of day" | An estimate process. Buy the time. |
The second answer is the professional one. Bring a table, not bravery.
Trade-off
Fixed scope / flexible date vs fixed date / flexible scope. Executives often need a date (conference, compliance deadline). In that world, negotiate scope: ship the slice that meets the deadline, park the rest. Fixed scope and fixed date with no buffer is how teams burn out and still miss.
Common mistakes
- Saying "yes" to a date in a meeting without a breakdown.
- Treating the first estimate as sacred instead of a living forecast.
- Giving a single number, which implies false precision.
Check yourself
A PM asks "so, Friday?" You have not seen the auth path. What do you say?
Buy time: break it down and reply with a range and named risks, not a brave yes.
You quoted 3–5 days at 70% confidence. They put "Friday" on the slide. What happened?
They turned your estimate into a commitment. Renegotiate scope or the date before the slide becomes the plan.
Key takeaways
- Estimates fail from unknowns, optimism, integration time, and moving scope — not from moral failure.
- An estimate is a range. A commitment is a date you agree to hit, usually by cutting scope.
- Early error bands are huge. The cone narrows only as you learn.
- Never say yes to a date without a breakdown.
Further learning
Next, make the range real: work breakdown and spikes.
Related
Estimation and planning
Breaking work into small tasks, estimating with ranges, de-risking early, and communicating slips before they become surprises.
Work breakdown and spikes
Split work until each leaf is about one or two focused days. Time-box unknowns as spikes before you pretend to know their cost.
Estimate ranges and padding
Quote a range and a confidence, then multiply the raw sum out loud for unfamiliarity. Hidden padding is how trust dies.