PDCA Model: Plan, Do, Check, Act
PDCA helps you test a process or product change by planning it, doing it (often small), checking the outcome against what you expected, and then acting: standardize what worked or adjust and run the next cycle.
Framework Card
- Name:
- PDCA Model
- Goal:
- Test a process or product change through a repeating cycle of Plan, Do, Check, and Act so the next cycle is based on evidence, not on an untested push.
- Flow:
- Plan → Do → Check → Act
- Best For:
- Repeating process improvement; Small tests of a change before standardizing; Recurring operational problems you can try again
Why it matters
In a lot of teams, "doing" beats "checking." An idea goes straight to production. A training is delivered once. A fix is merged. The next fire looks familiar.
Two failure modes show up again and again. One is starting without a plan for what "better" would look like. The other is finishing the work and never comparing actual results with the plan, so the same miss repeats.
That matters when the work is repeating: a queue, a handoff, a defect class, a feature you can flag. If you cannot try again, PDCA has little to grip. If you can try again and you skip Check, you only have motion.
PDCA is a cycle for that situation. It is a way to make the next pass cheaper than the last one. It is not a quality department in a box.
What it is
PDCA stands for Plan, Do, Check, Act. It is an iterative method for controlling and improving a process or a product by running a change as a test, not as a one-shot campaign.
| Stage | Focus | Question |
|---|---|---|
| Plan | Change design | What problem or opportunity, what will we try, and how will we know? |
| Do | Trial | Can we carry out that plan, often on a limited scale? |
| Check | Evidence | Did actual results match what Plan expected, and if not, why? |
| Act | Standard or next cycle | Do we standardize this, or adjust and loop? |
The cycle is associated with statistician Walter Shewhart in the 1920s and with W. Edwards Deming's later teaching. It is often called the Deming Cycle. Those names are history, not a guarantee. PDCA is a cycle you can run. It is not, by itself, ISO, Total Quality Management, or Six Sigma.
How it works
A useful PDCA is a test with a memory, not four posters on a wall.
1. Plan
Name the problem or the opportunity. Gather what you already know. Set an objective in units you can check. Write the change you will try, and write how you will Check: which signal, which sample, which time window. If Plan has no expected signal, Check cannot be honest.
2. Do
Carry out that planned change. Prefer a limited scale when the risk is high: one team, one queue, one flag. Do is not "review last quarter." Do is implementation of the plan you just wrote.
3. Check
Compare actual outcomes with the expected results from Plan. Collect the signal you named. If the change failed, ask why before you invent a larger change. Skipping Check turns the cycle into guesswork.
4. Act
If the outcome met the plan, standardize the successful process (write it down, train it, make it the default). If it did not, adjust the plan or the method and start the next cycle. Production teaching sometimes uses Keep / Improve / Stop / Start language inside Act. That can close one cycle. It does not turn PDCA into KISS Review.
PDCA is meant to repeat. A later cycle can sit inside a larger one (a team test inside a company-wide change). Nested cycles are scale, not extra letters.
How it compares
When another loop fits better, these methods do different jobs. They are not interchangeable labels for "improve something."
Related review and improvement loops
| Framework | What it helps you see | How it differs from PDCA |
|---|---|---|
| OODA Loop | Observe, Orient, Decide, Act when information is moving and delay is costly | Tempo under uncertainty. PDCA is a planned process test with an expected check. |
| DMAIC | Define, Measure, Analyze, Improve, Control | Heavier measurement and control path (often Six Sigma). PDCA is a lighter cycle and not that program. There is no MyFramework page for DMAIC yet. |
| 3R Review Framework | Record, Reflect, Refine after a piece of work | Personal, rapid, after the work. PDCA includes Plan and Do as a test. |
| GRAI Review Framework | Goal, Result, Analysis, Insight against a baseline | Reviews a result that already exists. PDCA runs the next experiment. |
PDCA is the lens when the question is: what change will we try, how will we know, and do we standardize or loop? Other methods help when the job is speed under uncertainty, a measurement-heavy program, a personal journal, or a Goal-Result review.
When to Use This Framework
- Repeating workflows: A queue, a handoff, or a checklist that runs every week, where a small change can be tried without betting the whole operation.
- Product or feature trials: You want to ship a change behind a flag or to a subset, then look at use and complaints before you standardize.
- Recurring defects: The same class of error returns. You need to isolate a fix, try it, and see whether the class actually drops.
- Personal skill loops (secondary): A practice plan with a check (a score, a recording, a review), not a vague "I will try harder."
Example
A concrete example makes the structure easier to reuse when you are under uncertainty.
Example: Ticket first-response on a support queue
A support manager's queue keeps missing a same-day first-response goal on billing tickets. The old habit was a new training deck every quarter, with no check.
Plan: The problem is first-response on billing tickets after 16:00. The change to try: a two-person late-shift pairing for billing only, for two weeks. Expected check: share of billing tickets with a same-day first response, compared with the prior two weeks. Out of scope: CSAT as the only signal.
Do: Run the pairing on weekdays for ten working days. Do not rewrite the whole handbook yet.
Check: Same-day first response on billing tickets rose from 61% to 79%. Chat tickets unrelated to billing did not move. Two days of data were missing because of a reporting bug; those days are labeled assumed, not invented.
Act: Standardize the late-shift pairing for billing. Do not roll the same pairing to every queue yet. Next cycle: fix the reporting bug so Check is complete, then decide whether to extend hours.
The cycle did not "transform customer service." It tested one change against a named signal.
Example: A feature behind a flag
A product team has a long-requested export. Shipping it to everyone would touch billing and audit logs.
Plan: Objective is "weekly active accounts that complete one export," not "ship the feature." Change: enable export for 10% of accounts on the current plan, with a kill switch. Check: completion rate, support tickets tagged export, and one audit-error count, after fourteen days.
Do: Ship behind the flag to the 10% sample.
Check: Completion is real among accounts that open the menu. Support tickets show a confusing date-range control. Audit errors stay flat.
Act: Do not standardize the current UI. Keep the flag. Next Plan: rewrite the date-range control, then Check completion and tickets again. The first cycle succeeded as a test even though the product is not "done."
Takeaway
What PDCA can help with
- Turning a repeating problem into a planned test with a named check
- Comparing actual results with expected results before you scale a change
- Standardizing what worked, or adjusting without pretending the first try was the program
- Nesting a small cycle inside a larger change when scale requires it
What PDCA cannot replace
- A full quality management system: ISO, TQM, or a Six Sigma program is more than this cycle. PDCA can sit inside those programs. It is not those programs.
- DMAIC: Define, Measure, Analyze, Improve, Control is a heavier, often statistical path. Use it when the job is measurement design and control of an existing process at that depth. PDCA is a lighter cycle.
- OODA: Observe, Orient, Decide, Act is for speed when the environment is moving. PDCA is a planned process test, not a competitive tempo loop.
- 3R Review: Record, Reflect, Refine is a personal rapid look at work already done. PDCA includes planning and doing a change.
- GRAI Review: Goal, Result, Analysis, Insight reviews a result that already exists. PDCA is the experiment you run next.
Honest scope: PDCA structures a test. It does not certify a quality system, and it should not be sold as mastery of continuous improvement.
Frequently asked questions
Plan, Do, Check, and Act. Plan designs the change and the check. Do carries it out. Check compares actual with expected. Act standardizes or adjusts and feeds the next cycle.
No. PDCA is a cycle you can run on a process or a product. Quality programs (ISO, TQM, Six Sigma) may use PDCA. They also include policy, measurement systems, and governance that PDCA alone does not provide.
OODA is Observe, Orient, Decide, Act. It is built for tempo when the environment is moving. PDCA is Plan, Do, Check, Act. It is built for a planned test of a process change. Both have an "Act." They answer different questions.
3R records what already happened, reflects on why, and refines the method. It is a personal rapid loop. PDCA plans a change, does it, and checks it. If you only need a note after a task, 3R is closer. If you need a test you can standardize, PDCA is closer.
A Plan with an objective and a named check, a Do that matches that plan, a Check that compares actual with expected (including what you do not know), and an Act that either standardizes or states the next cycle. If the output is only "we improved," you skipped Check.