The PDCA cycle — Plan, Do, Check, Act — is the simplest structured framework for continuous improvement. First described by Walter Shewhart and popularized by W. Edwards Deming in post-war Japan, it underlies most modern quality management systems: Lean, Six Sigma, ISO 9001, and Toyota’s kaizen approach. This guide explains each phase, shows how PDCA connects to root cause analysis tools like 5 Whys and fishbone diagrams, and walks through three real-world examples.
What Is the PDCA Cycle?
PDCA is a four-phase iterative loop. Each cycle produces an improvement or a learning that feeds the next cycle. The output of every Act phase becomes the new baseline for the next Plan phase — which is why teams that run PDCA continuously outperform those that run it once.
Plan
Define the problem. Identify root causes using 5 Whys, fishbone, or Pareto. Set a measurable improvement goal. Design a solution.
Do
Implement the solution — but on a small scale. A pilot limits risk and gives you clean data to evaluate before a full rollout.
Check
Compare actual results to your goal. Did the solution work? By how much? What unexpected effects appeared?
Act
If the improvement worked — standardize it. Update procedures, train the team, document the change. If not — return to Plan with new learnings.
The cycle then repeats. Each iteration either improves the process or adds knowledge that makes the next attempt smarter. This is why PDCA is called a cycle, not a project.
PDCA and Root Cause Analysis
The most critical part of the PDCA cycle is the Plan phase — specifically the root cause analysis step. Many PDCA cycles fail not in the Do phase, but in the Plan phase, because the team skips proper RCA and jumps straight to a solution. If the root cause is wrong, the solution won’t stick and the problem will recur.
The standard RCA tools slot directly into the Plan phase: use a Pareto chart to identify which problem category to tackle first, then use a 5 Whys or fishbone diagram to find the root cause of that top category.
How to Run a PDCA Cycle (Step by Step)
- Define the problem clearly — use data, not opinions. State what is wrong, where, and since when.
- Set a measurable goal — “reduce defect rate from 8% to under 2% within 60 days.” Without a measurable goal, the Check phase has nothing to evaluate against.
- Analyze root causes — use 5 Whys, a fishbone diagram, or a Pareto chart. Don’t skip this step. A solution without root cause analysis is just guessing.
- Design the solution — based on the root cause, not the symptom. Document what you will change, who is responsible, and how you will measure it.
- Run a small-scale pilot (Do) — test in one team, one line, one location. Limit scope to limit risk.
- Measure and compare (Check) — collect data during and after the pilot. Compare to your baseline and your goal. Note unexpected results.
- Standardize or restart (Act) — if the improvement worked, update procedures and roll out broadly. If not, return to step 1 with what you learned.
PDCA Cycle Examples
Manufacturing: Reducing Assembly Defects
Software: Reducing Login Failures
Healthcare: Reducing Medication Errors
PDCA vs. Other Improvement Frameworks
| Framework | Best For | Relationship to PDCA |
|---|---|---|
| PDCA | Iterative operational improvements, daily kaizen | Baseline framework |
| DMAIC (Six Sigma) | Complex, data-heavy process improvements | Uses PDCA within the Improve phase for solution testing |
| A3 Problem Solving | Structured single-problem deep dives | An A3 report documents one full PDCA cycle |
| 8D Report | Customer complaint resolution | D1–D3 = Plan, D4–D5 = Do, D6 = Check, D7–D8 = Act |
| Kaizen events | Rapid team-based improvements | A compressed PDCA cycle (1–5 days) |
Common PDCA Mistakes
- Skipping root cause analysis in the Plan phase — the most common mistake. Jumping to solutions before understanding causes leads to recurring problems.
- Making the Do phase a full rollout — the Do phase should always be a pilot. A full rollout before checking results removes your ability to compare and learn.
- No measurable goal — without a defined target, the Check phase becomes subjective (“it feels better”) instead of data-driven.
- Stopping after one cycle — PDCA is designed to repeat. After each Act phase, the next cycle starts with a higher baseline. Teams that stop after one cycle leave improvement on the table.
Run Your Next PDCA with Free RCA Tools
Start the Plan phase with our free 5 Whys, Fishbone, and Pareto tools — no signup, no downloads.
See All Free Tools →Related resources
- Root Cause Analysis Guide: A Complete Introduction — the fundamentals of RCA before running PDCA
- 5 Whys Examples: 10 Real-World Case Studies — how to use 5 Whys in the Plan phase
- Fishbone Diagram Examples: 7 Real Case Studies — map all possible causes before picking one
- Pareto Analysis: Complete Guide with Examples — identify which problem to tackle first
- RCA Tools Compared: 5 Whys, Fishbone, Pareto & More — choose the right tool for each PDCA cycle
- Free 5 Whys Tool — guided root cause analysis for the Plan phase
- Free Pareto Chart Maker — prioritize which problem to run PDCA on first
Frequently asked questions
What is the PDCA cycle?
The PDCA cycle (Plan-Do-Check-Act) is a four-phase iterative model for continuous improvement. Developed by Walter Shewhart and popularized by W. Edwards Deming, it provides a structured approach: Plan (identify the problem and design a solution), Do (implement on a small scale), Check (measure results), Act (standardize if successful or restart). Also called the Deming Cycle or PDSA cycle.
What are the 4 stages of the PDCA cycle?
(1) Plan — define the problem, analyze root causes, set measurable goals, design a solution. (2) Do — implement on a small scale or pilot. (3) Check — compare actual results to expected, identify gaps. (4) Act — if the improvement worked, standardize it; if not, return to Plan with new information.
What is the difference between PDCA and PDSA?
PDCA and PDSA (Plan-Do-Study-Act) are essentially the same model. Deming later preferred “Study” over “Check” because Study implies deeper analysis and learning, not just verifying compliance. In practice both terms are used interchangeably. PDCA is more common in manufacturing and Lean; PDSA appears more often in healthcare improvement frameworks like IHI.
How does the 5 Whys fit into the PDCA cycle?
The 5 Whys is used in the Plan phase for root cause analysis before designing a solution. Without proper RCA in the Plan phase, teams treat symptoms instead of causes — leading to recurring problems. Running 5 Whys inside PDCA ensures the solution addresses the real root cause, not just the visible symptom.
What is a PDCA cycle example?
Manufacturing example: Plan — Pareto chart shows 67% of defects are solder bridging; 5 Whys finds root cause is wrong temperature in morning shift. Do — pilot temperature check log on one line for 4 weeks. Check — defect rate drops from 8.2% to 1.4%. Act — roll out to all lines, update SOP.
What is the difference between PDCA and Six Sigma DMAIC?
PDCA is simpler and faster for iterative incremental improvements in daily operations. DMAIC (Define-Measure-Analyze-Improve-Control) is more rigorous and data-intensive for complex problems requiring statistical analysis. Many Six Sigma projects use PDCA cycles within the Improve phase for rapid solution testing.
How long should a PDCA cycle take?
Anywhere from one day (a simple process tweak) to several months (a complex operational improvement). The key principle is that the Do phase should be a small-scale pilot — not a full rollout — to limit the cost of failure. Lean teams often run weekly PDCA cycles for operational improvements; quality improvement projects in healthcare or manufacturing typically run 4–12 week cycles.