Should You Approve More Software Funding?

What the Next Funding Decision Requires

The decision to approve more software funding can become uncomfortable when a project has already exceeded its original budget. Your development team needs more money, the supplier believes the work remains worthwhile, and the executive team must decide whether another investment will produce a useful business outcome.

The real question is not simply whether the organisation can afford another invoice. It is whether the additional funding is justified by credible evidence, a realistic delivery plan and benefits that still matter to the business.

For a CEO, CFO or board member, that decision should be based on more than assurances that the project is nearly finished.

Takeaways

Why More Funding Needs Justification

Additional funding is not automatically evidence of failure.

Software projects operate in changing business environments. New customer requirements may emerge, regulations may change, or a company may discover opportunities that were not included in its original investment proposal.

An approved change in scope can justify an increase in funding. An unexplained overspend is a different matter.

The distinction is important because the two situations require different management responses.

Approved Changes Versus Overspending

Consider two projects.

In the first, a company decides to expand its customer platform to support another business division. The additional functionality was not included in the original scope. Management understands the investment, assesses the expected benefits and approves a revised budget.

In the second, a development supplier announces that the existing functionality will cost more than expected. Delivery dates have moved, completed work is difficult to verify, and the revised estimate contains little supporting detail.

Both projects require more money.

Only the first has a clearly explained business reason for the increase.

For the second, I would want to understand the causes of the overspend before recommending another financial commitment.

Don’t Confuse Progress With Value

A software team can be busy without delivering a usable business outcome.

Developers may have completed technical components, resolved defects and spent months improving the architecture. Some of that work may be necessary.

However, it does not automatically mean the organisation is closer to receiving the capability it intended to purchase.

Business value depends on whether the software can support a defined operational or commercial objective.

For example, a manufacturing business investing in a production management system might expect to reduce manual scheduling, improve inventory visibility and give managers more reliable production information.

A report showing that 80% of development tasks are complete does not demonstrate that those outcomes can be achieved.

Before approving additional funding, leadership needs evidence of what the software can actually do.

Evidence to Request Before Approval

A credible software funding request should explain the current financial position, the delivery status and what the additional investment will achieve.

The information should be presented clearly enough for a non-technical executive to challenge the assumptions.

I would start with seven areas.

Evidence required	What leadership needs to establish
Approved budget baseline	What was originally authorised, including approved changes
Actual expenditure	How much has been spent to date
Committed costs	What the business is already contractually committed to paying
Completed deliverables	What has been built, tested and accepted
Remaining scope	What still needs to be delivered
Outstanding defects and risks	What could prevent the software from being usable
Revised forecast	The estimated total cost and realistic completion date

These figures and explanations should reconcile. If they do not, management should understand why before proceeding.

Establish the True Financial Position

Start by separating expenditure into three categories.

Actual costs are expenses already incurred.

Committed costs are obligations the business has accepted but may not yet have paid.

Forecast costs are the estimated expenditure needed to finish the remaining work.

This distinction prevents a common misunderstanding.

A project might have spent $400,000, but that does not necessarily mean the business can cancel tomorrow without additional financial obligations.

Existing contracts, supplier commitments, licences and termination provisions may affect the available options.

Likewise, a request for another $100,000 might exclude testing, data migration, staff training or ongoing operating costs.

The funding decision should consider the total expected cost to achieve the intended business outcome, not merely the next development invoice.

Verify What Has Been Delivered

Project status reports can be useful, but leadership should seek evidence of completed work.

That might include working demonstrations, accepted features, successful tests or software already operating in a controlled environment.

Ask which deliverables are ready for business use and which remain incomplete.

It is worth separating three categories:

• Completed and accepted work.
• Developed work awaiting testing or business acceptance.
• Work that has not yet been completed.

A feature should not be treated as fully delivered simply because the development team has finished writing its code.

Integration, security, performance, operational readiness and user acceptance may still need attention.

Challenge the Revised Estimate

A revised forecast should explain how the remaining estimate was produced.

Did the supplier reassess the actual work? Were assumptions tested? Have unresolved technical problems been included? Is the forecast based on recent delivery performance?

If a project has repeatedly missed deadlines, I would be cautious about accepting another completion date without understanding why the new forecast is more credible.

A useful estimate should include assumptions, dependencies, material risks and a reasonable allowance for known uncertainty.

Precision alone is not evidence of accuracy.

A supplier presenting a completion date of 17 March does not necessarily have a better forecast than one explaining that delivery is expected during March, subject to identified dependencies.

Will More Money Deliver Business Value?

Software funding should be assessed against the business outcomes it is expected to create.

The original business case provides a starting point, but that case may no longer reflect current conditions.

