Making the Invisible Visible
The symptom is visible. The cause is hidden. The constraint is structural. The contradiction is assumed away. And the natural human response — act on what’s visible, react to what’s loudest, fix what you can reach — almost always addresses the wrong thing. Every great improvement framework is a different method for bridging that gap between what’s visible and what’s true.
Making something visible is itself an intervention. Not a precondition for the intervention — the intervention itself.
Most human systems fail not because people lack the will to fix them, but because the real problem is invisible. Every great improvement framework is a method for making the invisible visible — and Bootstrap CUSUM (StepChange Analyzer) is the instrument that makes structural change visible in data.
☰ Contents
The fundamental problem
Imagine a hospital with rising corridor care rates, falling staff morale, missed A&E targets, and increasing ambulance handover times. A management team looks at this picture and sees four problems. They form four workstreams, assign four improvement leads, and implement four programmes simultaneously.
What they cannot see — because it is structural and therefore invisible to operational observation — is that all four symptoms share a single cause: approximately 13,700 acute beds per day are occupied by patients who are medically fit to leave but cannot, because social care capacity is insufficient. That constraint sits outside the system boundary of any NHS trust. It is invisible from inside the organisation. And the four workstreams, each addressing a visible symptom, will produce activity without producing structural improvement.
This is not a story about the NHS. It is a story about the relationship between visibility and causality that every improvement framework has independently discovered:
The visibility gap
What is visible is almost never the cause of what is experienced. The symptom surfaces where the pain is felt. The cause sits upstream, often invisibly, often outside the boundary of the organisation that experiences the pain. The natural human response — act on what you can see, react to what is loudest, fix what you can reach — systematically addresses the symptom rather than the cause. This is not stupidity or laziness. It is a structural property of how human attention and organisational authority both work: we attend to what is visible, and we act where we have authority.
“If we keep working the way we are doing it, the outcome will be the same.”
Syd Stewart — StepChangeAnalysis.com
Every major improvement framework — from Shewhart’s control charts to Goldratt’s Evaporating Cloud to Don Norman’s affordances to FMEA detectability scoring — is a response to this same fundamental problem. They differ in domain, language, and method. They agree on the diagnosis: the problem is a visibility failure, and the solution is a visibility intervention.
Don Norman — visibility as the design principle
In The Design of Everyday Things (1988), Don Norman asked why intelligent, capable people consistently make errors with everyday objects — doors, switches, taps, computers. His answer was not that people are careless. It was that the objects failed to make the correct action visible.
Norman identified two visibility failures that cause most use errors:
| Norman’s concept | What it means | The improvement equivalent |
|---|---|---|
| Affordance | The correct action is not visible in the design of the object. A door that should be pushed has a handle that invites pulling. The user makes the “wrong” choice — but the design made the right choice invisible. | An improvement intervention that requires the correct action to be invisible (a new protocol buried in a policy document, a new pathway with no visible cue at the point of decision) will fail regardless of how well-designed it is. Visibility of the correct action is a precondition for behaviour change. |
| Feedback | The system state is not visible after an action. The user presses a button and does not know whether anything happened. They press it again. Or they don’t press it enough times. The absence of visible feedback produces error. | A system without visible feedback on its current state — a metric without a chart, a process without a run chart, an improvement without a change point detection method — cannot be managed. Bootstrap CUSUM is a feedback mechanism: it makes the system’s response to an intervention visible in the data. |
Norman’s most important insight for improvement work: when something goes wrong, the first question is never “who made the error?” It is “what was invisible that should have been visible?” This reframe — from blame to design — is the foundation of patient safety culture, human factors engineering, and every serious improvement methodology.
A “Norman door” is a door so badly designed that you always push when you should pull, or pull when you should push. NHS improvement is full of Norman doors: systems that make the wrong action easier than the right one, processes where the safe path is less visible than the unsafe shortcut, metrics that make gaming easier than genuine improvement. Every time an organisation responds to this by training staff to use the door correctly rather than fixing the door, it is applying a Level 1 fix to a Level 3 design problem.
Deming’s insight was that variation is everywhere and that managers must learn to distinguish common cause from special cause. But there is a prior problem: variation is often invisible. A manager who cannot see the variation — who has no control chart, no run chart, no Bootstrap CUSUM — will react to every data point as if it were a signal. Tampering is not stupidity. It is the rational response to invisible variation. The control chart does not just describe variation. It makes it visible — and visibility changes behaviour before any other intervention is applied.
FMEA — detectability as a risk dimension
Failure Mode and Effects Analysis (FMEA) was developed in aerospace and defence in the 1940s and became central to automotive and medical device safety. It scores every potential failure mode on three dimensions: Severity, Occurrence, and Detection. The Risk Priority Number (RPN) is their product: Severity × Occurrence × Detection.
Detection is the visibility score. A detection score of 1 means the failure is immediately obvious — it cannot occur without being seen. A detection score of 10 means the failure is completely invisible — it will occur and not be detected until it causes harm.
The profound insight in FMEA’s structure is that improving detectability reduces risk independently of whether you have fixed the cause. Making a failure mode visible — through an alarm, a visual indicator, a monitoring system, a mandatory check — reduces the RPN even if the underlying failure mode still exists. Visibility is a risk control in its own right.
This maps directly onto the improvement framework: making a problem visible is an intervention, not just a precondition for one. A run chart that shows variation doesn’t fix the process — but it makes the variation visible, which changes behaviour, which changes the system. Bootstrap CUSUM doesn’t fix the constraint — but it makes the structural change point visible, which changes what gets attributed to what, which changes what gets standardised and what gets abandoned.
In FMEA, the highest-risk failure modes are often not the most severe ones. They are the ones with low detectability — the silent failures that accumulate undetected until they produce a catastrophic outcome. The same pattern appears in organisational improvement: the most dangerous problems are not the loudest ones. They are the ones nobody can see. Corridor care is loud and visible. The discharge constraint that causes it is silent and invisible. FMEA would give corridor care a low detection score — and correctly identify the discharge constraint as the higher-risk finding.
A silo is not just an organisational structure. It is a visibility boundary. The cause of a problem is often on the other side of that boundary — in the supplier, the customer, the regulator, the adjacent department, the local authority. From inside the silo, the cause is structurally invisible. You experience the symptom. You cannot see what is producing it.
This is why systems thinking — Senge’s fifth discipline, Checkland’s rich picture, Beer’s Viable System Model — begins by drawing the whole system: suppliers, customers, regulators, government departments, legislation, feedback loops across boundaries. The rich picture includes things the organisation does not control precisely because the causes of its problems often live there. Making the whole system visible — not just your slice of it — is the prerequisite to finding the real constraint.
Every framework is a visibility tool
Across every improvement discipline, the same pattern recurs: a framework that makes something invisible, visible. The methods differ. The domains differ. The vocabulary differs. The insight is the same.
| Framework | What it makes visible | What was invisible before |
|---|---|---|
| Shewhart control chart | The boundary between common cause variation and special cause variation | Whether a data point is a signal worth acting on or noise that should be ignored. Without the chart, every data point looks like a signal. |
| Bootstrap CUSUM | The date and direction of a structural step change in a time series | Whether an intervention produced genuine structural improvement or whether the metric moved for other reasons (seasonal variation, regression to the mean, definition change). |
| Goldratt’s constraint map | Where work accumulates — the binding constraint in the system | That improving a non-constraint produces no improvement in throughput. Every manager sees their own bottleneck; the constraint map shows the system’s bottleneck. |
| Goldratt’s Evaporating Cloud | The structural contradiction keeping the constraint in place — and the assumption underneath it | That the constraint is not a resource problem or a process problem but a logical conflict between two legitimate requirements. The Cloud makes the conflict explicit — and often dissolves it. |
| Joiner’s levels of fix | The level at which the constraint sits (output, process, or system) and whether the organisation has authority to address it | That Level 1 and Level 2 interventions applied to a Level 3 constraint will produce no lasting change — invisible until the Bootstrap CUSUM flat line makes it explicit. |
| Causal loop diagram | The feedback loops — reinforcing and balancing — that produce system behaviour over time | That a vicious cycle is self-sustaining regardless of individual effort, and that the leverage point is in the loop structure, not in working harder within it. |
| TRIZ contradiction matrix | The technical or physical contradiction that makes the problem appear unsolvable | That the problem persists not because of insufficient resources but because of a structural conflict — and that the conflict can be resolved by changing the dimension in which standardisation and customisation apply. |
| FMEA detectability score | How visible each failure mode is before it causes harm | That silent failures are higher risk than loud ones — and that improving visibility is a risk control in its own right, independent of fixing the cause. |
| Senge’s iceberg model | The structure and mental models beneath the visible events and patterns | That events are the tip of the iceberg — below the surface lie patterns, structures, and mental models that will keep producing the same events until the structure changes. |
| Don Norman’s affordances | Whether the correct action is visible at the point of decision | That use errors are almost always design errors — the correct action was invisible, so the user made the only choice the design made obvious. |
| Hurson’s evaluation matrix | The trade-offs between candidate solutions against agreed success criteria | That the preferred solution is not necessarily the best one — the preference is usually based on incomplete, implicit comparison. The matrix makes the comparison explicit and visible. |
| The 5 Whys | The causal chain between a visible symptom and its root cause | That the first answer to “why?” is almost never the root cause — it is the next layer of symptom. Each Why peels back one layer of invisibility. The root cause is the Why that has no further Why beneath it. |
| Causal Loop Diagram (CLD) | The feedback loops — reinforcing and balancing — that produce system behaviour over time | That a vicious cycle is self-sustaining regardless of individual effort. The R1 reinforcing loop in NHS corridor care is invisible without the diagram — making it visible is the intervention. |
| Root Cause Analysis (RCA) | The upstream causes behind a visible failure or adverse event | That the proximate cause — the last thing that happened before the failure — is almost never the root cause. RCA makes the causal chain visible so the intervention addresses the origin, not the trigger. |
| Pre-committed prediction | What you expected to happen before the data arrived | That attribution is almost always post-hoc rationalisation. The pre-committed prediction makes the original hypothesis visible — so the data can test it rather than confirm it. |
The five steps every framework agrees on
Strip away the domain-specific language from every framework and five steps remain. They are always the same five steps. They are always in the same order. Every framework is a different set of tools for executing one or more of them.
Each step links to the relevant concept page — click to explore further.
Deming: distinguish common cause from special cause — don’t react to noise. Shewhart: measure before acting. Norman: find what the design made invisible. FMEA: score detectability. Bootstrap CUSUM: let the data speak before attributing.
The instruction is always the same: what you think you are seeing is not what is causing the problem. Look at the structure, not the event.
Goldratt: map the constraint. Senge: find the feedback loop. Checkland: draw the rich picture. Altshuller: name the contradiction. Joiner: identify the level. Hurson: find the real problem.
The instruction is always the same: the structure is producing the behaviour. Change the structure — not the people, not the effort level, not the process within unchanged boundaries.
Goldratt’s Evaporating Cloud: what assumption underlies the contradiction? TRIZ: resolve in a different dimension. Christensen: what job is actually being done? Norman: who decided the door should open that way?
The instruction is always the same: the constraint usually persists because of an assumption nobody has questioned. Making the assumption visible often dissolves the constraint.
Deming’s PDSA: plan, do, study, act — small cycles. Goldratt: exploit before elevating. Joiner: experiment before scaling. Bootstrap CUSUM: pre-committed prediction at the specified confidence threshold. FMEA: test detectability before deployment.
The instruction is always the same: don’t bet the organisation on an untested idea. Make the prediction visible before the data arrives — so the data can test it, not confirm it.
Goldratt’s Step 5: don’t let inertia become the next constraint. Deming: the cycle never ends. Senge: double-loop learning. Bootstrap CUSUM: monitor continuously for the next change point.
The instruction is always the same: you have made one invisible thing visible and addressed it. The system has changed. Something else is now invisible. Start again.
Why the loop never ends
Every framework is iterative because visibility is not a permanent condition. Making something visible changes the system — which creates new invisible things. The discharge constraint becomes visible through a causal loop diagram; it is addressed through shared budgets; the constraint moves to GP access; GP access becomes the new invisible problem. The five steps do not produce a final solution. They produce a method for continuous navigation through a system that is always partly invisible.
Bootstrap CUSUM is the instrument that detects when the system has changed — when a new invisible thing has become visible in the data. The flat line tells you the constraint is unchanged. The change point tells you something structural has shifted. Both are information. Both are visibility.
Bootstrap CUSUM — making structural change visible
Bootstrap CUSUM (the StepChange Analyzer) sits at Steps 1 and 4 of the generic model. At Step 1, it makes visible what common cause variation and measurement noise conceal: whether a genuine structural shift has occurred in a time series, and when. At Step 4, it is the Study step of PDSA — the honest test of whether the pre-committed prediction was confirmed by the data.
Its relationship to the visibility theme is precise. Every other visibility tool on this page makes a structural truth visible to human observation — the control chart makes variation visible to the eye, the Evaporating Cloud makes the contradiction visible to the mind, FMEA makes failure risk visible to the analyst. Bootstrap CUSUM makes structural change visible in data — and does so with a specified confidence level, a precise date, and a statistical threshold that cannot be moved after the fact.
Most improvement evaluation is retrospective: an intervention is implemented, the metric improves, and the improvement is attributed to the intervention. The attribution is almost always invisible — nobody wrote down what they expected to happen before the data arrived, so any movement in the data can be credited to any intervention. The pre-committed prediction makes the original hypothesis visible before the data arrives. Bootstrap CUSUM then tests it. The prediction was either confirmed or it was not. That result is visible, explicit, and cannot be reinterpreted after the fact.
This is the same principle as FMEA detectability applied to improvement evaluation: make the failure mode (wrong attribution, regression to the mean, seasonal variation) visible before it has the chance to masquerade as success.
The five steps are the why — the generic model that every improvement framework independently arrived at. The 7-step method is the how — the operational sequence for applying the five steps in practice with a team.
Step 1 of the 7-step method (list symptoms) is the five-step model’s Step 1 (make it visible). Steps 2–4 of the 7-step method (measure, root cause, test constraint) are the five-step model’s Steps 2 and 3 (see the structure, challenge the assumption). Step 7 of the 7-step method (PDSA with Bootstrap CUSUM) is the five-step model’s Step 4 (test honestly). The same logic, at different levels of abstraction.
How this site is organised around visibility
Every page on this site is a visibility tool. The taxonomy is:
| What we make visible | The tool | The invisible thing it addresses |
|---|---|---|
| Structural change in data | Bootstrap CUSUM — StepChange Analyzer | Whether an improvement is genuine or seasonal, random, or definitional |
| Type of variation | Common cause vs special cause | Whether to act on a data point or ignore it |
| The binding constraint | Theory of Constraints | Which bottleneck is actually limiting throughput |
| The structural contradiction | Finding the real constraint | Why the constraint has persisted despite repeated fixes |
| The level of the fix required | Joiner’s levels of fix | Whether the intervention has the authority to reach the constraint |
| Feedback loop structure | Causal loop diagrams | Why the system keeps producing the same outcomes despite interventions |
| Regression to the mean | Regression to the mean | Whether improvement after a bad period is structural or statistical inevitability |
| Trade-offs between solutions | The evaluation matrix | Which solution is actually best against agreed criteria — not just most politically convenient |
| The original hypothesis | Pre-committed prediction | What was expected before the data arrived — so attribution is honest |
Honest evidence of change
That’s what “honest evidence of change” means. Not that the people measuring are honest while others are dishonest. But that the method makes the right things visible — the structural change, the date it occurred, the confidence level, the balancing measures — so that the data is allowed to say no. A flat Bootstrap CUSUM line is not a failure. It is the most important visibility of all: the constraint is still there, still invisible to the intervention being applied, still waiting to be found.
Make your data visible
Upload your time-series data to the StepChange Analyzer. Bootstrap CUSUM will make the structural change point visible — or confirm the flat line that tells you the constraint has not yet been reached.
▶ Open the StepChange Analyzer