5 lessons worth learning about quality management framework

Someone brings you a number that moved. Last month it was one figure, this month it is another, and the room wants to know what changed. Usually nothing changed. The number moves every month, because everything varies, and the meeting is about to spend an hour explaining a wobble.

The framework that fixes this is statistical process control, the quality management framework Walter Shewhart built at Bell Labs in the 1920s and W. Edwards Deming carried into industry. Six Sigma, total quality management and most of what followed run on the same idea. It separates the variation a process produces all the time from the variation that means something happened.

What to take away

Lesson 1: The two kinds of variation

Every repeated activity produces different results each time. Some of that spread is the ordinary noise of the system: small differences in inputs, timing, people, and conditions. None of those are individually identifiable, and all of them are always present. The rest comes from something specific that was not there before.

The distinction between common cause and special cause variation is the whole of it. Common cause variation belongs to the process. If you dislike it, you have to change the process. No amount of investigating individual results will find a reason.

Special cause variation belongs to an event: a new supplier, a broken tool, a person's first week, a holiday.

The two need opposite handling.

Common cause. Do not investigate the individual point. Change the system or accept the spread.

Special cause. Investigate the individual point, because there is something to find, and the trail goes cold quickly.

Getting this backwards is where the money goes. Investigating ordinary noise produces a stream of explanations that are stories rather than causes, and it trains people to have an explanation ready. Ignoring a genuine signal because it is inside the usual range means the trail is cold by the time the pattern is obvious.

Lesson 2: Draw the chart before you do anything else

Two numbers compared against each other cannot tell you which kind of variation you are looking at. Twenty numbers in time order usually can.

The cheapest version is a run chart: plot each result in the order it happened, draw a line at the median, and look. That alone kills most of the false alarms, because a point that looked dramatic in isolation turns out to be inside the ordinary swing. It costs nothing and needs no software beyond whatever you already have.

The stronger version adds limits calculated from the data's own variation. The NIST/SEMATECH e-Handbook of Statistical Methods is the standard free reference for what control charts are and how their limits are built, and the calculation is arithmetic, not exotic: an individuals chart puts its center line at the average of the points and its limits three of the process's own standard deviations either side, with that spread estimated from the average gap between consecutive points.

The essential property: the limits describe what this process does when nothing unusual is happening. They are not the specification or the target.

That last point causes more confusion than anything else here. A process whose points all sit inside its limits is predictable. Predictable is not the same as good. You can have a stable process that reliably misses what the customer needs. The honest reading of that chart is that nothing is going wrong, and the process itself is the problem.

Lesson 3: What counts as a signal

A single point outside the limits is the obvious one. It is not the only one, and it is not the most useful.

Patterns worth treating as signals, in rough order of how often they matter:

Two disciplines make these useful. Decide the rules in advance, before you look at the data, because a rule chosen after seeing the chart only confirms what you already believed.

Write down what you concluded and what you did, since a chart's value accumulates over months and evaporates if nobody records events beside the points.

Lesson 4: Tampering: making it worse by responding

The counterintuitive part: if a process produces only common cause variation, adjusting after each result makes the spread wider. Move the setting up after a low result and down after a high one, and the output varies more than if you left it alone.

Your correction lands on top of the next ordinary swing instead of canceling it.

This is no subtle statistical curiosity. It describes much of ordinary management: the weekly figure that triggers a fix, staffing adjusted after every busy day, pricing tweaked after every soft month.

Each response is reasonable alone, but together they add variation that was not there before and consume attention needed to change the process.

You can watch this happen with a coin and a piece of paper in ten minutes. Write down a target, then record each toss as a small error above or below it, and run the sequence twice: once leaving the setting alone, once correcting it by the size of the last error. The corrected sequence is visibly wilder. It is the same point Deming made with his funnel and his marble, and doing it once stops the argument being theoretical.

The practical rule: only act on individual results when the chart says a special cause is present. Otherwise your improvement work is aimed at the process, not at points.

Lesson 5: Getting from here to a chart that runs itself

You do not need a program for this. Pick one measure that somebody already argues about, and do these in order.

Where the thing you want to track is a count of defects rather than a measurement, the chart type differs, and the attributes control charts section of the NIST/SEMATECH e-Handbook of Statistical Methods covers that case. The choice of chart matters less than the habit of plotting in time order at all.

Choosing which measure is worth this treatment is a separate question, with definitional traps of its own in operating processes metrics. And when nobody agrees what an acceptable result is, no chart will settle it — that is a quality management problem rather than a plotting one.

Reading someone else's improvement claim with this in mind comes down to two questions: was the change a special cause or inside the ordinary spread, and was the expectation written down before the data arrived? The second is the same discipline used in strategic planning.

Common questions

How many data points do we need before this is meaningful?

Enough to see the ordinary spread, which in practice means somewhere in the twenties for a start and more for confidence. With fewer than that you can still plot in time order and learn something, as long as you do not calculate limits and treat them as settled. Limits from six points will move a lot when the seventh arrives.

Our measure is monthly. Is that too slow?

Often, yes. Monthly data takes years to show a shift, and by then the cause is unrecoverable. If the underlying events happen daily or weekly, record them at that frequency even if you report monthly. The reporting cadence and the collection cadence are separate decisions and get collapsed by habit.

Does this apply to work that is not manufacturing?

The reasoning does: response times, error counts, days to complete something, and volumes vary in the same two ways, and the same two responses apply.

Service work often has less stable inputs, so more of what looks like a signal is a change in the mix of work arriving. Split by type before concluding.

Someone says our process is out of control. What does that actually mean?

In this vocabulary it means the chart shows a special cause, so the process is not currently predictable. It says nothing about whether the results are acceptable. The phrase gets used as an insult and it is a technical description, which is worth clarifying before the conversation goes badly.