Your software project is over budget: how to tell the client

The delivery dashboard turns red on Thursday afternoon.

Your fixed-price software project has consumed 72% of its planned effort. Only four of nine acceptance milestones are complete. The tech lead now forecasts another six weeks of work.

On Friday, the client asks, “Are we still within budget?”

The delivery manager says the team is checking. Internally, everyone hopes the next sprint will recover the gap.

Hope is not a cost forecast.

To tell a client their software project is over budget, explain the confirmed financial position, distinguish client budget from agency margin, own the causes, recommend recovery options, and name the decision needed. Do it when the forecast crosses the boundary—not after the money is gone.

First confirm what “over budget” actually means

Software agencies often use “over budget” for three different problems:

• Agency margin erosion: delivery is consuming more internal effort, but the client's fixed price has not changed.
• Forecast budget overrun: the expected cost of completing the agreed work is higher than the approved client budget.
• Change-driven cost: new or changed work requires a separate commercial decision under the agreement.

Those situations may exist together, but they do not create the same client obligation. A poor estimate on a fixed-price contract does not automatically become an extra invoice. The contract, approved changes, and commercial decision determine who absorbs which cost.

The client conversation should therefore begin with a verified forecast, not a vague statement that the team has used “too many hours.” PMI defines estimate at completion as the expected total cost when the defined scope is finished, while estimate to complete is the expected additional cost from the current point. Those are useful internal controls even if you translate them into simpler language on the call.

If the forecast is only a weak signal, investigate it. If it is credible enough to change a client decision, communicate it. The BRIEF framework for trusted client status updates helps surface cost risk before it becomes a commercial surprise.

The COST framework when a software project is over budget

COST gives delivery managers and agency founders four moves for discussing a budget overrun without hiding the facts, blaming the client, or demanding money before explaining the decision.

1. Confirm the forecast

Before the call, reconcile delivery, finance, and commercial data. At minimum, know:

• The approved budget or fixed price.
• Actual and already committed cost.
• The current estimate to complete the agreed scope.
• The forecast total and variance.
• How confident the team is and which unknowns can still move the number.

Use numbers the client can trace:

“The approved delivery budget is $120,000. We have incurred or committed $86,000. Based on the remaining accepted scope, our current estimate to complete is $49,000, which puts the forecast at $135,000—a $15,000 variance. The largest remaining uncertainty is migration reconciliation, which can move that forecast by approximately $4,000.”

This is an example, not a magic template. Replace every number with reconciled project data and label ranges honestly.

Not:

“We have burned more hours than expected, so we may need extra budget.”

Instead:

“The forecast for completing the agreed scope now exceeds the approved budget by $15,000. Here is what changed, what remains uncertain, and the choices available.”

Hours describe agency consumption. The client needs to understand the forecast and what it means for the outcome they funded.

2. Own the cause and the boundary

A budget variance can come from several places:

• An agency estimate or solution assumption was wrong.
• Delivery created avoidable rework or quality failure.
• The client approved additional or changed scope.
• A client or third-party dependency changed the delivery plan.
• An external event introduced a new constraint.
• More than one of these happened.

Do not collapse the explanation into “scope creep,” especially when agency rework contributed. Do not collapse it into an apology either. The client needs a clean account of cause, commercial boundary, and corrective action.

“Of the forecast variance, $6,000 comes from our underestimation of the legacy rules engine, and we will absorb that amount. The remaining $9,000 relates to the client-approved addition of two distributor workflows. We should decide whether to fund those workflows now or defer one to the next phase.”

That sentence owns the agency miss without volunteering a contractual conclusion for unrelated change.

Trace each cause to evidence: the original assumption, approved requirement, change record, defect history, dependency date, or technical finding. The recent BRIDGE sales-to-delivery handoff framework shows why estimate assumptions and verbal promises need to survive the transition into delivery.

3. Show the choices

Bad budget news without a decision path leaves the client to invent one. Usually that invention is: “Finish everything for the original amount and date.”

Prepare two or three viable choices. Recommend one.

Do not offer “add more developers” as an automatic recovery plan. Extra people can increase coordination cost and may not shorten work that depends on one architecture decision, one data source, or one client approver.

A useful recommendation sounds like this:

“We recommend protecting the November distributor launch by keeping the core order journey and deferring advanced reporting to phase two. That keeps the approved budget within a $2,000 range and preserves the business outcome. If reporting must launch now, the revised budget is $129,000 and the decision is needed by Tuesday.”

When new work is part of the variance, use the CLEAR approach to make scope-change trade-offs visible instead of turning the budget call into a contractual argument.

