PDCA/PDSA Cycle

Learn from a small change before committing the whole system, and turn every test into an explicit decision.

In one minute

PDCA and PDSA are iterative improvement cycles:

1. Plan: define the problem, prediction, change, measures and test conditions.
2. Do: run the change on a limited scale and record what happened.
3. Study: compare results with the prediction and explain the difference.
4. Act: adopt, adapt or stop the change, then define the next cycle.

“Check” is often used in PDCA. “Study” makes the learning obligation clearer: the team is not merely checking whether a task was completed.

Best for: operational improvements, process controls, AI pilots and uncertain changes that can be tested safely.
Avoid when: immediate containment is required, experimentation would be unethical or the change cannot be reversed or bounded.

The problem it addresses

Improvement programmes often jump from idea to rollout. When results disappoint, teams cannot tell whether the idea was wrong, execution differed, conditions changed or the measurement was weak.

PDSA replaces rollout-first thinking with a prediction and a small test. The result becomes evidence for the next decision rather than a verdict on the people involved.

When to use it

Use PDCA/PDSA when:

• the causal effect of a change is uncertain;
• a future-state process needs testing before scale;
• an AI assistant is proposed for a bounded workflow;
• the team can collect evidence within a short cycle;
• implementation conditions vary across users or locations;
• a standard needs repeated refinement after launch.

Begin with the smallest test that can challenge the key assumption without exposing many users to risk.

When not to use it

Do not use PDCA/PDSA:

• instead of emergency containment or mandatory corrective action;
• when participants cannot give required consent or protection;
• to run an irreversible high-impact experiment;
• without a prediction or decision rule;
• when the test population cannot reveal the relevant risk;
• as a circle drawn around ordinary project execution.

Use FMEA to identify prospective failure modes before a risky test and Root Cause Analysis to investigate a significant observed failure.

Inputs required

• a specific problem or opportunity and baseline;
• a theory of how the proposed change will help;
• a written prediction;
• primary outcome and balancing measures;
• a bounded test population, duration and owner;
• data collection and observation plan;
• safety, privacy, approval and stop conditions;
• a decision rule for adopt, adapt or stop.

Step-by-step process

1. State the aim and baseline

Describe what should improve, for whom, by how much and by when. Record the current level and relevant variation.

2. Form a change theory

Explain why the proposed change should affect the outcome. Identify the assumption most important to test first.

3. Write a prediction

Before implementation, record what will happen, by how much, over what period and what unexpected effect might appear. A prediction makes later learning specific.

4. Design the smallest informative test

Choose a narrow user group, one team, one shift or a limited case type. Define normal, boundary and exception cases. Limit permissions and make rollback possible.

5. Choose measures and decision rules

Use:

• an outcome measure for the intended result;
• a process measure for whether the change operated as designed;
• a balancing measure for unintended harm or burden;
• qualitative observations that explain the numbers.

Define what evidence will lead to adopt, adapt or stop.

6. Do the test

Run the planned change, document deviations and capture observations close to the work. Do not silently repair the plan and then report that it worked as designed.

7. Study prediction against result

Compare expected and observed outcomes. Examine variation, exceptions, missing data and alternative explanations. Ask what the result teaches about the change theory.

8. Act and define the next cycle

• Adopt when evidence supports the change in the tested context.
• Adapt when the theory remains plausible but the design needs revision.
• Stop when risk, poor effect or a false assumption makes continuation unjustified.

Scaling is another hypothesis. Increase scope gradually and keep monitoring.

AI automation lens

An AI pilot should test a complete controlled workflow, not just model output quality. Record the model and prompt version, retrieval source, permissions, reviewer role and test dataset.

Useful measures include:

• correct task outcomes and material-error rate;
• abstention and escalation performance;
• reviewer acceptance and correction effort;
• subgroup or edge-case performance;
• privacy, security and policy incidents;
• latency, cost and downstream queue effects.

Use offline or shadow-mode tests before live action where consequences are meaningful. A successful ten-case pilot supports only a limited claim; it does not prove general safety or value.

Visual model

Text alternative: a question, prediction and measure lead to a bounded test. Observed results are compared with the prediction, after which the team adapts, cautiously expands or stops the change and begins the next learning cycle.

