When the right project decision is to stop

Stopping a project can be harder to explain than approving another extension. There is completed work to point to, people have invested effort and the original sponsor may still be closely associated with the decision.

None of that establishes whether the next commitment is worthwhile. I would review what the organisation can still achieve, what it must spend from this point and which alternatives now exist. Past expenditure deserves an honest account, but it should not decide the future by itself.

Reopen the assumptions, not the personalities

Begin with the conditions that justified the project. The business case may have assumed a particular volume of work, a stable policy or access to an external system. If those conditions have changed, the delivery team can perform well and still be building something the organisation no longer needs.

Consider a fictional project to create a separate contractor portal. Halfway through delivery, an existing enterprise platform offers a supported route for the same basic task. The new option may be unsuitable, but it deserves evaluation. Dismissing it because work has already started would protect the project rather than the organisation's interests.

Compare the actual requirements. The existing platform might cover standard cases but lack a specialist approval rule. The custom portal might offer a better experience but create a maintenance obligation the organisation cannot staff. Neither option wins merely because it is new or already paid for.

Keep the review separate from a performance investigation. People are more likely to surface changed assumptions if doing so does not automatically become an admission of failure. Accountability still matters, but it should distinguish poor decisions from reasonable decisions made under different information.

Compare what remains to be committed

Prepare a forward-looking comparison of continuing, reducing scope, pausing and stopping. Include the costs of each route, including termination, transition and unresolved operational work. Money already spent and unrecoverable should be shown separately from future avoidable costs.

A pause is not free. Contracts may continue, knowledge may decay and staff may need to remobilise later. State what the pause buys: perhaps a regulatory decision, a dependency outcome or evidence from another implementation. Give it a review date and a funding limit.

A smaller delivery can be sensible if it produces a usable outcome. It is less convincing when the remaining fragment needs most of the original operating cost but delivers little of the benefit. Ask the service owner whether they would choose to operate that smaller result on its own.

Do not rely solely on a revised return calculation with optimistic inputs. Identify which assumptions have the greatest effect on the decision and what evidence supports them. If the recommendation changes whenever a small estimate moves, the sponsor should see that uncertainty.

Give the stop recommendation a workable shape

A useful recommendation explains the change in circumstances, the options examined and why further commitment is not justified. It should also describe the consequences of stopping. Stakeholders need to know what problem will remain unsolved and how it will be handled.

I would include a concise closure plan covering:

• Contractual notice, outstanding payments and supplier obligations.
• Access, environments and information created during delivery.
• Work that can be retained and the conditions for using it.
• Users or teams relying on a pilot or temporary process.
• The owner of the remaining business need.

Commercial and legal advisers should check the relevant agreement. A project manager's recommendation does not establish a right to terminate without cost. Likewise, possession of source code does not necessarily establish unrestricted rights to reuse it.

If a pilot is already operating, provide a supported exit. Tell participants where their work will go, what records they need and when access will change. Stopping funding while leaving an unsupported service in use is an incomplete decision.

Preserve useful work without preserving the project

Requirements, test cases and research findings may be useful even when the chosen solution is not. Keep material with a clear purpose, owner and access arrangement. Record its limitations so another team does not treat an old assumption as a current requirement.

Avoid archiving everything under the label "future reuse". Unmaintained code can create a misleading sense that a later project is nearly finished. Describe what was verified, which dependencies existed and what would need reassessment before use.

The same discipline belongs in build-versus-buy decisions. Reusable capability has value when someone can realistically operate it, not simply because it occupies a repository.

Recognise the team's contribution directly. Useful discovery, well-written tests or an early warning about an unworkable dependency remain useful work. There is no need to invent a successful outcome to acknowledge that effort.

Close the remaining commitments

Assign a closure owner and review the outstanding items until they are finished or transferred. Check that subscriptions, access and supplier work have actually ended where intended. Update the portfolio so the project no longer consumes nominal capacity in one report while continuing informally elsewhere.

Finally, record the lesson at the level where it changes a future decision. Perhaps the organisation needed to test an integration earlier or involve the operating owner before procurement. "Communicate better" will rarely change the next investment.

A stopped project should leave a clear account of why the decision changed, what remains and who owns it. That is a more defensible outcome than another extension whose main purpose is to avoid explaining the first one.