What is PDCA (Plan-Do-Check-Act)?

PDCA (Plan-Do-Check-Act) is a four-stage iterative management method used to control and continuously improve processes and products. Originated by Walter Shewhart and popularized by W. Edwards Deming, the cycle moves through Plan, Do, Check, and Act, then repeats, embedding learning from each iteration into the next.

TL;DR

Four phases, one loop: Plan a change, Do it on a small scale, Check the data against the prediction, Act to standardize or revise.
Small-batch testing beats big-bang rollouts: PDCA contains risk by validating changes on a pilot before they reach the full system.
The Check step is where most teams fail: Skipping data review converts PDCA into "Plan-Do-Hope" and stalls improvement.
Works wherever a process repeats: manufacturing, healthcare, software releases, and quarterly OKR cycles all run on the same loop.

Shewhart's 1939 cycle and Deming's reframing in postwar Japan

Walter A. Shewhart sketched a three-step "specification, production, inspection" cycle at Bell Labs in 1939, framing quality control as a circular, not linear, activity. W. Edwards Deming carried the model to Japan in 1950, where he taught it to engineers at JUSE (Union of Japanese Scientists and Engineers) as part of postwar industrial reconstruction.

Toyota absorbed the loop into what became the Toyota Production System. Deming's variant, with "Check" later swapped for "Study" (PDSA), spread back to Western industry through the 1980s quality movement.

The four phases, side by side

Each phase has a distinct question it answers and a distinct deliverable it produces. The table below maps the cycle as a single comparison instead of four prose blurbs.

Phase	Core question	Primary activity	Output	Most common failure
Plan	What problem are we solving and what change do we predict will fix it?	Diagnose the current state, set a measurable target, design the test	Hypothesis, success metric, pilot scope	Skipping root-cause analysis, jumping to a solution
Do	Does the change behave as expected when we run it?	Implement the change on a small scale, capture data	Pilot data, observations, anomalies	Scaling before validation, no data capture
Check	Did the result match the prediction?	Compare actual vs predicted, look for confounders	Decision: adopt, abandon, or iterate	Skipping the review or rationalizing failures
Act	How do we standardize or refine?	Codify what worked, document the standard, plan the next loop	Updated standard work, next PDCA cycle	Treating Act as "we're done" instead of "next loop"

A useful field test: if a team cannot name the prediction they made in Plan, they are not running PDCA. They are running "try things and report on them," which is a different and weaker loop.

Where PDCA outperforms one-shot project plans

PDCA's value shows up most clearly when the problem is poorly understood, the cost of being wrong is high, or the environment keeps shifting. A 2019 study at a private hospital documented hand hygiene compliance rising from 48% to 60% after one PDCA cycle (PMC, Karaaslan et al., 2019), with the gain attributed specifically to the Check phase exposing which staff groups and shifts lagged.

The headline number is small. The mechanism is the point: the loop forces the team to look at data they would otherwise skip.

Three conditions where PDCA tends to beat a fixed project plan:

High uncertainty about cause and effect. When you do not know which lever moves the metric, a Plan-Do-Check loop costs less than a six-month rollout that misses.
Recurring processes. Anything that runs more than once a quarter benefits from a feedback loop. One-time projects do not.
Cross-functional change. When the fix touches multiple teams, the Check step surfaces who is and is not following the new standard.

Learning is not compulsory; neither is survival.

― W. Edwards Deming, statistician and quality theorist

Where PDCA rollouts typically break

The cycle is simple. Implementing it well is not. The failure modes cluster in three places.

The Check step gets skipped

Teams plan, execute, then immediately move to the next initiative without ever comparing actual results against the prediction made in Plan. Without Check, there is no learning loop, only a project pipeline.

Plan substitutes activity for analysis

Spending two weeks building a Gantt chart is not Plan. Plan is naming the hypothesis, defining what would falsify it, and choosing a pilot small enough to fail safely.

Teams that treat Plan as scoping rather than hypothesizing tend to run cycles that confirm whatever they already believed.

Act is interpreted as "we shipped it"

Act has two outputs: a standardized procedure for what worked, and a fresh Plan for what to try next. Stopping at "we shipped it" turns PDCA into a one-shot project, which is exactly the thing PDCA exists to replace.

A useful diagnostic: a team running real PDCA can point to the previous cycle's Act output as the current cycle's starting standard. If that lineage does not exist, the loop has been broken.

PDCA in healthcare, manufacturing, and knowledge work

The same four steps adapt across contexts, but the artifacts change. In manufacturing, Plan produces a process map and a control chart; in software, Plan looks more like a hypothesis doc and an A/B test design.

PDCA also maps cleanly onto the quarterly OKR cycle: objective-setting is Plan, execution is Do, the OKR check-in is Check, and the OKR retrospective is Act. Teams already running OKRs are already running PDCA, just with different vocabulary.

When not to use PDCA

PDCA is not the right tool for every problem.

One-off decisions with no second iteration. A pricing change rolled out once organization-wide cannot complete a feedback loop in any useful sense.
Emergencies that need immediate response. A production outage needs incident response, not a Plan phase. Run PDCA on the postmortem, not the fire.
Pure exploration with no hypothesis. When the team genuinely does not know what to test, design-thinking divergence or fishbone diagram root-cause work comes first; PDCA starts once a hypothesis exists.
Static processes. A process that has not changed in five years and is not failing does not need a continuous-improvement loop running on it.

A contrarian read worth holding: PDCA is most often broken not by skeptics, but by enthusiasts who run loops on processes that did not need improving. Pick the targets that matter; ignore the rest.

Frequently asked questions

What does PDCA stand for?

PDCA stands for Plan-Do-Check-Act, a four-step iterative cycle for process improvement. Some practitioners use PDSA (Plan-Do-Study-Act), reflecting Deming's later preference for "Study" over "Check" to emphasize analysis rather than inspection.

What is the difference between PDCA and PDSA?

PDCA uses "Check," which Deming felt implied passive inspection. He later replaced it with "Study" to stress that the phase requires active analysis of what the data revealed about the prediction. The mechanics are identical; the word change is a framing correction.

Who created the PDCA cycle?

Walter A. Shewhart introduced a three-step "specification-production-inspection" cycle at Bell Labs in 1939. W. Edwards Deming expanded it into the four-step form and taught it to Japanese industry from 1950 onward, which is why it is often called the Deming cycle.

How long should one PDCA cycle take?

There is no fixed duration. Manufacturing teams often run hourly or shift-level cycles on a specific line; healthcare quality teams typically run monthly cycles tied to audit data; strategy teams running PDCA against quarterly objectives use 90-day loops. Match cycle length to how fast the underlying process produces signal.

How does PDCA relate to OKRs?

PDCA and OKRs share the same loop shape: define a measurable target, execute, review results, adjust. OKRs add the goal-setting and alignment vocabulary; PDCA adds the disciplined process for closing the learning loop each cycle. Teams running quarterly OKRs with a structured check-in and retrospective are running PDCA.

What is the most common reason PDCA fails?

The Check phase gets skipped. Teams plan and execute, then move to the next initiative without comparing the actual result to the prediction they made in Plan. Without that comparison, there is no learning, and the cycle degrades into a project pipeline.

Running PDCA inside your OKR cycle

PDCA does not replace a strategic planning process or an OKR program. It sits underneath them as the loop that turns each cycle into the next one's input.

Strong teams treat their quarterly business review as the Check step, the planning session as the Act-into-Plan handoff, and the resulting objectives as the Do phase about to start. Once that pattern is named, the cycle stops being a quality-management diagram and becomes the rhythm of how the organization learns.