4. Tie the decision to a checkpoint

A tense call can feel productive while leaving the project commercially undefined.

Close with four specifics:

1. Which option is being recommended.
2. Who has authority to approve it.
3. When the decision is required.
4. What work continues or pauses until then.

“James will confirm the reporting decision by Tuesday at 17:00 ET. Until then, the team will continue the core order journey and pause new reporting work. We will issue the written change summary today and refresh the forecast after the decision.”

If the client cannot decide on the call, do not convert silence into approval. Document the options, impacts, recommendation, and interim boundary.

What the full conversation sounds like

“We need to discuss the cost forecast for the distributor portal. The approved delivery budget is $120,000. Based on incurred commitments and the remaining accepted scope, our current forecast is $135,000. We have separated the variance into two parts. We underestimated the legacy rules-engine work by $6,000, which we will absorb. Two workflows added after scope approval account for the remaining $9,000. We recommend keeping the core ordering outcome within the current launch window and moving advanced reporting to phase two; that keeps the client budget within a $2,000 forecast range. If both new workflows must remain in the first release, we need a $9,000 change approval by Tuesday. I will walk through the evidence and both plans, then we can decide which priority to protect.”

The opening does not bury the number. It also does not present an invoice before explaining agency ownership, change evidence, and viable choices.

Prepare the agency before the client call

Reconcile one financial story

Delivery hours, finance costs, proposal assumptions, and client invoices often live in different systems. Resolve discrepancies before the call. If the agency gives three versions of the number, the client will reasonably trust none of them.

Assign conversation ownership

The delivery manager should explain delivery evidence. The account owner or founder should handle commercial boundaries. The tech lead should answer feasibility questions. Decide who leads and who speaks only when invited.

Stress-test the recommendation

Ask what happens if the client refuses extra budget, refuses reduced scope, or insists on the original date. A recommendation is not ready until the team understands its fallback and stop-work boundary.

Check the agreement

Review fixed-price terms, time-and-materials controls, change approval, notice requirements, acceptance, and client dependencies. Communication advice cannot replace the actual contract or legal review where needed.

What software agencies get wrong

Waiting until the budget is exhausted

Actual cost tells you where the money went. A credible completion forecast tells you when a decision can still change the outcome. PMI's budget-overrun guidance emphasises opening communication as part of responding to the problem.

The percentage without the consequence

“We are 12% over” is not enough. State whether the variance changes approved spend, agency margin, remaining scope, delivery date, or all four.

The blame ledger

A detailed list of late client replies can be relevant evidence. Reading it as an accusation makes agreement harder. Explain the dependency, recorded commitment, forecast impact, and decision required.

The surprise change order

Sending a commercial document before the client understands the variance turns a delivery problem into a trust problem.

The magical recovery sprint

Teams sometimes promise to “make it up” without changing scope, method, staffing, or constraints. A recovery plan must show what mechanism changes the forecast.

The discount that hides the control failure

Absorbing an agency miss may be the right commercial choice. Doing it silently prevents the agency from correcting estimation, handoff, or delivery controls.

Frequently asked questions

When should you tell a client a software project is over budget?

Tell the client when a verified completion forecast credibly exceeds the approved budget or a commercial boundary. Do not wait for actual spend to exhaust the budget if a decision can still reduce the impact.

Does a project overrun mean the client must pay more?

No. Payment depends on the agreement, approved scope changes, responsibility for the variance, and the commercial decision. Distinguish agency margin erosion from a change to the client's approved budget.

What should a budget-overrun update include?

Include approved budget, actual and committed cost, estimate to complete, forecast variance, cause, confidence and unknowns, contractual boundary, recommended options, decision owner, and decision date.

How much financial detail should you share with the client?

Share enough evidence to explain the forecast and support the decision. Internal salary, margin, or utilisation detail may not be relevant or appropriate; align disclosure with the commercial model and agreement.

Should you apologise when a software project goes over budget?

Acknowledge impact and own agency mistakes directly. Then explain the evidence, correction, and decision path. An apology without a mechanism does not control the overrun.

A cost report cannot rehearse the difficult questions

The hardest part begins when the client asks why they should pay for an estimate error, refuses every trade-off, questions earlier status reports, or demands the full scope for the original amount and date.

PitchDawn lets delivery managers, tech leads, and agency founders practise budget and difficult-client conversations with AI stakeholders who challenge the forecast and ownership in real time. The debrief helps reveal whether you hid the number, blamed the client, confused margin with budget, or ended without a decision.

Explore realistic IT-services and consulting scenarios on the PitchDawn industries page.

Start your first budget-conversation practice session free — no card required.