How Much Will Your Software Project Cost to Complete?

Forecast the Real Cost of Finishing

Your software project cost to complete can be difficult to establish when development has consumed much of the approved budget, but important features remain unfinished. Your team may be confident that delivery is close, yet nobody can explain how much additional investment is required.

For business leaders, this creates a difficult decision. Do you approve more funding, reduce the scope or reconsider the project? A credible forecast starts with evidence of what has been delivered, a realistic assessment of the work remaining and a clear understanding of the financial risks.

Takeaways

Why Original Cost Estimates Lose Value

The original budget represents what the business expected the project to cost before development began. It is not necessarily a reliable measure of what the project will cost today.

Software development involves decisions, dependencies and discoveries that affect the work required. Requirements become clearer. Integrations prove more complicated than expected. Testing reveals problems that need correcting. Business priorities also change.

None of these developments automatically indicates poor performance. However, they can make the original estimate less useful as a basis for future investment decisions.

Consider a business that approved $300,000 to develop a platform for its operations. Six months later, it has spent $240,000. The supplier reports that the project is 80% complete.

It might be tempting to assume the remaining work will cost $60,000.

Unfortunately, that conclusion depends on the reported percentage being accurate and the final 20% costing no more than expected.

Neither assumption has been established.

The unfinished work might include a complex integration, unresolved defects and substantial acceptance testing. These activities could require more time and money than the development completed so far.

The money already spent tells you where the project has been. It does not tell you what it will cost to finish.

A reliable forecast requires a fresh assessment of the remaining work, rather than simply subtracting expenditure from the original budget.

Why Percentage Complete Can Mislead

A project reported as 90% complete may still be months away from an operational release.

The problem is how completion is measured.

Developers may report progress against tasks, hours worked or features coded. Business leaders often interpret that figure as the proportion of the finished product that is ready to use.

These are different measures.

A feature that has been coded but not tested may still require substantial work. A payment integration that functions in a development environment may not yet be ready to handle real transactions.

I would be cautious about relying on a completion percentage unless the team can explain the evidence behind it.

For an executive, a more useful question is:

What can the business confidently use today, and what remains before the software is ready for its intended purpose?

Understand What Remains Unfinished

Before estimating additional costs, establish what remains to be delivered.

This sounds straightforward, but it can become complicated when the project plan has changed repeatedly or completed tasks have not been independently verified.

A useful starting point is to divide the project into four categories:

1. Completed and accepted: Software that meets the agreed requirements and has been demonstrated or tested.
2. Developed but not accepted: Features that exist but still require testing, correction or business approval.
3. Not yet developed: Requirements that remain entirely or substantially unfinished.
4. Unresolved or unknown: Technical problems, dependencies and decisions that could change the remaining effort.

This provides a more useful starting position than a single progress percentage.

Review Working Software

I would begin by asking the development team to demonstrate the software against the agreed business requirements.

The purpose is not to assess how impressive the interface looks. It is to establish whether the functions the business needs actually work.

For example, a customer management platform might display customer records correctly but still be unable to synchronise information with the company’s accounting system.

From a business perspective, that integration may be essential.

A demonstration should therefore cover realistic business activities rather than isolated features.

Ask whether the software can complete an important process from beginning to end.

For a subscription business, that might mean registering a customer, approving an application, setting up a subscription, processing payment and updating financial records.

A broken step can prevent the entire process from being usable.

Identify Hidden Dependencies

Some remaining costs are difficult to see because the work sits outside the immediate development backlog.

Examples include:

• Access to third-party systems or supplier APIs.
• Decisions about existing business processes.
• Data quality and migration requirements.
• External security assessments.
• Infrastructure configuration and deployment approvals.
• Outstanding technical design decisions.
• Availability of business staff for testing and sign-off.

A project may appear to have little development work remaining while these dependencies prevent completion.

Each dependency should have an owner, a current status and an estimated effect on cost and delivery.

Unresolved assumptions should be recorded as uncertainty, not quietly treated as completed work.

Rebuild a Credible Cost Forecast

A credible software budget forecast separates historical expenditure from future obligations.

There are four financial figures leadership should understand.

Financial measure	What it tells you
Actual costs	Expenditure already incurred, whether paid or accrued
Committed outstanding costs	Contractual commitments for future work or services not yet recognised in actual costs
Estimated additional costs	Forecast costs of remaining work not already included in outstanding commitments
Total forecast cost	The expected total expenditure when the agreed project scope is complete

The important distinction is between money already incurred, money the business is committed to spending and additional money that may still be needed.

Calculate the Total Forecast Cost

For a practical financial forecast, use:

Forecast total cost = Actual costs + Committed outstanding costs + Estimated additional costs to complete

The remaining funding requirement is:

Remaining funding required = Committed outstanding costs + Estimated additional costs to complete

