How clients should budget a software project
Build a software budget from delivery assumptions, named risks, operating costs, and explicit decisions about what happens when scope changes.
Agree what the budget buys
I recommend separating the delivery forecast from the spending limit. The forecast is an estimate under stated assumptions. The limit is the amount the sponsor has authorised. If the forecast rises above it, someone must choose a smaller release, approve more spending or stop. A forecast is not permission to spend.
For a hypothetical appointment portal, I recommend defining the first release as showing availability, reserving a slot, sending confirmation and letting staff cancel it. Exclude payments, recurring appointments and old-record imports. Agree acceptance cases, including two customers trying to reserve the same slot. This makes “booking” a reviewable commitment rather than a label that can expand unnoticed.
A completed example, with invented amounts
The following EUR amounts are invented to demonstrate the method. They are not Ulties prices, market rates, a quotation or observed delivery results. All amounts exclude tax; another project needs its own currency, tax treatment and commercial agreement.
Assume the sponsor approves a delivery limit of EUR 12,000. The initial forecast is EUR 10,000: EUR 6,000 for the portal, EUR 2,000 for calendar integration and EUR 2,000 for testing and handover. The remaining EUR 2,000 is headroom within the limit, not another task or an automatic contingency charge.
At a checkpoint, EUR 4,000 has been spent. The team now estimates EUR 9,000 of remaining delivery work because the calendar needs conflict handling the original estimate omitted. Forecast to finish: EUR 4,000 + EUR 9,000 = EUR 13,000. The predicted shortfall against the approved limit is EUR 1,000. Do not add the original EUR 10,000 forecast to money already spent: it included work now completed.
Make the sponsor decision explicit
In this example the supplier estimates that deferring automatic calendar synchronisation removes EUR 2,000 from remaining work. Staff would confirm appointments manually instead; customers would see a request acknowledgement, not a guaranteed booking. The revised forecast is EUR 4,000 + EUR 7,000 = EUR 11,000. That leaves EUR 1,000 of headroom, but it buys a different workflow.
I recommend recording the sponsor’s choice before continuing the affected work: accept that smaller workflow, approve a EUR 13,000 limit for the original scope, or pause while another option is investigated. Update the acceptance cases and schedule as well as the number. A cheaper forecast is not a scope-neutral saving.
The example assumes the deferred work has not already been done and can be removed without extra cancellation or rework charges. If that assumption fails, recalculate before seeking approval. The revised amount is still a forecast, not a guaranteed final bill.
Price the unknown and keep operating costs separate
For an uncertain integration, I recommend a bounded investigation: a named question, a spending cap and an output. Here the question is whether the calendar sandbox rejects simultaneous reservations. The output should include observed results and a revised estimate, including what remains unknown. Discovery can expose a dependency the team cannot control; it does not guarantee certainty.
For a separate illustrative operating plan, assume EUR 150 per month for hosting and monitoring and EUR 50 per month for support. A full twelve months costs EUR 2,400 before tax: twelve times EUR 200. This is separate from the EUR 12,000 delivery limit. Message usage, renewals and additional changes are excluded and need their own estimates and owners. A different launch date changes the period you should budget.
The GAO’s cost-estimating guide identifies scope, assumptions, risk analysis and updating estimates with actual costs as estimating steps. It concerns government programmes; I am adapting those principles here, not claiming this small example follows its full methodology.
What to request at the next checkpoint
I recommend a checkpoint record containing accepted functionality, spend to date, remaining-work forecast, changed assumptions and a named decision owner. Ask which content, data cleanup, accessibility testing, migration work and client approval effort are included. An estimate that assumes your team supplies those things should say so.
I recommend requesting a demonstration against the acceptance cases. Spending to plan does not establish that the promised workflow works. Record authorised changes so both sides can explain the current scope and limit at the next review.
This is a planning method for a client sponsor, not financial, tax or procurement advice. It does not establish supplier rates, contract rights, payment milestones or Ulties support terms. Agree those separately in the actual proposal.