The PDSA Cycle

The PDSA cycle traces its origins to physicist Walter Shewhart, who developed the underlying concept at Bell Telephone Laboratories during the 1920s.1 Shewhart later introduced this cycle to W. Edwards Deming, an American engineer and statistician who would become Shewhart's most influential student and the figure most closely associated with the cycle's later development and global spread.

Deming carried this model to Japan starting in 1950, when the Japanese Union of Scientists and Engineers invited him to teach statistical quality control to Japanese industry.2 Japanese engineers subsequently adapted Deming's teaching into what became known as the Plan-Do-Check-Act cycle, a variant that spread widely through quality management practice and remains common today, particularly within ISO 9001 contexts.

Deming himself, however, consistently preferred a different formulation: Plan-Do-Study-Act, with Study replacing Check as the third step. He viewed this distinction as substantive rather than cosmetic, since a Check step primarily asks whether a change succeeded or failed, while a Study step asks what the team actually learned by comparing predicted results against a documented theory. Deming referred to his version as the Shewhart Cycle, honoring his mentor, and continued refining it throughout his career, developing the more explicitly named PDSA model shortly before his death in 1993.

Why Deming Insisted on Study Over Check

Deming's insistence on Study rather than Check reflects a deeper philosophy about how organizations actually learn from their own improvement efforts. A Check step, in Deming's view, focuses narrowly on the implementation of a change and its resulting success or failure, prompting a correction to the plan only if that check reveals failure. This framing treats each cycle as a pass-or-fail test, offering little structured mechanism for extracting deeper insight beyond a binary verdict.

The Study step demands considerably more from a team. Deming's approach requires predicting results before implementing a change, then studying actual outcomes and comparing them explicitly against that prediction, regardless of whether the change ultimately succeeded or failed. This comparison generates new knowledge even from an unsuccessful cycle, since a prediction that fails to match reality reveals a flaw in the underlying theory driving the change, information a simple pass-or-fail check would never surface directly.

This distinction matters considerably for how organizations use their improvement cycles over time. A team using PDCA's Check step might abandon an unsuccessful change without fully understanding why it failed, since the check only confirmed failure without generating theory-level insight. A team using PDSA's Study step treats that same failure as a source of learning, revising its underlying theory before attempting a next iteration, which compounds knowledge across cycles rather than simply cycling through pass-or-fail attempts.

The Four Stages in Detail

The Plan stage begins the cycle by identifying a specific goal or purpose, formulating a theory about what change might achieve that goal, and defining the metrics that will determine success before any action occurs. This stage also requires committing to a specific, falsifiable prediction about what the data will show once the change takes effect, since this prediction becomes the essential reference point the later Study stage depends on entirely.

The Do stage follows, implementing the components of the plan on whatever scale the team has chosen, ideally small enough to limit risk while still generating meaningful data. This stage often includes documenting problems and unexpected observations as they occur during implementation, since these real-time notes frequently prove valuable during the Study stage even when they fall outside the original prediction the team made.

The Study stage examines the results generated during the Do stage, testing the original plan's validity by comparing actual outcomes against the prediction made during planning. This comparison looks specifically for signs of progress and genuine success, but equally for problems or areas requiring further improvement, since Deming intended this stage to generate learning regardless of which direction the results ultimately pointed. The Act stage closes the cycle, integrating whatever learning the Study stage generated to adjust the original goal, revise the methods used, reformulate the underlying theory entirely, or expand a successful change to a broader scale.

Applying PDSA in Practice

PDSA proves especially well suited to situations where a team wants to test whether a single, specific process change actually leads to genuine improvement before committing broader resources to it. A hospital ward testing a new patient handoff procedure, for example, might apply the change to one shift or one unit first, predicting a specific reduction in reported communication errors, rather than rolling the new procedure out across every unit simultaneously without any evidence it actually works. This small-scale approach limits the cost of being wrong while still generating real data about whether the underlying theory holds.

The Institute for Healthcare Improvement adapted Deming's PDSA cycle specifically for healthcare settings, and the model has since become a standard quality improvement tool across hospitals and health systems.3 This adoption reflects healthcare's particular need for iterative, evidence-based testing before scaling changes that directly affect patient safety, where the cost of an unstudied, poorly designed change rolled out broadly can be severe.

Organizations applying PDSA successfully typically chain multiple cycles together rather than treating a single cycle as a complete solution. An initial cycle might reveal that a proposed change produces only partial improvement, prompting a revised theory and a second cycle that refines the approach based on what the first cycle's Study stage revealed. This iterative chaining reflects PDSA's core philosophy directly, since Deming designed the cycle as a continuous engine for learning rather than a single-pass tool applied once and then set aside.

Common Pitfalls in Execution

Despite PDSA's conceptual simplicity, research examining real-world application has found that many organizations struggle to execute the cycle with genuine fidelity to its underlying methodology. A retrospective study of front-line healthcare improvement teams found that fidelity to proper PDSA methodology remained low even after multiple rounds of dedicated support and training, with teams frequently struggling to understand the methodology correctly and apply it consistently in practice. This finding suggests that PDSA's apparent simplicity can mask real difficulty in disciplined execution.

One common failure mode involves skipping the explicit prediction step during planning, moving directly from a vague goal to implementation without committing to a specific, testable forecast of what the data should show. Without this prediction on record, the Study stage loses its essential reference point, collapsing back into something closer to a simple Check step regardless of what the team calls it. Teams should treat the prediction as a mandatory, documented component of the Plan stage, not an optional refinement to add if time permits.

Another frequent shortfall involves treating PDSA as a single, isolated event rather than part of an iterative series using regular data over time. A team that runs one cycle, implements whatever the Act stage suggests, and never returns to test further has captured only a fraction of the methodology's value. Executives sponsoring improvement initiatives should ask specifically whether teams are running PDSA as a genuine iterative series, since this distinction separates organizations that build compounding improvement capability from those that merely go through the cycle's motions once.

• 1PDCA, Wikipedia
• 2PDCA Cycle: Guide, Practical Example & Template, SI Labs
• 3PDSA cycle, EBSCO Research