Market expectations change. Operating priorities evolve. The company’s financial position may be different from when the project began.

Before approving more expenditure, leadership should establish whether the original investment still makes sense.

Revisit the Business Case

The business case should connect the proposed software with a measurable business need.

Depending on the project, that might involve revenue, operating efficiency, compliance, customer service or reduced business risk.

Ask four questions:

1. What business problem was the investment intended to solve?
2. Does that problem still exist, and is it still important?
3. What usable capability will the next funding commitment deliver?
4. How will the business know whether the expected benefit has been achieved?

These questions help distinguish investment in business capability from expenditure on development activity.

For example, an organisation may have originally planned to replace several disconnected systems with one platform.

If additional funding will deliver an operationally useful integration that reduces manual work, there may be a reasonable commercial argument for continuing.

If the proposed investment only produces another incomplete technical component, management needs to understand how that component contributes to the final outcome.

Consider the Cost of Delay

Stopping expenditure can reduce immediate cash requirements, but delay also has consequences.

A retailer may continue relying on manual inventory processes. A financial services business may delay the release of a customer platform. A healthcare provider may need to retain inefficient administrative processes.

These costs should be considered, not assumed.

I would want business stakeholders to explain the actual consequences of waiting another three or six months.

That might include additional operating expenditure, delayed revenue, supplier costs or an increased workload for employees.

Any financial estimates should be supported by reasonable assumptions.

The objective is not to manufacture a larger benefit figure to justify the project. It is to understand the commercial choices.

Ignore the Sunk Cost Trap

Money already spent is not a reason to approve more.

Past expenditure matters when understanding the project’s history, but the next decision should focus on future costs, benefits and risks.

A business that has invested $500,000 does not automatically have a sound reason to invest another $150,000.

Equally, abandoning the work purely because the original budget was exceeded may destroy value that could still be recovered.

The right question is:

From our position today, which decision offers the best realistic business outcome?

That is a much better basis for executive judgement than trying to defend earlier decisions.

A $150,000 Funding Request

Consider a hypothetical Australian business developing an internal software platform.

The board originally approved a budget of $500,000. Development has progressed, but the system is not ready for operational use.

Management now receives a request for another $150,000.

The supplier explains that the project requires further integration work, additional testing and changes to functionality that proved more complex than expected.

The board must decide whether to approve the increase.

The following figures are illustrative and do not represent an actual client engagement.

Review the Financial Position

Assume the current position is:

Financial measure	Hypothetical amount
Original approved budget	$500,000
Expenditure to date	$480,000
Unspent original budget	$20,000
Additional funding requested	$150,000
Revised total budget	$650,000
Increase over original budget	30%

The new request raises the project’s total authorised budget by 30%.

That increase deserves scrutiny, but its size alone does not determine whether it is justified.

The board still needs to understand what has been delivered and how reliable the new forecast is.

If the additional $150,000 is intended to fund the remaining work, management should establish whether the $20,000 unspent balance is included in the supplier’s calculation. For this example, assume the revised total of $650,000 includes the existing balance.

The board must also establish whether there are any additional committed costs outside these figures.

Examine the Remaining Work

Suppose the supplier reports that the main application is largely developed.

However, several important matters remain unresolved:

• Data migration has not been fully tested.
• Integration with an existing finance system is incomplete.
• User acceptance testing has identified important defects.
• The operational support arrangements have not been confirmed.
• The proposed completion date depends on resolving outstanding technical issues.

These are material concerns because the business cannot obtain the expected benefits until the software is ready for use.

The board should ask for a revised delivery plan identifying the work required, expected acceptance criteria, dependencies and forecast expenditure.

It should also consider whether business stakeholders agree that the remaining features are essential.

Evaluate the Investment Decision

Suppose the review establishes that the core application works, most of the essential functionality is complete and the remaining integration work is achievable.

The revised funding request may be commercially reasonable.

However, if important components remain untested, estimates are unsupported or technical risks are poorly understood, immediate unconditional approval would expose the business to further uncertainty.

The board has options.

It could approve funding in stages, require a narrower delivery scope or commission an independent assessment before making a larger commitment.

The aim is not to punish a supplier for exceeding an estimate. It is to make a sound decision about the next $150,000.

Compare Your Recovery Options

When additional software funding is requested, leadership should consider alternatives rather than treating the supplier’s preferred plan as the only choice.

Three options commonly deserve consideration.

Option	When it may be suitable	Main concern
Fund the current plan	Delivery evidence and the revised forecast are credible	Further costs if assumptions prove wrong
Reduce or phase scope	Essential business value can be delivered sooner	Deferred functionality and possible rework
Commission an independent review	Delivery status or remaining costs are uncertain	Review cost and a short decision delay

