Common Cause Variation, Explained

Common cause variation is the routine variation built into a process — the combined effect of many small influences that are present all the time. Ambient temperature, slight differences in materials, ordinary human rhythm, the design of the workflow itself: no single one dominates, and no single one can be blamed for any particular result. A process showing only common cause variation is called stable, and its defining virtue is predictability — you cannot say what the next value will be, but you can say the range it will almost certainly fall within.

How it’s used

The concept earns its keep by dictating the correct management response. Because common cause variation comes from the system as a whole, it cannot be reduced by reacting to individual results — there is no culprit behind any single point, so demanding an explanation for one produces fiction. Worse, adjusting the process in response to routine ups and downs — what quality professionals call tampering — injects new variation on top of the old. W. Edwards Deming spent decades demonstrating that this well-intentioned habit reliably makes processes worse.

Reducing common cause variation requires changing the system itself: a better method, better materials, better design. That is management work, done through deliberate improvement projects — which is precisely what the DMAIC roadmap exists to structure.

A worked example

A call center’s average handle time drifts between bands day to day — some days quicker, some slower, with no pattern a control chart can find. A new manager, unaware of the distinction, demands a written explanation for every day above average. The team learns to produce plausible stories, morale sinks, and handle time does not move, because nothing about the system has changed. The improvement finally comes from a chartered project that redesigns call routing and the knowledge base — a system change, aimed at the whole distribution rather than at last Tuesday.

• If a point sits inside the control limits with no unusual pattern, do not demand a special explanation for it.
• Never adjust a stable process in response to a single result — tampering adds variation rather than removing it.
• Direct improvement effort at the system, through a scoped project, not at the people working inside it.
• Remember that stable does not mean acceptable: a process can be perfectly predictable and predictably poor.

Common cause variation has no villain — only a system. And systems are changed, not blamed.

The common-versus-special distinction is one of the first ideas we teach. It appears in our free White Belt course, is developed properly in Yellow Belt ($129, about 14 hours), and becomes daily working knowledge at Green Belt, where control charts turn the concept into a decision rule you can defend.