These calculations assume that each cost is included only once.

If a supplier’s outstanding commitment already covers specific development work, that work must not appear again as an additional forecast cost.

Similarly, an unpaid invoice for work already performed belongs in actual incurred costs. It should not be counted again as future expenditure.

The distinction matters because double counting can make a project appear more expensive than it really is.

Example: A Project Already Over Budget

Consider an established Australian business developing a software platform to replace several disconnected operational systems.

The original approved project budget was $300,000.

After reviewing its financial records and the remaining technical work, the business identifies the following figures.

Cost component	Amount
Original approved budget	$300,000
Actual costs incurred	$240,000
Outstanding committed costs	$30,000
Additional development	$65,000
Testing and defect correction	$20,000
Data migration and deployment	$15,000
Total forecast cost	$370,000

These figures are hypothetical and exclude any further contingency.

The project has $130,000 of expenditure remaining, including existing commitments.

Its total forecast cost is $370,000, which is $70,000 above the original budget.

This is a more useful position than simply reporting that $240,000 has been spent.

It gives the board three figures it can act upon:

• The original investment approval was $300,000.
• The current expected total is $370,000.
• The remaining funding requirement is $130,000.

Leadership can now assess whether the additional investment is commercially justified.

The forecast does not establish that the project should continue. It establishes the financial question that needs answering.

Account for Testing and Launch Costs

A frequent source of budget uncertainty is the work required after the main software features have been developed.

Completion involves more than writing code.

The software needs to work reliably in the environment where employees, customers and suppliers will use it.

Testing and Defect Correction

Testing should be considered throughout development, not treated as an activity that begins when everything else is finished.

The remaining forecast should account for:

• Functional testing against business requirements.
• Integration testing between connected systems.
• Regression testing after changes.
• Performance testing where capacity matters.
• Security testing appropriate to the system’s risks.
• User acceptance testing by the business.
• Correction and retesting of outstanding defects.

Existing defects should be assessed by their severity and impact.

A minor display issue is different from an error that creates incorrect invoices or exposes customer information.

The forecast should also consider the possibility of additional defects being discovered during testing.

Do not assume every defect can be predicted. Instead, make reasonable allowances based on the system’s current quality and the evidence available.

Migration and Deployment

Moving software into production introduces another group of activities.

A replacement business system may require historical data to be cleaned, transferred and reconciled.

The business may need to prepare infrastructure, configure access controls, establish backups and confirm that recovery procedures work.

A production release may also require coordination with external providers.

These activities can involve specialists outside the main development team.

Where the project replaces an existing system, the forecast should account for any period during which both systems must operate.

Operational Readiness

The project is not truly finished if the software has been deployed but nobody is prepared to operate it.

Consider:

• Staff training and updated procedures.
• Administrator and support documentation.
• Monitoring and incident response arrangements.
• Ownership of ongoing maintenance.
• Support agreements and supplier handover.
• Business continuity and recovery preparation.
• Final acceptance and responsibility for outstanding issues.

These are not optional extras when they are necessary to achieve the intended business outcome.

Ongoing operating costs should also be shown separately from the one-off cost of completing the project. A board needs to understand both the investment required to launch and the recurring cost of running the software.

Build Low, Expected and High Forecasts

A single cost estimate can create false confidence.

Software projects contain uncertainties that cannot always be resolved before further work begins.

A better approach is to prepare three scenarios.

Scenario	Meaning	Illustrative total
Low	Remaining work proceeds with limited disruption	$340,000
Expected	Most likely outcome based on current evidence	$370,000
High	Material risks and additional work increase costs	$430,000

These are hypothetical figures for the same project.

They are not statistical confidence limits or probabilities.

A useful forecast explains why the figures differ.

For example, the low scenario might assume that all remaining integrations work as designed and testing identifies only minor defects.

The expected scenario might allow for moderate rework and additional testing.

The high scenario might include extensive integration changes, data quality issues and a longer period of supplier involvement.

Each assumption should be visible.

Identify the Main Cost Drivers

Rather than applying an arbitrary percentage to every estimate, consider the risks that could materially affect expenditure.

These might include:

Unclear requirements: The business has not agreed on what must be delivered before launch.

Poor software quality: Correcting existing defects may take longer than expected.

Supplier dependencies: Work depends on external organisations that have their own schedules and commercial arrangements.

Limited development capacity: The forecast assumes people will remain available when competing commitments may affect their capacity.

Technical uncertainty: Parts of the system have not been adequately tested or understood.

Changing business needs: New requirements continue to enter the project without corresponding decisions about scope and cost.

For each risk, estimate its possible financial effect and explain how the assumption has been reached.

The US Government Accountability Office’s Cost Estimating and Assessment Guide identifies comprehensive scope, documented assumptions, accuracy and credibility as characteristics of reliable cost estimates.