Option 1: Fund the Current Plan

Continuing the existing plan can be sensible when the problems are understood and the remaining work is achievable.

The team may have valuable knowledge of the software. Switching suppliers could introduce additional cost and delay.

Approval should still be linked to a documented plan and clear responsibilities.

The business needs to know what success looks like and how progress will be demonstrated.

Option 2: Reduce or Phase the Scope

Sometimes the most practical response is to deliver less software.

That does not mean accepting poor quality or abandoning essential safeguards.

It means distinguishing between functionality that the business needs immediately and features that can be deferred.

For example, an internal platform might support essential operational processes without every planned reporting feature or workflow enhancement.

A phased release may allow employees to begin using the system and the organisation to test whether the expected benefits are achievable.

This approach requires careful assessment of technical dependencies, operational readiness and the cost of later enhancements.

Option 3: Seek Independent Assurance

An independent review becomes valuable when management cannot confidently establish the project’s current position.

This is particularly relevant when the same supplier requesting additional funds is also responsible for assessing its own delivery performance.

That does not imply dishonesty or incompetence.

Suppliers can have legitimate technical explanations for changing estimates. However, they also have commercial interests and may interpret uncertainty differently from the organisation funding the project.

An independent assessment provides another perspective.

The review should focus on the decision management needs to make, rather than producing an exhaustive catalogue of every possible technical issue.

The question might be whether the current platform is worth completing, whether the revised cost is credible or whether another delivery approach offers a better result.

For organisations facing this uncertainty, an independent Software Development & Delivery Review can examine progress, delivery practices, estimates and technology risks to support a more informed decision.

Who Is Accountable for the Budget?

A software funding decision should have a clearly identified owner.

That person might be the CEO, a business sponsor, an executive committee or the board, depending on the organisation’s governance arrangements.

The supplier should be accountable for its delivery commitments. The project manager should provide reliable information about progress and risks. Finance should validate the financial position.

However, someone within the business must remain accountable for deciding whether the investment continues.

This responsibility cannot simply be delegated to the development team.

Define Funding Approval Gates

A funding approval gate is a decision point where management assesses whether agreed conditions have been met before releasing additional money.

The idea is straightforward.

Instead of approving the entire additional budget without conditions, the organisation can link funding to defined delivery outcomes.

The Australian Government’s Gateway assurance approach provides a useful example of reviewing projects at critical decisions, including investment approval, readiness for service and benefits realisation.

Private businesses can apply similar principles without adopting the full public-sector framework.

For the hypothetical $150,000 request, management might consider staged funding linked to:

1. Validation of the remaining scope and delivery forecast.
2. Completion and acceptance of the essential integrations.
3. Successful user acceptance testing.
4. Demonstrated operational readiness.

The exact funding amounts should reflect the work involved and the organisation’s commercial commitments.

Approval conditions must be realistic. A development team cannot reasonably demonstrate completed integration testing before the necessary integration work has been funded.

The purpose is to create useful decision points, not impossible conditions.

Set Spending Limits and Controls

Additional funding approval should establish who can authorise expenditure and what happens when the forecast changes.

Useful controls include:

• A documented maximum approved budget.
• Named decision-makers and approval limits.
• Clear rules for changes in scope.
• Regular reporting on actual and forecast expenditure.
• Escalation when agreed cost or delivery thresholds are exceeded.
• Defined acceptance criteria for funded deliverables.

These controls need to be proportionate to the project.

A $150,000 extension to a software project does not require the governance overhead of a billion-dollar infrastructure program.

It does require management to know who is making decisions and on what evidence.

Make Acceptance Criteria Measurable

Funding approval should not depend on vague milestones such as “development substantially complete” or “system almost ready“.

These statements leave too much room for interpretation.

Better criteria describe observable results.

For example, a data migration milestone might require the successful transfer and reconciliation of an agreed dataset, with specified exceptions documented and accepted.

An integration milestone might require agreed business transactions to pass defined tests in an appropriate environment.

Acceptance should involve the people who understand how the business will use the software.

That matters because technically completed work is not necessarily operationally useful.

Warning Signs Before Approving Funds

Certain patterns should prompt closer examination before more money is committed.

One warning sign rarely tells the whole story. A combination of unresolved issues is more concerning.

Estimates Keep Changing

Software estimates naturally become more accurate as uncertainties are resolved.

However, repeated increases without credible explanations suggest that the planning process needs attention.

Management should ask what has changed and whether the revised estimate incorporates what the team has learned.

If previous forecasts were unreliable, the business needs a reason to trust the next one.

Delivery Evidence Is Limited

A supplier may provide detailed reports on hours worked, tasks completed and meetings held.

That information has a place.

However, it cannot replace evidence that the business is receiving usable functionality.

