Overview
Decide whether to continue a project by comparing what each available option would cost and deliver from today onward. Money and effort already spent cannot be recovered simply by spending more. They can provide lessons and create assets, but they should not become the reason to continue an otherwise poor option.
The decision is broader than “finish or abandon.” A project may be narrowed, paused, sold, transferred, completed in stages, or replaced by a simpler approach. Each option has future costs, possible benefits, obligations, and uncertainty.
HM Treasury's Green Book distinguishes irreversible sunk costs from the opportunity cost of resources that still have another use. Its formal framework concerns public appraisal; the forward-looking distinction is also useful for a business project review. The examples below are illustrative operating analysis, not a valuation or financing recommendation.
Define the decision that is still available
Write the actual choice and the date by which it must be made. “Was the project a mistake?” is a retrospective question. “Should we authorize the next implementation stage?” is a current decision.
Identify what the business can still control. A payment already made may be unrecoverable. A purchase order not yet placed may be avoidable. A signed commitment may require a cancellation payment or other action.
Ask the relevant contract, finance, and project owners to establish those facts. Do not label a cost avoidable merely because the team would prefer not to pay it.
Connect the review to the strategic planning process. The project should still support a current objective, rather than surviving because it once appeared in a plan.
Separate historical spending from future consequences
Keep a record of prior spending for accountability, but do not add it to only one side of the current comparison. The same irreversible past expenditure remains past under both continuation and stopping.
Suppose an illustrative software project has already cost 90,000. Finishing the current scope would require another 35,000. Stopping would require 5,000 of closeout work. The present choice is not whether to recover the 90,000 by spending 35,000. It is whether the future benefit of the completed scope justifies its future cost relative to the available alternatives.
Historical spending can still matter indirectly. It may have produced reusable code, research, equipment, or relationships. Those assets have current value only to the extent they can support a future use or be recovered.
Avoid using “we are too far in” as a substitute for that analysis. Progress needs to be measured by usable outcomes and remaining uncertainty.
Estimate the cost to complete afresh
Do not calculate remaining cost only by subtracting money spent from the original budget. The original estimate may no longer describe the work.
Ask what remains to make the outcome usable: implementation, integration, review, testing, training, migration, support, remediation, and operating costs. Include work that another department would otherwise absorb without appearing in the project budget.
Separate known commitments from estimates. Where uncertainty is material, show a range and the assumptions behind it.
Review the schedule as well. A benefit arriving later can differ substantially from the same benefit arriving on time. Delays may require temporary workarounds, extend vendor costs, or miss the period when the outcome would have been most valuable.
The team responsible for delivery should provide the estimate, and someone with enough independence should challenge its completeness.
Reassess the benefit without preserving the old promise
Identify the business outcome that completion would now create. Has demand changed? Is there still a clear user or customer need? Does the organization have the capacity to adopt the result?
A project can be technically complete while producing little value because the operating process, training, or customer demand never materialized.
Distinguish evidence from expectation. A signed customer commitment is different from an encouraging conversation. A tested reduction in a specific task is different from a broad claim that staff will save time.
Use the business plan guide to reconnect the forecast with current assumptions. The project review should be willing to revise the original business case rather than treating it as a promise that later evidence must defend.
Give stopping a complete cost estimate
Stopping is not always free. Consider contractual closeout, data preservation, customer communication, safe decommissioning, transition work, and obligations to employees or partners.
Also consider what happens to the need the project was meant to address. If an old system must remain in service, include its future operating and maintenance consequences. If the need can be met manually, estimate that work realistically.
Do not exaggerate exit costs to make continuation inevitable. Ask for the basis of each amount and distinguish unavoidable obligations from discretionary cleanup.
Likewise, do not ignore obligations because the project is no longer attractive. The organization needs a responsible exit plan even when the original investment has failed to deliver.
Compare a smaller usable option
A reduced scope may preserve the most valuable outcome while avoiding expensive secondary features. Start with the user's essential task and identify the smallest complete version that serves it.
For example, an internal scheduling project may not need its planned reporting suite to replace the most burdensome manual step. But removing reporting could still be unacceptable if it is necessary for required records or management control.
Test the reduced option as its own design. Do not assume that deleting half the feature list halves the cost. Shared infrastructure, dependencies, and transition work may remain.
Document what the smaller option excludes and who accepts that consequence. Otherwise, the omitted scope may return later as unplanned work, undermining the apparent saving.
Work through a forward-looking comparison
Consider three illustrative options for the software project. All figures concern future amounts over the same evaluation period and are simplified for explanation.
| Option | Future implementation and transition cost | Estimated future net operating benefit before that cost |
|---|---|---|
| Complete current scope | 35,000 | 50,000 |
| Deliver a smaller usable scope | 18,000 | 38,000 |
| Stop and retain the current process | 5,000 | 0 |
On these assumptions, subtracting the stated future cost gives 15,000 for completion, 20,000 for the smaller scope, and minus 5,000 for stopping. The already spent 90,000 does not change that ranking because it cannot be changed by any current option.
This table does not prove the smaller scope is best. The estimates may differ in uncertainty, timing, obligations, or strategic effect. It shows why the team should compare real alternatives rather than ask only whether the full project's total historical return looks disappointing.
Test the assumptions that could reverse the choice
Identify the few uncertain facts with the greatest effect. Perhaps the smaller scope's benefit depends on staff adoption, or the full scope's estimate excludes a difficult integration.
Vary those assumptions and see when the preferred option changes. If a modest change reverses the ranking, the decision is sensitive and may benefit from more evidence.
A short prototype, supplier clarification, or user test can sometimes resolve a specific uncertainty. Define what the investigation must establish and how much time and money it is worth.
Do not use “we need more research” to postpone a decision indefinitely. Information gathering has a cost and may consume the remaining opportunity. The review should specify what evidence would be sufficient to decide.
Include the next best use of resources
People, equipment, and cash may have other uses. Continuing a project can prevent the business from pursuing those alternatives.
An employee's salary may already be budgeted, but their time is not automatically free for the project. Ask what valuable work they would otherwise do. Similarly, equipment already purchased may have resale value or a productive alternative use.
Avoid double counting. If the comparison already includes a resource's relevant cost in one way, do not add the same consequence again under a different label.
The purpose is to make the tradeoff explicit, not to attach speculative revenue to every hour. A credible alternative with an owner and a realistic plan is more informative than a vague claim that the team could be doing something better.
Check cash timing separately from economic value
An option can appear attractive over several years while requiring cash the business cannot provide when needed. Put its receipts and payments into the cash-flow forecast.
Show deposits, milestone payments, transition overlaps, and the timing of expected benefits. Do not assume that an accounting saving immediately becomes cash available for the next invoice.
If funding is uncertain, record that as a condition. A possible loan or future sale should not be treated as an approved resource.
Financial and contractual specialists may need to review material commitments. The project comparison should make their questions easier to answer by keeping the timing and assumptions visible.
Make the decision process safe for bad news
People who proposed or delivered the project may feel that stopping it reflects on their competence. A review that punishes honest updates encourages optimistic estimates and delayed disclosure.
Ask what the team knows now that it did not know before. Separate an understandable earlier decision under uncertainty from the obligation to make a sound decision today.
Invite challenge from someone who does not own the original promise. Give the delivery team a chance to explain technical and operating constraints without requiring them to defend every past choice.
Accountability still matters. Preserve the lessons about estimation, governance, or execution. But do not force additional spending merely to avoid acknowledging that a prior assumption was wrong.
Record conditions for continuing or pausing
If the decision is to continue, name the next funded stage, its intended outcome, budget boundary, and review trigger. Do not turn a conditional approval into authorization for unlimited completion work.
If the decision is to pause, specify what is preserved, what costs continue, who maintains the assets, and when the pause will be reconsidered. A pause without those rules can become an expensive form of indecision.
If the decision is to stop, assign closeout work and communication. Confirm which commitments remain and how the original business need will be handled.
Use observable triggers where possible: a supplier quote, a tested integration, a customer commitment, or a completed usable milestone. Avoid vague conditions such as “when confidence improves.”
Verify the decision's consequences
Review whether the chosen option produced the expected result. Did the reduced scope remain bounded? Did stopping actually release the capacity assumed? Did closeout costs match the estimate?
Preserve reusable knowledge and assets with clear ownership. Do not keep every unfinished artifact indefinitely merely because it once cost money.
The next project can benefit from the review if assumptions, evidence, and decision dates remain traceable. A candid stop decision can be evidence of effective management when the future case no longer supports continuation.
The question is what the business should do with the choices it still has. Past spending explains how it arrived here; it does not decide where it should go next.
References and examples
Primary sources and product examples used to ground this guide. Product links are editorial references, not endorsements.