The principles are useful for commercial software projects even though the guide was developed for government programmes.

Use Scenarios for Funding Decisions

The expected forecast provides a working financial position.

The high scenario helps leadership understand its potential exposure.

A CFO may be comfortable with the expected cost but unwilling to approve the high scenario without further evidence.

That is a reasonable distinction.

The business could authorise a limited amount of work to resolve the largest uncertainty before approving the full remaining budget.

This is often more useful than treating the entire forecast as a single funding request.

Use Actual Delivery to Update Estimates

One of the strongest sources of forecasting evidence is the development team’s recent performance.

If the project has been running for months, there should be information about the amount of work completed and the resources required.

The objective is not to criticise the team for missing an old estimate. It is to use current evidence to make a better prediction.

Review Completed Work

Examine a representative period of recent delivery.

Ask:

• Which features were accepted by the business?
• How much work was completed?
• How much was spent?
• How much time went into defect correction?
• Which planned items were carried forward?
• What unplanned work appeared?
• Have the team and supplier arrangements changed?

The answers help establish a realistic delivery rate.

A team may consistently complete fewer items than originally planned. That information matters when estimating how long the remaining work will take.

However, not all tasks are equal. Counting completed tickets without considering their complexity can be misleading.

Where teams use Agile delivery methods, historical throughput or velocity can support forecasts, provided the remaining work is estimated consistently.

The Agile Manifesto places emphasis on working software and responding to change. These principles are particularly relevant when evaluating actual delivery rather than relying entirely on an outdated plan.

Convert Delivery Rates into Costs

Consider a team that has consistently completed approximately $20,000 worth of project expenditure per month.

If the verified remaining work is expected to require four months at the current capacity, the baseline future expenditure might be around $80,000.

That is a starting calculation, not a final estimate.

It must be adjusted for changes in team composition, one-off activities, external supplier charges and work that is unlike anything previously completed.

If the remaining scope includes substantial integration or migration activities, recent development performance may not be representative.

The key is to distinguish what historical evidence supports from what still depends on assumptions.

Update the Forecast Regularly

An estimate should change when better evidence becomes available.

I would expect a project with material financial exposure to maintain a current cost-to-complete forecast, reviewed at intervals appropriate to its delivery and reporting cycle.

The forecast should show:

Measure	Why it matters
Previous forecast	Establishes the earlier expectation
Current forecast	Shows the latest expected total
Change in forecast	Makes financial movement visible
Reason for change	Explains the underlying cause
Remaining uncertainties	Identifies what could change again
Required decisions	Gives leadership an action to consider

This creates a clearer conversation between development, finance and executive leadership.

Instead of reporting only that the project remains on track, the team can explain what has changed and what those changes mean financially.

Set Funding Limits and Review Points

Once the cost forecast is credible, the next question is whether the business should approve the remaining investment.

The answer should not depend solely on how much has already been spent.

Money already committed or incurred cannot automatically justify spending more.

The relevant decision is whether the expected future business value outweighs the costs and risks of continuing.

Separate Past Spend from Future Value

Consider the earlier example.

The business has already incurred $240,000 and expects another $130,000 of expenditure to complete the project.

The decision is not whether the original $300,000 approval was correct.

That decision belongs to the past.

Leadership must now decide whether spending the remaining $130,000 is preferable to the available alternatives.

The potential benefits might include reduced manual administration, improved customer service, better reporting or replacing costly legacy systems.

Those benefits need to be examined against the remaining investment and the risk that delivery will cost more than expected.

If the software no longer provides a convincing business case, stopping or reducing the scope may be appropriate even when substantial money has already been spent.

Consider Your Funding Options

There are four broad choices.

Option	When it may be appropriate
Continue as planned	Remaining scope, cost and expected value are credible
Reduce scope	Essential business outcomes can be delivered with less work
Pause and reassess	Material uncertainty prevents a responsible funding decision
Stop or replace the approach	Future costs and risks outweigh likely benefits

There is no universal answer.

A scope reduction may allow the business to launch the most valuable functions while deferring less important features.

A short pause might allow testing or a technical investigation to establish whether a critical integration is viable.

Replacing a supplier or rebuilding the system may sometimes be justified, but those decisions introduce their own costs and risks.

If the project is also experiencing repeated delays, my guide to a software project running late explains the delivery problems that leadership should investigate.

Use Staged Funding Approvals

A business does not always need to authorise every remaining dollar at once.

Instead, it can establish funding stages linked to verifiable outcomes.

For example:

Stage 1: Confirm the remaining requirements, demonstrate existing functionality and assess critical technical risks.

Stage 2: Complete the essential development and integrations required for a viable release.

Stage 3: Complete acceptance testing, migration and operational preparation.

Stage 4: Authorise production deployment when agreed readiness criteria have been met.