If the project repeatedly consumes budget without producing demonstrable progress, leadership should investigate.

Risks Are Raised Too Late

A technical dependency might have existed for months but only become visible when a major milestone is missed.

Sometimes this happens because the issue was genuinely difficult to discover.

In other cases, the project may lack effective risk management, communication or technical oversight.

The question is not simply why the issue occurred. It is what has changed to prevent the same problem affecting the revised plan.

Nobody Owns the Decision

When responsibilities are unclear, funding decisions become reactive.

Finance may assume technology has validated the estimate. Technology may assume the business has approved the scope. The supplier may believe its role is to implement every requested change.

Meanwhile, the project continues consuming money.

Clear accountability helps prevent this.

For businesses already experiencing repeated overruns, the wider problem of software costs getting out of control may need attention alongside the immediate funding decision.

When an Independent Review Helps

An independent review is appropriate when the amount at risk, uncertainty or potential business consequences justify another experienced perspective.

It does not need to be adversarial.

The objective is to give the business reliable information about its options.

An independent review can be particularly useful when:

• The latest funding request is not supported by a credible forecast.
• Management cannot verify what has been delivered.
• The supplier and internal stakeholders disagree about progress.
• The project has repeatedly missed important milestones.
• Technical explanations are difficult to assess commercially.
• Leadership is considering changing suppliers or abandoning the project.
• The proposed additional investment is material to the organisation.

I would start by establishing the specific decision the organisation needs to make.

If the question is whether the remaining work can be delivered for the revised price, the review should examine the delivery evidence, assumptions, technical dependencies and risks relevant to that decision.

There may be no reason to conduct an exhaustive review of every system and process.

Work With the Existing Team

A useful independent assessment should consider the perspectives of both the organisation and the people delivering the software.

Developers may understand technical limitations that have not been communicated clearly to management.

Business stakeholders may have changed priorities without appreciating the effect on the delivery plan.

The review should test these explanations rather than assume either group is responsible for the problem.

I believe strongly in people before technology.

An effective review should create understanding, improve decisions and help capable people work together.

It should not become an exercise in assigning blame.

When Ongoing Governance Is Needed

An independent review can help resolve an immediate funding question.

However, repeated uncertainty about technology investment may indicate a wider management problem.

If a business regularly struggles to assess supplier estimates, control delivery priorities or understand technology risks, another one-off review may not address the underlying issue.

The organisation may need continuing technology leadership.

For an established business, that could involve strengthening the existing technology management team, improving executive reporting or establishing clearer investment governance.

It may also involve independent senior leadership through Fractional CTO services.

The appropriate response depends on the organisation’s capabilities, risk exposure and management structure.

Separate Advice From Delivery Oversight

An independent assessment should help answer a defined question.

Ongoing Project Delivery consulting addresses a different need: maintaining visibility, improving priorities, managing suppliers and supporting delivery decisions as work progresses.

A business might need both, but they are not automatically connected.

For example, the organisation may discover that its existing team can complete the project successfully with clearer priorities and stronger internal governance.

Alternatively, it may need experienced independent oversight until delivery becomes more predictable.

The aim should be to introduce the level of leadership the business actually needs.

Frequently Asked Questions

Should We Approve More Software Funding?

Approve more software funding when the revised investment is supported by credible delivery evidence, an achievable forecast and a business case that remains worthwhile. Do not rely solely on the amount already spent or assurances that completion is close.

What Evidence Should a CFO Request?

Request the approved budget, actual expenditure, committed costs, completed deliverables, remaining scope, outstanding risks and a revised total cost forecast. The information should explain what the additional funding will deliver and how progress will be verified.

Can We Approve Funding in Stages?

Yes. Staged approvals can help manage uncertainty when each funding release is linked to realistic delivery milestones and measurable acceptance criteria. The arrangement should also account for supplier contracts and the cost of reaching each milestone.

When Should We Stop Funding a Project?

Consider stopping or materially changing the project when the remaining costs and risks outweigh the expected future benefits, or when a credible delivery path cannot be established. The decision should consider contractual obligations, alternative approaches and the consequences of stopping.

When Is an Independent Review Worthwhile?

An independent review is useful when management lacks confidence in the delivery status, revised forecast or technical explanations behind a material funding request. The review should be proportionate to the financial exposure and focus on the decision leadership needs to make.

Make the Next Funding Decision Count

Approving additional expenditure may be the right commercial decision, but management should understand what it is purchasing and how the expected benefits will be achieved. If delivery evidence is uncertain, I can provide an independent Software Development & Delivery Review to help you assess the current position and your realistic options before committing further funds. Before you approve more software funding, establish whether the proposed investment is genuinely justified.