Planning guide / Software estimates
Keep the assumptions attached to the number.
A ballpark can help decide whether an idea deserves further investigation. It becomes misleading when the number survives but its scope, exclusions and uncertainty disappear. A useful estimate states the decision it supports and the evidence still needed before a commitment.
One number, different decisions
An estimate needs a purpose before it needs precision.
Ask what decision the estimate must support: dismiss an unsuitable option, fund investigation, approve a scoped release or revise a delivery forecast. The evidence needed for each is different. A narrow range is useful only when its assumptions justify it.
- Estimate and budget are different
- An estimate describes expected effort, cost or time under stated assumptions. A budget is an authorized spending limit. Setting the budget does not make the estimated work fit inside it.
- Effort is not elapsed time
- People may need access, decisions, test environments or external approvals before work can move. Parallel work and waiting time affect the calendar differently from engineering effort.
- A forecast is not a commercial promise
- A forecast changes with evidence about remaining work and delivery conditions. Any commercial commitment needs its own agreed scope, acceptance terms, responsibilities and treatment of change.
Six ways an early estimate loses its basis
Inspect what the number leaves out.
These are failure mechanisms to look for in a proposal. They are not claims about every supplier or a reason to avoid early planning altogether.
Screens stand in for complete work
01Question to ask: What must happen behind and around the interface?
- How it happens
- A feature list names dashboards, forms and reports without defining permissions, exceptions or the source records that make them work.
- Evidence to request
- User tasks, business rules, data sources, roles, error paths, acceptance examples and operational handoffs.
- Better approach
- Describe a complete workflow from input to accepted result. Include validation, access checks, testing and recovery where the work requires them.
- Owner decision
- Product and operating owners decide what is required for the first usable release and what can be deferred.
- Estimate record
- Included workflows, acceptance boundaries, exclusions and unresolved requirements.
- Warning sign
- A screen count is treated as sufficient scope, or basic exception handling appears later as unexpected work.
- Reason to revise
- A new role, rule or exception changes what the release must do.
Integration and data work stay invisible
02Question to ask: Have we inspected the systems and records we depend on?
- How it happens
- An API name or sample spreadsheet is taken as proof that the required data is complete, accessible and compatible.
- Evidence to request
- Actual API behavior, access requirements, data samples, identifiers, field meaning, quality issues and migration needs.
- Better approach
- Investigate the uncertain boundary with representative records and a small technical test. Keep cleanup, reconciliation and unavailable access explicit.
- Owner decision
- System and data owners confirm access, source meaning and the acceptance criteria for imported or synchronized records.
- Estimate record
- Tested interface, inspected sample, mapping assumptions, missing evidence and responsible owner.
- Warning sign
- The estimate says an integration is standard without checking the required operations or data quality.
- Reason to revise
- The real interface, data volume or reconciliation requirement differs from the assumption.
The calendar assumes away dependencies
03Question to ask: What has to be ready before the team can finish?
- How it happens
- A delivery date is calculated from effort while client decisions, procurement, review cycles and third-party work are omitted.
- Evidence to request
- Named dependencies, decision owners, access dates, review capacity, team availability and release constraints.
- Better approach
- Show the sequence and waiting points separately from effort. Use scenarios when a dependency date is uncertain instead of silently assuming immediate availability.
- Owner decision
- Sponsors and delivery owners decide which deadlines are fixed and what scope or dependency changes are possible.
- Estimate record
- Schedule assumptions, external dependencies, owner commitments and unresolved timing.
- Warning sign
- Adding people is presented as a direct reduction in duration without checking which work can run in parallel.
- Reason to revise
- A dependency slips, review capacity changes or an assumed parallel activity becomes sequential.
The comparison excludes different work
04Question to ask: Are the proposals estimating the same outcome?
- How it happens
- Two totals look comparable even though one excludes migration, testing, deployment, training or ongoing operation.
- Evidence to request
- Deliverables, acceptance criteria, internal effort, recurring charges, handover, support scope and explicit exclusions.
- Better approach
- Normalize proposals against the same work boundary. Separate implementation from recurring costs and identify responsibilities that remain with the client.
- Owner decision
- The buyer decides which services to buy, which responsibilities to retain and which risks need clarification.
- Estimate record
- Comparable scope table, included and excluded cost categories, assumptions and open commercial questions.
- Warning sign
- The lowest total is called the cheapest option before omissions and operating responsibilities are reconciled.
- Reason to revise
- A required responsibility moves between the supplier and client or a recurring cost was not included.
A single figure hides uncertainty
05Question to ask: Which assumptions would materially change this estimate?
- How it happens
- A precise total is produced from uncertain inputs, or a generic contingency is added without explaining the underlying risks.
- Evidence to request
- Estimation method, comparable evidence, major assumptions, uncertain work, dependencies and sensitivity to changes.
- Better approach
- Explain the important scenarios and drivers. Use a range where justified, and do not attach a probability or confidence label without a defensible method and data.
- Owner decision
- Sponsors decide whether the remaining uncertainty is acceptable for the current decision or needs investigation first.
- Estimate record
- Basis of estimate, scenario differences, material risks and the next evidence needed.
- Warning sign
- A narrow range has no supporting analysis, or contingency is used to hide undefined scope.
- Reason to revise
- New evidence changes a major assumption or reveals a risk that the original basis did not cover.
The original number becomes untouchable
06Question to ask: What does the latest delivery evidence say about remaining work?
- How it happens
- The first estimate stays in presentations while accepted scope, completed work and operating conditions have changed.
- Evidence to request
- Original estimate version, scope changes, accepted work, actual effort or cost, unresolved defects and remaining dependencies.
- Better approach
- Update the forecast and explain the difference. Separate added scope, corrected assumptions and delivery performance rather than combining every change into an unexplained overrun.
- Owner decision
- The accountable sponsor decides whether to continue, reduce scope, change the approach or stop.
- Estimate record
- Dated forecast, reconciliation to the previous version, remaining uncertainty and the decision taken.
- Warning sign
- Reported progress counts started tasks while integration and acceptance work remain outside the forecast.
- Reason to revise
- Accepted work, actual costs or unresolved delivery risks contradict the current plan.
Match the number to the decision
Do not promote an estimate without its evidence.
These records can inform one another, but they are not interchangeable. State the purpose and limits wherever the number is reused.
| Record | Useful purpose | Does not establish | Decision owner | Evidence to retain |
|---|---|---|---|---|
| Early ballpark | Screen an option | Committed price or date | Sponsor | Outline scope and assumptions |
| Discovery plan | Fund specific learning | A fully defined solution | Product and sponsor | Questions and completion criteria |
| Scoped estimate | Compare a defined release | All uncertainty removed | Delivery and buyer | Baseline, method and risk |
| Budget | Authorize spending | Required work fits the limit | Budget owner | Approved scope and controls |
| Delivery forecast | Reassess remaining work | An unchanged original promise | Delivery owner | Actuals, changes and dependencies |
| Commercial commitment | Agree responsibilities | A substitute for clear terms | Authorized parties | Scope, acceptance and change terms |
A better next decision
Investigate the uncertainty that could change your choice.
Discovery is useful when it resolves a material question. It should not become an open-ended promise that all uncertainty will disappear.
- 01
Name the decision
State whether you are screening an idea, funding investigation, comparing proposals or authorizing a release. Identify the owner and the evidence that would change the decision.
- 02
Define the work boundary
Describe the user outcome, source data, roles and acceptance conditions. List exclusions, client responsibilities and recurring operating work separately.
- 03
Test a material unknown
Inspect a difficult integration, data sample or user workflow. Choose an investigation that can resolve a consequential assumption and define what counts as an answer.
- 04
Compare scenarios
Show how different scope or dependency assumptions affect effort, cost and elapsed time. Preserve unknowns that the investigation did not resolve.
- 05
Decide and keep updating
Choose the next bounded commitment, defer it or stop. Version the estimate and revisit it as accepted work, actual costs and changed requirements provide better evidence.
Keep the estimate usable
Preserve the basis when the number travels.
A concise estimate record can prevent an early assumption from becoming an accidental delivery commitment.
- Attach scope and date
- Show the estimate version, purpose, included work, exclusions and date. When a total appears in a decision paper, keep a link to that basis.
- Name uncertain dependencies
- Give important unanswered questions an owner and a review point. Missing access or an undecided requirement must remain visible.
- Separate changes from performance
- Explain whether a revision comes from changed scope, corrected assumptions, external conditions or delivery results. Keep the original basis available for comparison.
- Define acceptance before progress
- Measure work against agreed completion conditions. Code written, tickets closed and a demo shown can leave substantial testing, integration or operating work unfinished.
Questions before approving the number
Ask what the estimate is ready to support.
A useful supplier can explain the basis of an estimate, its limits and the next evidence that would improve it.
- Are ballpark estimates always a mistake?
- No. An early estimate can help screen options and decide whether further investigation is worthwhile. The mistake is reusing it for a stronger commitment after its assumptions and limits have been forgotten.
- Should every estimate be a range?
- A range can communicate uncertainty, but it still needs a basis. Explain what drives the endpoints or scenarios. Do not invent a confidence percentage or imply that a wider range compensates for missing scope.
- Does discovery guarantee an accurate final price?
- No. Discovery should resolve specific questions about users, constraints and feasibility. It may support a better estimate, identify a different approach or show that further work is not justified. Some delivery uncertainty remains.
- Can a fixed budget still be useful?
- Yes, as a spending constraint. The team must then define what outcome can be pursued within it and how scope decisions will be made. A fixed budget does not independently prove that all requested features can be delivered.
- What should I request before comparing proposals?
- Ask each supplier to show included workflows, acceptance criteria, exclusions, client responsibilities, dependencies, operating costs and the basis of uncertainty. Reconcile those differences before comparing the totals.
Source basis
Sources behind the control model.
- 01
US Government Accountability Office
Cost Estimating and Assessment GuideOfficial overview of the 2020 guide identifies scope, technical baseline, assumptions, data, sensitivity and risk analysis, documentation and updates using actual costs. The overview is the source reviewed here.
- 02
GOV.UK Service Manual
Planning in agileGuidance updated March 2026 supports changing plans as evidence grows, keeping distant work at a higher level and making near-term work more detailed. Its government planning context is not a commercial delivery promise.
- 03
GOV.UK Service Manual
How the discovery phase worksGuidance on understanding the problem, users and constraints before proceeding. Discovery can support a decision to stop; its example durations and government approvals are not adopted as Werkon terms.
Start with one real workflow
A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.
Show Us the WorkflowStart with the free automation readiness checklistOBSERVEQUANTIFYDECIDEBUILD