Each stage should have a clear funding limit, accountable owner and decision point.

The aim is to preserve management control without creating unnecessary bureaucracy.

Staged approval is particularly useful when the high forecast differs materially from the expected outcome.

It allows leadership to invest in reducing uncertainty before making a larger commitment.

Know When an Independent Review Helps

Not every uncertain software forecast requires an external consultant.

If the internal technology team can demonstrate completed functionality, explain remaining work and produce a credible forecast supported by evidence, leadership may already have what it needs.

Independent advice becomes more valuable when the financial decision is material and the available information is incomplete, disputed or difficult to verify.

Warning signs include:

• The supplier cannot explain how the remaining estimate was calculated.
• The project is repeatedly described as nearly finished.
• Additional funding requests arrive without a revised delivery forecast.
• Development progress cannot be demonstrated against agreed requirements.
• The project plan does not account for testing and deployment.
• Financial reporting does not reconcile with supplier commitments.
• Different stakeholders report different completion expectations.
• Leadership is considering replacing the development company.

One warning sign does not prove a project is failing.

The concern is whether management can make a sound decision using the information available.

What Should an Independent Review Examine?

I would start with the evidence rather than the explanations.

That includes the agreed requirements, current backlog, delivery history, accepted functionality, outstanding defects and available financial records.

The review should consider whether the remaining work has been identified and whether the forecast reflects a realistic approach to completing it.

It should also distinguish delivery issues from commercial or governance problems.

For example, a development supplier might be performing reasonably well against instructions that have changed repeatedly.

In that situation, replacing the supplier may not address the underlying problem.

The business may instead need clearer requirements, better decision rights and stronger control over scope changes.

An independent assessment can help determine which issues are technical, which are organisational and which relate to supplier performance.

Make the Next Investment Decision Clearer

White Internet Consulting’s Software Development Review is designed to help business leaders understand delivery concerns, risks and progress before committing more money or making major supplier decisions.

The immediate objective is to establish a clearer picture of the project, not to assume that further development or a new supplier is automatically the right answer.

For a business dealing with ongoing delivery uncertainty, this can provide a practical starting point for discussing the remaining investment and the decisions required.

Improve Ongoing Financial Oversight

A cost-to-complete review addresses an immediate funding question.

It does not necessarily resolve the management practices that created the uncertainty.

If forecasts repeatedly become unreliable, the business may need stronger ongoing oversight of its technology investments.

This includes clear ownership of budgets, scope decisions, supplier commitments and delivery reporting.

For example, a company operating several software platforms may have internal developers, outsourced suppliers and technology costs spread across different business departments.

No single person may have a complete view of the financial position.

Individual teams may be managing their responsibilities competently while the overall investment remains poorly controlled.

This is a leadership and governance issue, not simply a software development problem.

Establish Clear Accountability

Effective oversight requires agreement on a few important responsibilities.

Who approves changes to the agreed scope?

Who owns the overall software budget?

Who validates supplier estimates?

Who decides whether a feature is essential for launch?

Who reports forecast changes to the executive team?

These responsibilities do not always need to sit with a full-time CTO.

They do need clear ownership.

For established businesses, experienced Project Delivery support may help connect technology work with the commercial decisions required to keep delivery under control.

Where the issues extend across several projects, suppliers or business priorities, ongoing technology leadership may be more appropriate.

The goal is not to introduce more reporting for its own sake.

It is to give executives reliable information and clear accountability for decisions affecting business investment.

Frequently Asked Questions

How Do We Estimate Completion Costs?

Start by confirming the remaining scope and reviewing what has been completed and accepted. Estimate the cost of unfinished work, include outstanding contractual commitments and account for testing, deployment and operational readiness without double counting costs.

Can We Trust the Original Budget?

The original budget is useful for comparing planned and forecast expenditure, but it may no longer reflect the work remaining. A revised estimate should use current requirements, delivery evidence and known risks.

What If the Project Is Over Budget?

First establish the realistic remaining investment. Then assess whether the expected business benefits justify continuing, reducing scope or choosing another approach. Past expenditure alone should not determine the decision.

When Should We Seek an Independent Review?

Consider an independent review when the financial exposure is material and your team or supplier cannot provide a credible explanation of remaining work, delivery risks and estimated costs.

Do We Need Ongoing Technology Leadership?

Not necessarily. A capable internal team may manage the project effectively once the immediate uncertainty is resolved. Ongoing oversight becomes more relevant when unclear accountability, competing technology priorities or unreliable forecasts are recurring problems.

Make Your Next Investment Decision Count

A credible software project cost to complete forecast gives leadership a stronger basis for deciding whether to continue funding an existing project. If your development team cannot explain what remains, what it will cost and which risks could change the outcome, consider an independent Software Development Review before committing further investment. It is a practical way to establish greater confidence in your software project cost to complete.