Decide Whether to Fund the Next Step

A project can reach a difficult point without a dramatic failure. The prototype works, but the workflow it supports is less important than expected. An integration is possible, but its operating cost changes the case for using it. A dependency has moved, and the original opportunity may no longer exist.

The team has invested effort. Other people expect a result. There is a persuasive argument that one more phase will make the work worthwhile. There may also be a persuasive argument for stopping. Neither should rest on embarrassment about what has already been spent.

Frame the decision around the next investment. What would it buy? What evidence supports it? What else would become harder to do if the crew continued?

Reconstruct the original reason

Return to the problem and the people affected. Avoid beginning the review with completed tasks. A list of delivered components can establish progress against a plan while saying little about the plan’s continuing value.

Write the intended improvement in ordinary language. Then describe what you now know about it. Perhaps the problem remains important but the proposed solution is unsuitable. Perhaps a smaller change addresses most of the need. Perhaps the beneficiary cannot adopt the result under current conditions.

Keep these possibilities distinct. Stopping an approach does not necessarily abandon the problem. Continuing to care about the problem does not require continuing the approach.

Put real options beside one another

Compare at least the plausible alternatives: continue as proposed, reduce or change the scope, pause with explicit conditions, or stop. Include the work each option requires. “Stop” can still involve customer communication, data reconciliation, infrastructure removal, documentation, and support.

For an illustrative internal tool, the alternatives might be another month of development, a narrower workflow built on existing software, or retirement of the pilot. The useful comparison would include the remaining user need, expected operating responsibilities, unresolved integration risk, and cost of switching. A percentage-complete estimate would not settle those questions.

Avoid making the preferred option look precise while leaving the others vague. If continuation has a named owner and a detailed plan, give the alternatives enough attention to be meaningfully compared.

Use one more experiment carefully

Further investigation can be a responsible choice when it resolves a question that changes the decision. Name that question before approving the work. Specify the evidence needed, the investment limit, and what each plausible result would lead you to do.

“Get more feedback” is too open. “Observe whether staff can complete this workflow without the proposed integration, then decide whether that integration remains in scope” creates a decision the investigation can support.

An experiment becomes a way to postpone judgment if every result leads to another experiment. Before starting, check that at least one credible outcome would cause a change or a stop. If no result could affect your choice, you are asking the team to justify a decision already made.

Close the work responsibly

If you stop, give closure an owner. Identify what remains in use, what carries risk, and what must be removed. Preserve findings with their context so someone can judge whether they still apply later. Record why the work ended without turning the account into a defence of anyone’s reputation.

Recognize the contributions that made the decision possible. A team that exposes a weak assumption early has done useful work even when the intended software does not become a lasting product. Be precise about what was learned and what decision it changed.

A pause needs similar care. State the condition for reconsideration, who will monitor it, and what happens to ongoing costs. Otherwise “paused” can become an unattended operating state.

At the next review, finish with a decision that names the next investment or the closure work. Give it an owner and a review point. The team should leave knowing what to do, rather than carrying an increasingly expensive obligation to make the past look sensible.