Software planning / Cost estimation
Build the estimate from the work it must cover.
A useful software cost estimate can be inspected and revised. It connects a defined outcome to the work, resources and operating assumptions needed to achieve it. The total should remain traceable to those inputs as scope, evidence and actual costs change.
Construct a reviewable model
Start with a complete piece of work.
Consider an illustrative service-request system. A request must be submitted, assigned, updated and closed. Estimating only its form leaves unanswered work: duplicate requests, access rules, notifications, existing records and operational support. Define a usable result first, then identify what it takes to deliver and sustain it.
- Scope describes the result
- Record included behavior, acceptance conditions and exclusions. A request to add a feature is not yet an explanation of its complete work.
- A cost basis explains the amount
- Connect quantities or effort to the applicable cost source. Keep units, currency, dates and the treatment of internal effort consistent.
- A range explains uncertainty
- Show which assumptions change between scenarios. A pair of endpoints does not establish a confidence level without a supporting method and evidence.
Six areas to cost
Follow the service beyond its visible interface.
Use these areas to inspect the proposed work. They are not fixed percentages of a budget, and a shared activity should be counted once.
Understanding the required behavior
01Cost question: Which decisions are unresolved before the work can be sized?
- Work to consider
- User tasks, business rules, exceptions and acceptance examples.
- Evidence to gather
- Current workflow, representative requests and the people who handle them.
- Service-request example
- Clarify whether a reopened request creates a new record or changes the old one.
- Estimate owner
- Product and operating owners resolve the business rule with technical input.
- Record in the model
- A bounded investigation or a defined behavior, with its assumptions.
- Uncertainty driver
- Different stakeholders expect different versions of the same feature.
- Update trigger
- A clarified rule changes the required behavior.
Implementing the usable change
02Cost question: What must be built or adapted to satisfy acceptance?
- Work to consider
- Application behavior, permissions, interfaces and necessary technical work.
- Evidence to gather
- Existing architecture, relevant code, acceptance cases and comparable work.
- Service-request example
- Include assignment rules and permitted status changes with the request interface.
- Estimate owner
- Engineering estimates the work; the product owner confirms the intended result.
- Record in the model
- Work items with an effort basis and named exclusions.
- Uncertainty driver
- An existing component needs more adaptation than expected.
- Update trigger
- Inspection or implementation reveals additional required work.
Connecting and moving records
03Cost question: What makes data usable across the boundary?
- Work to consider
- Mapping, interface behavior, migration, cleanup and reconciliation.
- Evidence to gather
- Representative records, identifiers, API behavior and source ownership.
- Service-request example
- Determine how old requests map to the new statuses and how duplicates are handled.
- Estimate owner
- System and data owners confirm meaning; engineering assesses the transfer.
- Record in the model
- Separate integration and migration work with acceptance evidence.
- Uncertainty driver
- Missing identifiers or inconsistent records change the reconciliation effort.
- Update trigger
- Real data or interface behavior contradicts the sample.
Verifying and introducing the system
04Cost question: What work makes the change ready for real use?
- Work to consider
- Relevant testing, release preparation, user guidance and transition.
- Evidence to gather
- Failure consequences, test conditions, operational constraints and receiving teams.
- Service-request example
- Check notification failures and show the receiving team how to handle an unassigned request.
- Estimate owner
- Quality, delivery and business owners define the relevant acceptance and readiness work.
- Record in the model
- Verification and transition activities attached to the release scope.
- Uncertainty driver
- An unavailable environment or review dependency delays completion.
- Update trigger
- A new failure case or rollout constraint changes readiness work.
Running the service
05Cost question: What will usage and support require over the chosen period?
- Work to consider
- Hosting, storage, service calls, monitoring and operating effort.
- Evidence to gather
- Expected demand, retention, environment needs, current prices and support responsibilities.
- Service-request example
- Model request volume and notification usage separately from the development effort.
- Estimate owner
- Engineering and service owners define demand; finance validates the cost treatment.
- Record in the model
- Recurring quantities, pricing basis, period and usage scenarios.
- Uncertainty driver
- Retention, traffic or service consumption differs from the plan.
- Update trigger
- Measured usage or applicable pricing changes.
Maintaining and eventually replacing it
06Cost question: What work remains after the first release?
- Work to consider
- Updates, defect repair, documentation, knowledge transfer and eventual retirement.
- Evidence to gather
- Dependency condition, planned ownership, likely changes and exit requirements.
- Service-request example
- Keep the request workflow maintainable and identify what records must be retained or transferred at retirement.
- Estimate owner
- The service owner defines the ownership horizon with technical and business input.
- Record in the model
- A stated period and separate assumptions for maintenance and transition.
- Uncertainty driver
- A short planning horizon hides later obligations.
- Update trigger
- Support conditions, ownership or the retirement plan changes.
Keep each estimate line inspectable
Make the calculation reproducible.
For labor, the arithmetic may be effort multiplied by an applicable rate. For usage-based services, it may be consumption multiplied by the relevant charge. The difficult part is establishing those inputs and avoiding omissions or double counting.
| Field | Record | Check | Validate with | Do not assume |
|---|---|---|---|---|
| Work item | Complete accepted result | Scope and exclusions | Product and delivery | A title defines the work |
| Quantity basis | Effort or consumption | Method and units | Technical owner | All units are comparable |
| Cost source | Applicable dated basis | Currency and inclusions | Finance or buyer | A public price is the actual rate |
| Timing | When costs occur | One-off or recurring | Delivery and service | Every resource runs from day one |
| Uncertainty | Drivers and scenarios | Dependencies and overlap | Relevant risk owner | A range proves probability |
| Revision | Version and reason | Actuals and remaining work | Accountable sponsor | Old inputs remain valid |
From scope to a maintained estimate
Build, challenge and revise the cost model.
Use the level of detail the decision needs. Keep unresolved work visible rather than inventing precision to fill a spreadsheet.
- 01
Set the boundary and period
Name the decision, included outcome, acceptance conditions, ownership period and exclusions. Identify responsibilities retained by the business.
- 02
Gather the cost basis
Break down complete work and collect relevant quantities, applicable rates and other charges. Use comparable delivery evidence only after checking the differences.
- 03
Investigate important unknowns
Use discovery to clarify users, rules and constraints. Choose a bounded technical investigation when the result could materially change an integration or implementation estimate.
- 04
Review scenarios and totals
Check the important drivers, shared costs and dependencies. Explain the range and its limits. Keep allowances distinct from already counted work.
- 05
Reconcile with actual delivery
Record actual costs to date and re-estimate remaining work. Explain revisions caused by added scope, corrected assumptions, usage changes or delivery results.
Prevent a misleading total
Keep the estimate and the decision connected.
The model should make a decision easier to inspect, including when the required outcome does not fit the available budget.
- Do not double count work
- Identify shared setup, coordination and testing activities. Check whether an external charge or internal cost basis already includes the item being added.
- Separate cost from calendar
- Effort, waiting time and elapsed duration are different. A dependency can change the schedule and may create additional cost, but the relationship needs an explicit basis.
- Keep uncertainty conditional
- Document the assumptions behind each scenario. Do not label a range P50 or P90 without a justified probabilistic analysis, and do not hide undefined scope in a standard percentage.
- Explain a scope decision
- If the estimate exceeds the budget, identify the behavior that could be deferred and the consequences. Do not preserve the original total by silently excluding required verification or operating work.
Questions about the estimate
Ask how the total was built.
A useful estimate remains explainable when someone challenges an input or asks what a change would cost.
- How do you calculate software development cost?
- Define complete work, estimate the relevant effort or quantities, apply the appropriate cost basis and add other included charges without overlap. Then account for uncertainty and the selected ownership period. The arithmetic alone does not establish whether the scope is complete.
- Which estimation method should a team use?
- Choose a method suited to the evidence available. A breakdown of work can support a bottom-up estimate; comparable completed work can support an analogy. A model needs inputs and calibration relevant to the situation. Record the method and challenge material assumptions.
- How should discovery affect the estimate?
- It should answer named questions that could change the proposed scope or approach. A finding may narrow uncertainty, reveal more work or support a decision not to build. Paying for discovery does not guarantee a fixed final price.
- What belongs in total ownership cost?
- State the ownership period, then include the applicable acquisition or development work, operation, support, maintenance and transition or retirement responsibilities. Separate cash charges from internal effort so the business can interpret the model consistently.
- When should an estimate be updated?
- Update it when evidence changes material inputs: accepted scope, actual effort, integration findings, usage, pricing or dependencies. Preserve the earlier version and explain the difference so a revised forecast does not erase the original basis.
Source basis
Sources behind the control model.
- 01
US Government Accountability Office
Cost Estimating and Assessment GuideThe official 2020 overview identifies the estimating process, assumptions, analysis and updates using actual costs. This article uses the overview, not a review of the full report.
- 02
NASA Software Engineering Handbook
SWE-151: Cost Estimate ConditionsCurrent Version D page, requirements and cost-guidance sections, reviewed September 2026. Supports lifecycle coverage, project attributes and uncertainty. NASA-specific mandates and numeric allowances are not adopted.
- 03
GOV.UK Service Manual
How the discovery phase worksSupports investigating users, constraints and the problem before committing to development. Its typical durations and government approval process are not Werkon terms.
- 04
FinOps Foundation
Planning & EstimatingThe capability's definition and scenario guidance support explicit usage, pricing, environments and shared costs. This article applies those ideas to operating-cost assumptions without adopting example trial durations or KPI formulas.
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