PDCA Cycle: Treating Every Change as an Experiment

The PDCA cycle — Plan, Do, Check, Act — is an iterative improvement method rooted in Walter Shewhart's statistical quality-control work at Bell Labs in the 1920s–30s and popularized by W. Edwards Deming, whose lectures in postwar Japan seeded its adoption across Japanese manufacturing and, later, lean and continuous-improvement practice worldwide. An accuracy point most retellings skip: Deming himself preferred and taught PDSA — Plan, Do, Study, Act — arguing that 'Check' suggests inspection against expectations while 'Study' demands learning from what happened, including the unexpected; he attributed the underlying cycle to Shewhart. The four phases: Plan — identify the problem, analyze root causes, form a hypothesis ('if we change X, metric Y improves because Z') and define success criteria before starting; Do — run the change small, as a controlled trial; Check/Study — compare results against the prediction, studying deviations rather than explaining them away; Act — adopt and standardize if the hypothesis held, abandon or adjust if it didn't, and start the next turn either way. Known failure modes: Plan-Do-Plan-Do loops that never study results, success criteria defined after the results are in, 'Act' meaning a report rather than a standard, and cycles run on gut feel without a falsifiable hypothesis. On an argument tree, each cycle becomes an argued experiment: the hypothesis is a claim, the Plan's root-cause analysis is its supporting case, Study results attach as evidence for or against, and the Act decision is recorded with its reasoning — so improvement knowledge accumulates instead of evaporating between cycles. In decision-quality terms, PDCA feeds the commitment-to-action element and disciplines information gathering; the argument tree supplies the sound reasoning across cycles.

All decision frameworks
Framework guide · organizational alignment

PDCA Cycle

Plan, Do, Check, Act — the humble loop behind a century of quality improvement. Deming wanted one word changed, and the change is the whole method.

TL;DR

PDCA treats every change as an experiment: hypothesize, trial small, study the results, then standardize or abandon — and loop:

  • Shewhart built it, Deming spread it — and taught it as PDSA: Study, not Check, because the point is learning, not inspection
  • Plan means a falsifiable hypothesis — 'if we change X, Y improves because Z' — with success criteria set before the trial
  • Act means standardize or abandon — a cycle that ends in a report instead of a changed standard didn't act
  • On an argument tree, each cycle is an argued experiment — and what was learned survives to the next one

What PDCA is — and the one-word correction Deming insisted on

The cycle's bones come from Walter Shewhart, the Bell Labs physicist whose 1920s–30s statistical quality-control work introduced the idea that improvement follows a repeating loop of specification, production, and inspection — refined into a cycle of hypothesis and test. W. Edwards Deming carried it further and, through his lectures in postwar Japan, into the practice of Japanese manufacturing — from which lean, kaizen and modern continuous improvement descend. Deming, characteristically, credited it as the Shewhart cycle; Japanese practice named it the Deming cycle; the abbreviation PDCA stuck worldwide.

The four phases: Plan — define the problem, analyze root causes, and commit to a falsifiable hypothesis: if we change X, metric Y will improve, because Z — with success criteria written down before anything runs. Do — run the change small: one line, one team, one week; a controlled trial, not a rollout. Check — compare what happened against what the Plan predicted. Act — if the hypothesis held, adopt and standardize; if not, abandon or adjust; either way, the next turn starts from what this one learned.

And the correction: Deming himself preferred PDSA — Plan, Do, Study, Act — and was insistent about it. 'Check' smells of inspection: did the result pass? 'Study' demands more: what actually happened, including the parts nobody predicted? The distinction sounds pedantic and is instead the whole method — a cycle that only checks conformance learns nothing from surprises, and surprises are where the learning lives. We keep the common name and Deming's meaning. Context: decision-making models.

When to use it — and when not to

PDCA earns its keep when:

  • Improving a recurring process — support flows, deployment pipelines, onboarding, quality problems — anything that runs often enough for small experiments to read out.
  • The change is reversible and trialable. PDCA's power is cheap iterations; if you can pilot small, you can afford to be wrong fast.
  • Building an improvement culture. The loop teaches hypothesis-thinking: teams that run honest PDSA stop confusing activity with learning.

And where it fails or misfits:

  • Plan-Do-Plan-Do. The commonest corruption: teams ship change after change and never study results. Without the S, it's just churn with ceremony.
  • Success criteria after the fact. If 'what would success look like?' is answered after the data is in, every cycle succeeds and nothing is learned. Criteria date-stamp before the Do.
  • Act = a slide. A cycle that ends in a readout instead of a changed standard (or an explicit abandonment) has a hole where its fourth phase should be.
  • One-shot, irreversible decisions. PDCA is for iterating; a market entry or an acquisition doesn't get a second turn. Those need decision trees, scenarios, and the rest of the toolbox.

Step by step, with a worked example

