Should you finish an internal project that is over budget?

An over-budget project should be reviewed using the choices still available. Money already spent explains how the business reached its current position, but it cannot be recovered merely by approving the remaining work. Compare the additional spending and benefits of completing the project with the costs and consequences of stopping or narrowing it.

Start by defining what is usable today. A partially configured system may support one process, while an unfinished facility may provide no operational benefit until specific safety and commissioning work is complete. Ask the delivery owner to demonstrate the current state and identify the minimum work needed for a usable result.

Preserve the original approval and explain the variance separately. Management needs accountability for the overrun as well as a forward-looking decision. Combining those discussions can pressure the team to finish a weak project merely to make the earlier approval look reasonable.

List unfinished deliverables, dependencies, contracted work and internal staffing. Obtain revised estimates from the people who will perform the work. A percentage-complete claim is insufficient when the remaining tasks are the hardest integration, testing or approval steps. Ask what evidence supports the proposed completion date.

Include costs after the nominal finish: training, parallel operation, maintenance, support and retiring the old process. If the benefit depends on adoption, identify who owns the operating change and whether that team has capacity. A technically complete tool can remain unused while both old and new costs continue.

Separate firm commitments from uncertain estimates. Show a range for unresolved work and explain what would reduce the uncertainty. If another short investigation could establish whether the project can function, management may choose that limited step before approving the full remaining budget. Give the investigation its own spending cap and decision date.

Suppose a hypothetical internal scheduling project has already cost $180,000. Completing the original scope now requires another $90,000 and would produce an estimated $50,000 of annual operating benefit for three years. Ignoring financing, tax and timing differences, the remaining benefit totals $150,000 against $90,000 of future spending. The prior $180,000 does not change that forward comparison.

A narrower release might cost $35,000 and produce $30,000 annually over the same period. Its undiscounted future benefit less cost is $55,000, compared with $60,000 for the full release. The extra $55,000 required for the full version buys only $5,000 more net benefit under these assumptions. That can make the narrower option attractive when cash or implementation capacity is limited.

Stopping could still cost money. Assume contract termination and secure removal of temporary systems would cost $10,000. Include that amount in the stop option rather than treating cancellation as free. These illustrative figures support a comparison; they do not establish a universal project-approval rule.

Revisit the original problem. A process may have changed while the project was being built, or another system may now solve part of it. Benefits estimated at approval can become outdated even when the technical scope remains unchanged. Ask the operating owner which measurable activity will improve after launch and what has changed since the first estimate.

Distinguish released capacity from cash savings. Saving employee hours creates cash savings only when spending falls. Redeploying those hours may produce additional output or another benefit, which should be identified and valued separately. If staff remain employed and no alternative work is identified, describe the result as available capacity. Do not count the same hours as both eliminated cost and additional output.

Use evidence from a limited working part where possible. Compare processing time, error rates or delivery output under similar conditions. Record implementation assumptions, such as training completion, that must hold for the benefit to appear. A benefit without an owner is difficult to verify after approval.

Stopping, narrowing or completing a project can raise accounting questions about recorded assets, expenses and obligations. Have the accounting owner evaluate those consequences under the applicable reporting basis. Avoid choosing an operating option solely to preserve a desired accounting result.

The SEC's financial-statement guide distinguishes assets, expenses and cash flows. Those distinctions explain why a project decision can affect reported profit differently from future cash. A write-down of a recorded amount, for example, should not be confused with a new supplier payment. The exact treatment requires review of the project's facts and accounting policy.

Show management both views: the economic comparison of future alternatives and the expected reporting consequences supported by the accounting team. Keeping them separate helps readers understand which amounts are new commitments, which reflect earlier spending and which remain estimates.

If management continues, approve a defined scope, maximum additional commitment and observable acceptance condition. Name the person who can approve changes. A revised total budget without a delivery boundary can allow the same overrun pattern to repeat under a new number.

If management stops, assign contract closure, data retention, access removal and handover responsibilities. Preserve work that the business owns and can use later, while closing temporary resources that continue to incur charges. Confirm the actual exit cost against the estimate.

Schedule the benefit review when the operating result can reasonably be measured. Compare achieved output and spending with the revised decision case, not only the original proposal. Retain the reasons for the choice so a future team can understand why the business completed, reduced or ended the project.