Change needs a purpose, evidence of progress and the judgement to know when to stop. Use these five pillars to define success, test the results and decide what deserves to grow.
Before choosing a tool or starting a project, agree the problem, who it affects and what a meaningful improvement would look like. Establish a baseline so that progress can be demonstrated.
These pillars provide a practical lens for business change, automation and AI. Choose measures that fit the work and review them together. A gain in speed should not hide poorer quality, extra cost or an unacceptable risk.
Use a small set of meaningful measures across the pillars. Look at the evidence alongside feedback from the people doing the work.
Does work become easier and more effective?
Look at the whole process, including the effort needed to check, correct and maintain the solution. A faster task only helps if the time released can be put to useful work.
Are the outcomes reliable and fit for purpose?
Agree what good looks like before delivery. Check accuracy, consistency and the handling of exceptions, alongside the speed of the work.
Does the benefit justify the full cost?
Connect improvements to a commercial outcome. Include implementation, subscriptions, integration, training, oversight and ongoing support in the cost.
Does the change work for the people using it?
Understand how employees and customers experience the new process. Make ownership clear, support adoption and check whether effort has simply moved to someone else.
Can the organisation trust and govern the change?
Set boundaries around data, decisions and actions. Define what a system may access, what needs human approval and who can investigate or stop it.
For AI, establish three things before deployment: the business outcome it is authorised to pursue, the information and actions it can access, and the operational oversight needed to detect, investigate and stop unexpected behaviour.
The ability to stop is part of good delivery. Agree the boundaries before you begin, while decisions can still be made calmly and objectively.
Benefits remain below the agreed threshold, costs keep rising or the original problem has changed. Review the future cost and likely benefit rather than defending money already spent.
Quality deteriorates, people are disadvantaged, sensitive information is exposed or actions exceed their authority. Pause affected activity immediately when an agreed safety boundary is breached.
Manual checks, corrections and workarounds outweigh the benefit. Investigate what is failing and whether the process, data, training or solution needs to change.
Specify the measure, threshold and review period. Distinguish an immediate stop condition from a concern that needs investigation.
Give an accountable person authority to pause the work. Make it clear how staff raise a concern and who covers an absence.
Know how to disable affected actions, preserve a record of what happened and keep essential work running through a fallback process.
Investigate the cause, agree corrective action and test the result. Require an explicit decision before restarting or expanding.
A pilot reduces drafting time but starts offering refunds outside the business rules. That breaches its authority, even if the productivity figures look good.
The response: disable automatic sending, route replies through human review and investigate the affected cases. Restart only after permissions and approval rules have been corrected, tested and signed off by the accountable owner.
Stopping can mean pausing a feature, redesigning a process or ending an initiative. The decision should protect people and business value, with a clear record of why it was made.
Project Reboot helps you understand the current process, define useful outcomes and build a delivery approach with clear ownership and sensible controls.
Explore the AI Readiness Assessment to understand your foundations or see the work in practice.
Let’s talk about your transformation