Common Cause Variation — Improving a Stable System

Bootstrap CUSUM has found no step change. The system is stable — fluctuating within a predictable range, but not structurally shifting. This is Joiner’s “common cause highway” (p.140, Fourth Generation Management): the process is doing exactly what it is designed to do. If that level is unacceptable, the only way to improve it is to redesign the system. Do not tamper.

What “no change detected” means

When Bootstrap CUSUM finds no statistically significant change point, it is telling you that the process has been operating at a stable level throughout the period analysed. The variation you can see in the data — the monthly ups and downs — is common cause variation: the normal, expected output of a system behaving consistently with its own design.

This finding has two very different meanings depending on whether the stable level is acceptable or not.

The common cause highway

Joiner’s metaphor on page 140 of Fourth Generation Management is the “common cause highway”: the system is on a road, and without a structural change, it will stay on that road. The lane may be wide or narrow (more or less variable) and the road may be heading in a direction you do not want — but the vehicle will not leave the road by itself. It will not improve spontaneously. And it will not respond to the driver reacting to every bump in the tarmac.

The highway metaphor makes three things precise:

• The road is the system. The performance you observe is the output of the system’s design — its processes, its incentive structures, its resources, its boundaries. To change where the road goes, you must change the road, not steer harder.
• The lane width is the common cause variation. Some systems have wide lanes — high month-to-month variability that is still predictable within a range. Others have narrow lanes — consistent and tightly controlled. Narrowing the lane (reducing variation) requires changing the system, not reacting to individual data points.
• Reacting to bumps is tampering. Every time a manager reacts to a single month’s bad number with an intervention, they are steering in response to road texture rather than road direction. The cumulative effect of such reactions is to add variation — to widen the lane — without changing the direction of travel.

The cardinal rule — do not tamper

Deming’s funnel experiment is the clearest demonstration of tampering. A marble is dropped through a funnel onto a target. With no intervention, the marbles cluster around the target — common cause variation. If the operator adjusts the funnel after each drop to compensate for where the last marble landed, the marbles scatter further from the target with each adjustment. Tampering makes things worse.

In management terms, tampering is any intervention made in response to common cause variation — a data point that is within the system’s normal range — treated as if it were a special cause requiring a specific response. The consequences are:

• Increased variation. Each reaction adds noise. The system becomes less predictable, not more.
• False attribution. When the metric improves in the month after an intervention — as it statistically will do some of the time, by regression to the mean — the intervention is credited with an improvement it did not cause. This reinforces the behaviour of reacting to data.
• Staff demoralisation. Teams learn that every dip in performance triggers a management response. Data reporting becomes a political exercise in managing the reaction rather than an honest analysis of the system.
• Masking the real problem. Constant reactive interventions obscure the underlying stable level of the system. It becomes impossible to see the road clearly because the driver keeps adjusting.

How to actually improve a stable system

Reducing common cause variation — shifting the stable level of the system — requires structural change at the level where the system is actually designed. Joiner’s levels of fix provide the framework: the question is not “what can we do?” but “at what level does the constraint sit, and who has the authority to change it?”

Bootstrap CUSUM on a stable system

Bootstrap CUSUM is at its most useful as a prospective monitoring tool on a system confirmed to be stable. Set a pre-committed confidence threshold (typically 95%). Upload data monthly as it arrives. The algorithm will detect the first structural change point — whether improvement or deterioration — against the clean, stable baseline. Because the baseline is stable, there is no ambiguity about attribution: whatever changed in the system at or just before the change point date is the candidate cause.

When the stable level is acceptable

Not every stable system needs to be improved. If Bootstrap CUSUM shows a flat line at a level that meets the purpose of the system — if the common cause variation is within acceptable bounds and the direction of travel is stable — the correct response is to hold it there and monitor.

The temptation to improve a system that is already performing acceptably is itself a form of tampering: introducing change for its own sake, or in response to external pressure to “do something,” risks destabilising a system that was working. Deming’s formulation applies here too: “if it ain’t broke, don’t fix it” is not complacency — it is the correct response to a stable, acceptable system.

The monitoring task is to watch for the first sign that the stable level is shifting — an early change point in a leading indicator, a seasonal pattern that has become a structural trend. Bootstrap CUSUM running continuously on the metric will detect that shift before it becomes entrenched.