Illustrative scenario: an invented support team whose first-response time has crept badly. One full turn:

  1. 1Plan — diagnose before hypothesizing. The team pulls a sample of slow tickets and finds a pattern: triage waits on a daily assignment meeting. Hypothesis: if tickets auto-route by category on arrival (X), median first-response time drops by a third (Y), because the assignment wait is the dominant delay (Z). Success criterion, written down now: median under 4 hours across two weeks, with no rise in re-routing rate (the counter-metric that catches gaming).
  2. 2Do — small. Auto-routing on two ticket categories, one team, two weeks. The rest of the flow unchanged, so the comparison stays clean.
  3. 3Study — against the prediction, including the surprises. Median fell to 3.6 hours — hypothesis holds. But re-routing rose in one category: the auto-router misfiles billing-adjacent tickets. That surprise is the phase's real yield; 'Check' would have shipped it as a pass.
  4. 4Act — standardize the win, cycle the surprise. Auto-routing becomes the documented standard for the categories where it held. The billing misfiling becomes the next cycle's Plan. Both decisions recorded with their reasoning.
  5. 5Turn again. The next cycle inherits the last one's evidence — which is the entire compounding logic of the method, and exactly what evaporates when cycles live in slide decks.

PDCA as an argument tree

In decision-quality terms, PDCA feeds commitment to action — it is the rare framework whose fourth phase is acting — and disciplines information: the Study phase generates evidence on a schedule. Its weak point is memory between cycles. On an argument tree:

Hypothesis → root claim

"Auto-routing cuts first-response time by a third because assignment wait dominates." Falsifiable, dated, with success criteria attached — before the trial runs.

Root-cause analysis → the supporting case

The ticket-sample evidence supports the claim; a teammate's alternative diagnosis (staffing, not routing) attaches as a counterargument, on the record before the experiment adjudicates.

Study results → evidence on the claim

The 3.6-hour median lands as support; the billing misfiling lands as a flagged surprise with its own node — visible, not buried in a readout appendix.

Act → a recorded decision, cycles → a chain

Standardize-or-abandon is recorded with reasoning, and the next cycle links back. A year of improvement becomes an auditable chain of argued experiments instead of a folder of decks.

The one-sentence version

PDCA supplies commitment and evidence-on-a-schedule; the argument tree supplies the sound reasoning that makes each cycle's learning survive to the next. See decision quality.

PDCA vs the alternatives

If your question is…Reach forWhy not PDCA
Which strategic objectives to improve towardBalanced ScorecardThe scorecard sets direction; PDCA is the loop inside one objective
Whether the organization can absorb a big changeMcKinsey 7SPDCA iterates within the system; 7S diagnoses the system
A one-shot, irreversible commitmentDecision trees / CBANo second turn means no cycle
Managing a register of standing risksEnterprise risk managementDifferent loop: monitoring exposure, not improving a process

Frequently Asked Questions

What does PDCA stand for?

Plan, Do, Check, Act — an iterative improvement loop. Plan: diagnose the problem, form a falsifiable hypothesis ('if we change X, metric Y improves, because Z') and set success criteria in advance. Do: run the change small, as a controlled trial. Check: compare results against the prediction. Act: standardize the change if the hypothesis held, abandon or adjust it if not, and begin the next cycle from what was learned. The cycle descends from Walter Shewhart's quality-control work and was spread worldwide through W. Edwards Deming's teaching.

What is the difference between PDCA and PDSA?

One word, and Deming considered it the important one. He taught the cycle as PDSA — Plan, Do, Study, Act — and objected to 'Check' on the grounds that it suggests inspection: did the result pass or fail? 'Study' demands learning: what actually happened, including the deviations and surprises nobody predicted — which is where improvement knowledge mostly lives. Deming credited the underlying cycle to Shewhart. In practice, use whichever name your organization knows, but run the third phase as Study: analyze the surprises instead of merely grading the outcome.

What is the most common PDCA mistake?

The Plan-Do-Plan-Do loop: teams ship change after change, hold a readout, and never genuinely study results against a prior prediction — activity mistaken for learning. Its enablers are the other classic failures: success criteria defined after the data is in (so every cycle 'succeeds'), hypotheses too vague to falsify ('improve communication'), and an Act phase that produces a slide rather than a changed standard or an explicit abandonment. The antidote is bureaucratically simple: write the hypothesis and criteria down, dated, before the Do begins.

Where does PDCA come from?

From statistical quality control. Walter Shewhart at Bell Labs developed the underlying cycle in the 1920s–30s as part of his work on process control; W. Edwards Deming refined and taught it — always crediting Shewhart — and his lectures in postwar Japan seeded its adoption across Japanese manufacturing, where it became central to kaizen and what the world later studied as lean production. The 'Deming cycle' name came from Japan; Deming himself called it the Shewhart cycle and taught it as PDSA.

How does PDCA work on an argument tree?

Each cycle becomes an argued experiment. The hypothesis is the root claim, dated and falsifiable, with success criteria attached before the trial; the root-cause analysis forms its supporting case, and alternative diagnoses attach as counterarguments before the experiment adjudicates between them. Study results land as evidence — including surprises, which get their own visible nodes rather than an appendix burial — and the Act decision is recorded with its reasoning. Because cycles link, a year of improvement work reads as an auditable chain of experiments rather than a folder of unconnected readouts.

Related frameworks

Run cycles that remember what they learned

Hypotheses as claims, criteria set before the trial, surprises as first-class evidence, and every Act recorded with its why.

Start Free — No Credit Card

Free forever for individuals