Making Improvements That Stick

List every symptom

Write down every problem, recurring issue, and unexplained variation you experience. Don’t filter yet — don’t decide what is important and what is not. Capture everything: customer complaints, error rates, staff turnover, missed deadlines, lost sales, support calls, rework, delays. Get it all on paper.

Look hardest at where outcomes vary most for no obvious reason — peak order volumes, work with unpredictable scope, requests that look standard but reveal hidden complexity once underway. High variation in outcomes for similar inputs is the most powerful diagnostic clue available: it signals that the system is dependent on individuals rather than design, and that a structural fix is available. Variation is rarely visible in averages — it only becomes visible when you plot results over time.

Measure your biggest issue over time

For your most significant problem, find a number that tracks it over time — monthly sales, support cases per month, error rate, on-time delivery percentage, customer complaints per quarter. Plot it as a time series and run it through Bootstrap CUSUM.

This step answers the question that most organisations skip: is this problem getting worse, staying flat, or gradually improving? A flat Bootstrap CUSUM line means the problem is stable at a level you don’t want — it has been like this for years and will continue unless the system changes. An upward change point means something made it worse at a specific date — find out what changed then.

Find the root cause

For each significant issue, trace the causal chain back to its root. For a straightforward problem with a clear sequence of causes, use the 5 Whys — ask why five times until you reach the underlying system condition. For a complex problem with multiple contributing factors, use a fishbone diagram to map all the possible causes across categories before investigating which ones are active.

The most important rule: keep going past “human error.” Human error is a symptom, not a cause. The root cause is the system condition that made the error easy to commit and hard to catch. Apply the Joiner test at the end: is the proposed fix at the output level, the process level, or the system level? If it is not at the system level, ask whether a deeper cause exists.

Find the dominant constraint

Review your full list of root causes and look for the one that keeps appearing across multiple problems. That is your constraint — the single condition that, if addressed, would unlock improvement across the widest range of issues simultaneously. It is often something you do not have rather than something wrong that needs stopping: a missing role, a missing system, a missing decision that has never been made, a missing feedback loop.

Addressing anything other than the constraint improves things at the margins. Addressing the constraint changes the system. The Theory of Constraints gives this a precise operational method: Identify the constraint, Exploit it fully before adding resources, Subordinate everything else to it, then Elevate it. Look for what is already working well despite the constraints — those Bright Spots are operating differently, and understanding how tells you what the constraint actually is.

Design a complete solution

Generate possible solutions to the constraint and the root causes. Then apply the necessary but not sufficient test to each one: is this solution sufficient on its own, or does it only remove one obstacle while others remain? A training programme alone is rarely sufficient. A new process alone is rarely sufficient. A technology alone is rarely sufficient.

Ask: what are all the necessary conditions for the goal? Which are currently met? Which are not? A complete solution addresses all the unmet necessary conditions, not just the most obvious one. Deming and Goldratt both made the same point: technology, process, and measurement must all change together. Change any two and the third pulls the system back.

Prioritise with PICK

You will have more possible solutions than capacity to implement them. Sort them using the PICK model — a simple 2x2 matrix of impact versus effort. Implement high-impact, low-effort ideas immediately. Challenge yourself to find a way to deliver high-impact, high-effort ideas — plan these carefully with a PDSA cycle. Possible means do it if you have spare capacity. Kill means stop — including stopping things already in progress that are low impact and high effort.

Be ruthless about Kill. The effort saved by stopping a low-impact activity is capacity for the high-impact ones. Focus is not about working harder — it is about working exclusively on the constraint while everything else waits. Organisations that pursue too many priorities simultaneously make slow progress on all of them. A portfolio policy — a clear, written statement of what you will and will not take on — is what makes Kill decisions defensible and consistent rather than case-by-case.

Handling Challenge items: the most effective way to execute a high-impact, high-effort Challenge item is to break it into stages. Each stage should be small enough to deliver within a PDSA cycle — typically weeks, not months. The first stage defines the minimum version that delivers real value and can be tested with real users. Subsequent stages expand scope based on what the first stage revealed. This converts a daunting large project into a series of manageable steps, each with its own Bootstrap CUSUM test, each building evidence before committing to the next.

Plan, Do, Study, Act

Take your prioritised solutions through a PDSA cycle. Plan: state clearly what you predict will happen and by when. Pick a specific outcome measure and pre-specify the Bootstrap CUSUM change point you expect. Do: implement the change, on a small scale first where possible. Study: run Bootstrap CUSUM on the outcome measure. Has a structural change point appeared? Act: if yes, scale up. If no, the root cause analysis was incomplete — return to Step 3.

The Study step is where most improvement cycles break down. Without a pre-specified Bootstrap CUSUM test, any result can be interpreted as success. The pre-commitment is what makes the verdict honest — and honest verdicts are what produce learning rather than confirmation bias.