Understand what makes a software estimate uncertain

Read estimates as conditional plans and ask which assumptions, dependencies and unanswered questions affect their reliability.

Glass cubes of different sizes beside a caliper and laptop suggest estimate uncertainty.

An estimate is easier to use when you know what it assumes. Two suppliers can offer different delivery expectations because they imagine different data quality, review arrangements or scope boundaries. Before comparing their numbers, ask what each believes is included and which unknowns could materially change the work. That conversation often reveals more than another round of negotiation.

Identify the sources of uncertainty

Separate unclear requirements, unfamiliar business rules, external dependencies and incomplete inputs. A hypothetical Wollongong parts supplier may know exactly how it creates new orders but not how many old product codes refer to the same item. Building a new order form and reconciling historical records are different estimation problems. Ask the supplier to describe uncertainty in plain language, including what information would improve confidence. A broad contingency statement alone does not explain where attention is needed.

Check the assumptions you control

An estimate may depend on staff answering questions promptly, supplying sample records or reviewing a demonstration within a certain period. If your busiest season overlaps delivery, those assumptions may be unrealistic. Identify a business decision maker and a backup before agreeing a schedule. Delayed decisions are not automatically the supplier's fault, but neither should an estimate silently assume unlimited access to your team. Make both sides' responsibilities visible so the plan can reflect actual capacity.

Use targeted investigation selectively

A small experiment can sometimes resolve a large unknown. The parts supplier might examine a representative record sample before estimating the full clean-up. In other cases, investigation has diminishing value and the team must proceed with a stated assumption. The tradeoff is between spending time to reduce uncertainty and delaying useful implementation. Ask which unanswered question could change the approach substantially, then investigate that question before polishing the estimate of work that is already well understood.

Revisit the plan when evidence changes

Agree when estimates will be reviewed and how new information will affect scope or sequence. Avoid treating an early planning range as a permanent promise while also expecting requirements to evolve freely. Equally, ask for a clear explanation when expectations change. Your next scoping step is an assumptions register with a confidence note, an owner and a proposed check for each significant uncertainty. Use it to compare proposals on an equivalent basis.

Planning checklist

  • Ask what the estimate assumes.
  • Name business inputs and review capacity.
  • Investigate the unknown with the largest consequence.

Discuss your software project with 110s

Related Insight