Software project estimation: why estimates slip and how to make them reliable

Software project estimation goes wrong for a simple reason: the estimate is made when the least is known about the work. A reliable estimate is a range that narrows as questions get answered, not a single number fixed on day one. Discovery, small pieces of work and regular re-estimates are what narrow it.

Why software estimates slip

Slow developers cause fewer slips than people think. Most come from work nobody saw when the estimate was made:

• Vague requirements. 'Users can export reports' could mean one download button or a scheduled report builder with filters and permissions.
• Integration surprises. An older system or a third-party API often behaves differently from its documentation.
• Work outside the features. Environments, security checks, test data, release steps and documentation are easy to leave out of a feature-by-feature estimate.
• Waiting. Time spent waiting for decisions, access, content or feedback is real schedule time, even when nobody is coding.
• Optimism. People estimate the version of the task where everything goes right the first time.

Ask for a range, not a single number

Steve McConnell's white paper on the cone of uncertainty puts numbers on this. Estimates made by skilled estimators at the initial concept stage can be out by a factor of four in either direction, a sixteen-fold spread from lowest to highest. The spread narrows as the product definition, requirements and design are settled. It only narrows if the project actually settles them.

A single number hides all of that. A range shows how much is still unknown, and a useful estimate makes the reasons visible. Ask for four things:

• A low and a high figure for effort, cost or calendar time.
• The assumptions behind each figure, written as plain sentences.
• The main unknowns that explain the gap between the two.
• What would narrow the range, such as a prototype, access to an API or a decision on a feature.

If a partner gives you a precise figure for an idea that fits on one page, ask what it assumes. Either the scope is smaller than you think, or the risk has been priced in somewhere you can't see.

Do discovery before you commit to a number

Discovery is the short phase where both sides work out what is actually being built: the users, workflows, integrations, risks and what is out of scope. It costs a little time up front and removes the biggest sources of error from the estimate.

On our project delivery work, the first step is agreeing the business outcome, users, architecture, scope, dependencies, milestones and acceptance criteria. That agreed delivery baseline is what the plan and price are built on. Well-defined work can then have a fixed price paid against milestones. Work that needs discovery first can use a capped or phased structure until the baseline is agreed.

How certain the scope is also decides which contract suits you. Our post on fixed price vs time and materials covers that choice.

Break the work down until it can be estimated

Large items are where estimates hide their errors. Break features into tasks small enough for one person to finish in a few days, and estimate those. You can't estimate 'build the dashboard' without asking what is on it, so breaking work down forces the questions out early.

It also shows the work that sits between features. Check that the breakdown includes these, because they are often missing:

• Project setup: environments, build pipelines and access to systems.
• Sign-in, user roles and permissions.
• Error messages, empty screens and edge cases.
• Automated tests and realistic test data.
• Security and performance checks before release.
• Release work, documentation and handover.
• Time for your own team to review, test and approve.

Use buffers honestly

A buffer is not padding. It is an estimate of the risk you already know about. Keep it as its own visible line rather than spreading it across every task, where nobody can see it being used up.

Tie each part of the buffer to a named risk, such as 'the payment provider's test environment may not match production'. When that risk passes without trouble, release its share of the buffer. If the buffer starts running down early, treat it as a signal to talk about scope, not to ask the team for weekend work.

Re-estimate at every milestone

An estimate is a forecast, so update it as you learn. At each milestone, or every few sprints on a longer project, compare what was planned with what was finished. Then forecast the remaining work again.

Measure progress by finished, tested work, not by hours used. Half the budget spent does not mean half the work is done. A team that re-estimates regularly gives you bad news while you still have options: cut scope, move a date or change the order of the work. For the numbers worth watching along the way, see software delivery metrics for business leaders.

What to ask for when you receive an estimate

1. A range with its assumptions. What would push it to the low end, and what to the high end?
2. A breakdown by milestone, so you can see where the effort goes and what you could drop if the budget is fixed.
3. The exclusions. The out-of-scope list tells you as much as the in-scope one.
4. Your own tasks and deadlines, such as content, access, test users and decisions.
5. When it will be re-estimated, and how you will hear about changes.
6. How changes will be priced, agreed before the first change request arrives.

Where to start

Write down the outcome you need and the one constraint you can't move, whether that is a date or a budget. Share that, and ask for a range with its assumptions rather than a single number. If the range is wide, pay for discovery first and ask for a firmer estimate at the end of it.

A scoped Coretus project can kick off in 1–2 weeks, with agreed milestones and acceptance criteria. Book a free 30-minute call, and after it we will suggest the right team and give you a rough quote range.