Common Cause vs Special Cause — Which Type of Variation Do You Have?
The single most important distinction in improvement work. Confuse the two and every response you make will be wrong — either tampering with a stable system or ignoring a real signal. This page tells you which type you have, how the StepChange Analyzer (Bootstrap CUSUM) detects the difference, and exactly what to do next.
If the StepChange Analyzer (Bootstrap CUSUM) detects a change point, you have a special cause signal — something specific shifted the system. If it detects no change point, the variation is common cause — the system is stable and reacting to it will make things worse.
The response to each type is opposite. Special cause: find and address the specific cause. Common cause: do not tamper — redesign the system or wait. Applying the wrong response to either type produces worse outcomes than doing nothing.
☰ Contents
The two types — at a glance
The normal, expected variation of a stable system. The process is doing exactly what it is designed to do. The ups and downs you see month to month are noise — predictable within a range, produced by the system itself.
System state: stable
Correct response: do not tamper
To improve: redesign the system
A non-random signal that something specific changed. A sustained shift to a new level, a spike, a trend. Something outside the system’s normal behaviour caused this — a specific, identifiable event.
System state: shifting
Correct response: investigate the cause
To improve: address the specific cause
The distinction was first made precisely by Walter Shewhart in 1931 — he called them “chance causes” and “assignable causes.” Deming developed it into a management principle. Joiner built it into a practical decision framework. The terminology has changed but the insight is the same: variation has two sources, and they require opposite responses.
How to tell which type you have
The StepChange Analyzer (Bootstrap CUSUM) does this automatically. Upload your time-series data, run the analysis, and the result is unambiguous:
📊 Reading the Bootstrap CUSUM result
The change point may be an improvement (the metric moved in the right direction) or a deterioration (it moved in the wrong direction). Both are special causes. Both require investigation before attribution — the date is the starting point, not the conclusion. Go to Change detected: what to do next.
This has two very different meanings: the stable level may be acceptable (hold steady, monitor) or unacceptable (the system needs redesigning, not reacting to). In either case, do not tamper — launching a new intervention in response to a single bad month is reacting to noise. Go to No change detected: what to do next.
The two mistakes — and why both make things worse
Shewhart identified two types of error. Deming demonstrated both with the funnel experiment. They are not symmetric — Mistake 1 is far more common in practice — but both produce worse outcomes than the correct response.
| Mistake | What it looks like | Why it makes things worse |
|---|---|---|
| Mistake 1 Treating common cause as special cause |
Reacting to every bad month with an action plan. Calling a meeting when the metric dips. Changing the process in response to normal fluctuation. Launching a new initiative because last quarter was worse than the previous one. | Each reaction adds variation to a stable system — Deming called it tampering. The system becomes less predictable. Staff learn that numbers trigger reactions regardless of whether they contain a signal. Data reporting becomes political. Performance worsens on average. |
| Mistake 2 Treating special cause as common cause |
Dismissing a genuine shift as “just noise.” Not investigating a sustained deterioration. Assuming a real improvement will sustain itself without standardising the conditions that caused it. | A deterioration goes unaddressed and compounds. An improvement drifts back because its cause was never identified or standardised. Special causes that are not identified recur — sometimes repeatedly, sometimes with increasing severity. |
Monthly performance reviews that respond to every data point with an action plan are institutional Mistake 1. The pressure to “do something” in response to a bad number is real and understandable — but if the number is common cause variation, any action taken is a reaction to noise. Bootstrap CUSUM applied to the metric will show a flat line throughout: no action plan has changed the system. The activity generated is real. The improvement is not.
What to do next — decision table
| Bootstrap CUSUM result | Type of variation | Stable level acceptable? | Next step |
|---|---|---|---|
| Change point — improvement direction | Special cause | Better than before | Investigate the cause. Standardise if genuine. Check balancing measures. Path A → |
| Change point — deterioration direction | Special cause | Worse than before | Investigate the cause. Triage and stabilise. Apply Joiner levels to find the right response level. Path A → |
| No change point — stable at acceptable level | Common cause | Yes | Hold steady. Do not tamper. Monitor with Bootstrap CUSUM. Path B → |
| No change point — stable at unacceptable level | Common cause | No | Redesign the system — not the process. Stratify, experiment, disaggregate. Path C → |
| No change point — intervention recently applied | Common cause so far | Unclear — too soon | Wait. Do not add further interventions. Re-run as more data arrives. Path B → |
| No change point — multiple interventions applied | Common cause | No | Interventions have not reached the constraint. Move up a Joiner level. Joiner levels → |
Real examples
📋 What each type looks like in practice
Run the test — find out which type you have
Upload your time-series data to the StepChange Analyzer. Bootstrap CUSUM will detect whether a structural shift has occurred, date it precisely if so, and give you the unambiguous starting point for the right response.
▶ Open the StepChange Analyzer