How to decide whether to continue

A project has consumed months and remains far from its expected result. Ending it feels like wasting the effort. Continuing seems like the only way to make sense of what has already been done.

Past work belongs to the project's history and may have produced knowledge or resources you can still use. The next decision, however, commits time and money that remain available. What can the future work deliver, and at what cost?

Contracts, dependencies and commitments created by the project still affect what is feasible, even when past spending cannot be recovered. Distinguish present consequences from attempts to recover an expense that no choice will return.

Separate past spending from resources you can still use

Consider a fictional initiative to build a subscription service. The team developed part of the system, interviewed prospective users and discovered that demand would require more customer support than expected.

The hours spent interviewing cannot be recovered. What the team learned may help it compare different offers. Some software might serve another project, provided adapting it is worthwhile. An existing contract might create a cost of closing the project.

Inventory these elements without automatically assigning value to each. A nearly finished system is not necessarily cheap to finish, nor does it prove that anyone will use it. Having learned a great deal does not mean continuing will produce equally useful knowledge.

Estimate the remaining work again

Initial estimates can keep circulating after discoveries have changed the work required. Ask what remains now, based on what the team learned during execution.

In the subscription example, support might account for most of the cost while the discussion still focuses on finishing the code. Compare the complete offer, including operation and maintenance, with other ways to meet the same need.

A new estimate may be highly uncertain. Record what supports it and which dependency could change it. A plausible range with its conditions is more useful than a precise date without a basis.

Include what will not happen while the project continues. The team might postpone an improvement with established demand. Examine that alternative too, so the existing work is not judged more harshly than its replacement.

Check whether the goal still matters

The problem may have changed since the project began. A service aimed at a particular difficulty may become less useful after customers change their routines. Or the goal may remain valid while the chosen solution is unsuitable.

Revisiting the goal helps distinguish these situations. "We need to finish the system" is a task. "We need to meet this need sustainably" leaves room to finish, simplify or change course.

Talk to the people who will use the result and those who will maintain it. Developers can assess what remains before delivery; customer support staff can identify commitments that will continue afterward.

Consider a partial exit

Ending everything and continuing everything can seem like the only options. There may be a smaller version that tests the need, a useful part to retain or an obligation to complete before stopping.

The fictional company could offer the service manually to a small group if that clarifies the effort and willingness to use it. The test needs a question and a limit. Otherwise it may simply prolong a project nobody wants to end.

The company may also need to stop new sales while honoring existing commitments. Include the transition cost in the decision. A responsible exit rarely means abandoning all work in progress.

Set the next review before continuing

If the team continues, agree on what must be observed to justify another stage. What evidence of demand matters? How much effort is acceptable? When will estimates be examined again?

Choose conditions the team can observe and relate to the goal. "Improve confidence in the project" supplies no clear rule. "Provide this support within the estimated effort for the specified cases" gives the team a concrete hypothesis to evaluate.

The review must also allow the project to end. If every disappointing result only leads to another deadline extension, the criterion is not guiding the decision.

Write the case for continuing using only benefits and costs that can still occur. Then add today's transition obligations. If the argument depends mainly on past spending, revisit the estimate of remaining work and the alternative it is delaying.