Collect at least 5 measurements before improving a workflow — distinguish common-cause variation (inherent) from special-cause variation (fixable)

Why This Is a Rule

W. Edwards Deming and Walter Shewhart identified two fundamentally different types of process variation that require opposite responses. Common-cause variation is inherent system fluctuation — the natural range of outcomes a stable process produces. Your commute varies between 25-35 minutes due to normal traffic patterns. Special-cause variation is identifiable disruption — a specific, assignable event that pushes the process outside its normal range. Your commute takes 90 minutes because of an accident.

The critical insight is that these two types of variation require opposite interventions. Common-cause variation is reduced by changing the system itself (move closer to work, change your route). Special-cause variation is addressed by removing the specific cause (accident cleanup). Treating common-cause as special-cause (investigating why today's commute was 33 minutes instead of 28) wastes effort chasing noise. Treating special-cause as common-cause (redesigning the whole workflow because one execution was disrupted by a power outage) wastes effort fixing what isn't broken.

Five measurements is the minimum sample that reveals the process's natural range. With fewer than five data points, you can't distinguish normal variation from an anomaly. A single slow execution could be common-cause (the process is sometimes slow) or special-cause (something specific went wrong this time). Five measurements show you the baseline so you can tell the difference.

When This Fires

• Before attempting to improve any workflow — ensure you have enough data to distinguish variation types
• When a single bad execution makes you want to redesign the whole process
• When a workflow's performance seems inconsistent and you're not sure if that's normal
• Complements Measure actual elapsed time over 3-4 cycles before optimizing — felt difficulty systematically misidentifies bottlenecks (measure before optimizing) with the specific statistical reasoning for the measurement threshold

Common Failure Mode

Reacting to single data points: one bad workflow execution triggers a redesign. This is Deming's "tampering" — adjusting a stable process in response to common-cause variation, which actually increases variation rather than reducing it. The single bad execution may have been well within the process's normal range. Without baseline measurements, you can't know.

The Protocol

(1) Before improving any workflow, collect at least 5 measurements of its key metric (elapsed time, error rate, output quality). (2) Calculate the range: what's the highest and lowest measurement? This is your process's natural variation band. (3) For future executions, ask: "Is this measurement inside or outside the natural range?" Inside → common-cause variation. Don't react to individual data points; improve the system if the whole range is unacceptable. Outside → special-cause variation. Investigate what specific event caused this outlier and remove it. (4) Only redesign the workflow when the entire common-cause range is unacceptable — meaning even the best executions don't meet your standard. (5) After any improvement, collect 5 new measurements to establish the new baseline. Don't assume the improvement worked — verify it statistically.