Text alternative: Plan, Do, Study and Act form a repeating cycle. Plan contains aim, prediction, measures and safeguards; Do runs a bounded test; Study compares prediction with outcome and balancing evidence; Act selects adopt, adapt or stop before the next cycle.

Interactive example

Scenario

A support team wants an AI classifier to route incoming tickets. The current correct-routing rate is 81%, median queue-to-agent time is 42 minutes and 6% of urgent cases are initially misrouted.

Your move

Design a first PDSA cycle that produces useful evidence without allowing the model to route live tickets autonomously.

Worked answer

Plan: predict that shadow-mode classification of 200 tickets from three common categories will achieve at least 90% correct routing while flagging at least 95% of urgent cases. Record subgroup results, abstentions and reviewer minutes. Stop if any urgent category has insufficient examples or sensitive data are exposed.

Do: run the model without changing live routing. Two agents independently label a sample and record ambiguous cases.

Study: compare the prediction with overall and category-level results, examine disagreements and estimate the effect on queue time and reviewer load.

Act: if urgent-case sensitivity misses the threshold, do not enable live routing. Adapt the taxonomy, add an urgency gate and test again. If results meet the rule, move to a small supervised live pilot with rollback.

Facilitation notes

• Require a written prediction before the test starts.
• Make the first cycle small enough to run quickly and safely.
• Record deviations; they are learning, not embarrassment.
• Use balancing measures to expose shifted burden or harm.
• Review disaggregated evidence when average performance can hide vulnerable groups.
• Separate a promising result from permission to scale.
• End every cycle with a named decision and next owner.

Expected output

A sound application produces:

• a measurable aim and baseline;
• an explicit change theory and prediction;
• a bounded test plan with safeguards;
• outcome, process and balancing measures;
• observed results and deviations;
• an adopt, adapt or stop decision;
• a documented next cycle, owner and review date.

Common mistakes

1. Skipping the prediction. The team cannot distinguish learning from hindsight.
2. Testing at full scale. Exposure increases before the idea is understood.
3. Measuring implementation only. “The tool launched” says nothing about the outcome.
4. Ignoring balancing measures. Time saved upstream may become review or recovery work elsewhere.
5. Changing the test silently. Results can no longer be interpreted against the plan.
6. Treating one cycle as proof. Context, variation and scaling remain untested.
7. Using Act to mean rollout. Stopping or adapting is a valid evidence-based decision.

Quality checklist

• The aim includes outcome, population, magnitude and time.
• The baseline and important variation are visible.
• The change theory and prediction are written before testing.
• The test is the smallest safe informative step.
• Outcome, process and balancing measures are defined.
• Stop, rollback and escalation conditions are explicit.
• Results are compared with the prediction.
• The decision is adopt, adapt or stop with reasons.
• Scaling is treated as another test.

Template

Knowledge check

A team launches an AI assistant to every employee, then plans to check adoption after three months. What is the main PDSA weakness?

A. Adoption should never be measured.
B. The team skipped a bounded prediction-led test and has no early outcome or balancing evidence.
C. Three months is always too short.
D. AI cannot be tested with PDSA.

Answer: B. A small, measured test should challenge the critical assumptions before broad exposure.

Related tools

• Uses opportunities from: Value Stream Mapping, Theory of Constraints
• Risk-checked with: FMEA, Mistake Proofing
• Supported by: Pareto Analysis, Root Cause Analysis
• Not to be confused with: a project plan, retrospective or uncontrolled trial

References

1. Institute for Healthcare Improvement. “Plan-Do-Study-Act (PDSA) Worksheet.” Official resource (opens in a new tab).
2. Institute for Healthcare Improvement. “Model for Improvement: Testing Changes.” Official guidance (opens in a new tab).
3. Deming, W. E. The New Economics for Industry, Government, Education. MIT Press, third edition, 2018.
4. International Organization for Standardization. “The Process Approach in ISO 9001:2015.” Official guidance PDF (opens in a new tab).
5. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, 2023. Official publication (opens in a new tab).

Sources reviewed 3 August 2026.