When Should a Project Board Stop or Reset a Project?


A project team discussing priorities beside a wall of planning notes

Project boards are often encouraged to support delivery, remove obstacles and maintain momentum. Those responsibilities matter, but governance also requires a harder judgement: whether the project should continue in its current form at all.

Stopping a project is not automatically a failure. Continuing to spend money, consume scarce capacity and disrupt operations after the justification has weakened can be the more serious failure. Equally, closing too quickly can destroy recoverable value. The project board needs a disciplined way to distinguish a difficult stage from a project that should be paused, reset or stopped.


Begin with continued business justification

PRINCE2 treats continued business justification as a principle, not a document completed at the beginning and filed away. The question is not simply whether the original business case was approved. It is whether the project remains desirable, viable and achievable now.

Review what has changed. Costs may have increased, benefits may have reduced, a regulatory deadline may have moved or another initiative may now meet the same need. For an AI-enabled process, new evidence about data quality, adoption or operating cost may materially alter the case.


Separate a problem from an exception

Projects rarely run without problems. A delayed activity or failed test does not by itself require board intervention. PRINCE2 tolerances give the project manager room to manage within agreed boundaries for time, cost, scope, quality, risk, benefits and sustainability.

The board should become directly involved when forecasts show those tolerances will be exceeded, or when the assumptions behind them are no longer credible. That is an exception: the agreed plan can no longer be delivered within the authority given.

An exception should trigger a decision, not simply a red status report. Ask what caused it, which outcomes remain achievable, what options have been assessed and what additional exposure each option creates.


Check whether the benefit still matters

A project can recover its schedule and still be the wrong investment. Revisit the problem the project was meant to solve. Is the outcome still needed? Will it still create measurable benefit? Is there an operational owner willing and able to realise that benefit?

Be wary of benefits that remain technically possible but have become too remote or too expensive. A promised efficiency may depend on behaviour that teams cannot adopt during peak workload. A customer improvement may be offset by added rework elsewhere. Use current evidence rather than repeating the original forecast.

If the need remains strong but the proposed solution no longer represents the best route, a reset may be better than continuing unchanged.


Look at deliverability, not optimism

Recovery plans can become exercises in optimism. Dates move, more people are added and difficult work is compressed into the final stage. The board needs to test whether the new plan is genuinely achievable.

Ask what has been learned from actual delivery. Are estimates based on completed work? Have critical dependencies been confirmed? Is specialist capacity available? Can suppliers meet the revised commitment? What must operations stop doing to absorb the change?

For people-dependent change, include readiness and adoption. If managers do not have time to support new behaviours, training has not produced competence or frontline teams rely on unresolved workarounds, technical completion will not rescue the outcome.


Consider four real options

The choice is rarely only “carry on” or “cancel”. A project board should consider at least four options.

Continue when the business case remains strong, delivery is within tolerance or a credible corrective action can restore control without new board authority.

Pause when a dependency, decision or operating condition must be resolved before responsible delivery can continue. A pause needs a purpose, owner, review date and clear conditions for restart. Otherwise, it becomes an expensive project that is neither active nor closed.

Reset when the need remains valid but scope, approach, governance, team or sequence must change materially. The reset should produce a fresh baseline and business case, not disguise repeated slippage beneath another revised date.

Close when continued investment is no longer justified, the outcome is no longer achievable at acceptable risk, or a better option has replaced the project.


Protect customers and operations during the decision

A board decision does not happen in isolation. Pausing or stopping may affect customers, employees, suppliers, contracts and regulatory commitments. Continuing may also create harm through instability, duplicated processes or change fatigue.

Map the consequences of every option. What service must continue? Which temporary controls are needed? What will happen to incomplete data, licences, contracts and partially delivered products? Who needs clear communication, and when?

Operational involvement is essential here. The project team may understand deliverables, while operational leaders understand the cost of running parallel processes and the risk of an unfinished transition.


Avoid punishing early escalation

Teams conceal bad news when escalation is treated as personal failure. Project managers need to know that a well-evidenced exception is responsible management, not an admission of incompetence.

The board can set that tone by asking for evidence, options and learning rather than blame. It should also examine whether its own decisions, delays or unresolved priorities contributed to the position. Governance loses credibility when responsibility only travels downwards.


Make the decision explicit

Record the decision, rationale, assumptions, evidence, conditions and named owners. If the project continues, state the revised tolerances and what would cause another review. If it pauses, define the restart criteria. If it resets, approve a controlled route to a new baseline. If it closes, authorise the closure work and protection of useful assets.


Capture value even when a project closes

Closure should preserve learning, reusable products, data, supplier knowledge and any benefits already created. It should also end unnecessary spending and release people cleanly rather than leaving an unofficial team trying to revive the work.

Review why warning signs emerged when they did. Were tolerances unclear? Did assurance focus too heavily on schedule? Was the business case allowed to become ceremonial? The purpose is to improve future governance, not create a retrospective prosecution.

A strong project board does not keep every project alive. It keeps investment aligned with value and makes clear decisions while choices still exist. If you are reviewing a troubled change or designing stronger governance, I can help connect PRINCE2 controls with operational capacity, adoption and practical delivery evidence.


About Mark M Barton

I am a Change Management, Change/Internal Communications, and Project Delivery and Operations professional with over 25 years' experience helping organisations deliver complex projects, improve operations and navigate organisational change.

Certified in both Prosci Change Management and PRINCE2, I work across change management, project delivery, operational improvement, internal communications and transformation initiatives, helping organisations achieve successful outcomes through both structured delivery and effective people engagement.

If I can help you, your team, or your organisation do reach out.

Previous
Previous

One Delivery Plan: Combining Project and Change Management

Next
Next

How to Make Project Assurance Useful