The PDCA Cycle Explained: Plan, Do, Check, Act in Practice

Plenty of teams say they use the PDCA cycle; in published projects, far fewer run all of it. The PDCA cycleplan-do-study-act: A four-step loop for testing a change: plan it with a written prediction, try it on a small scale, study what happened against the prediction, then act by adopting, adapting or dropping it. It comes from the quality methods of Walter Shewhart and W. Edwards Deming.Full entry in the glossary, short for plan, do, check, act, is a four-step loop for testing a change to a process: plan the change, test it small, check what happened, then act on what you learned by building the change in more widely or going round again with a different plan.¹ Only 3 of 72 health-care improvement projects that documented their cycles followed all four core features of the method, according to a 2019 systematic reviewsystematic review: A review that fixes its question and its rules for including studies in advance, then searches out every study that fits and weighs them together. Some systematic reviews pool the results into a meta-analysis; others describe what the studies found without combining the numbers.Full entry in the glossary by Danish researchers.²

Four stages, each with one job

The PDCA cycle is a way of finding out whether a change to a process works before you commit to it. ASQ, the American Society for Quality, calls it a four-step model for carrying out change and says it should be repeated again and again for continuous improvement, the way a circle has no end.¹

It works because it borrows the logic of a laboratory experiment and scales it down to ordinary work. In a 2016 BMJ Quality & Safety article, Julie Reed and Alan Card point out that the four stages mirror an experiment: form a hypothesis, collect data to test it, interpret the results, then refine the hypothesis.³ A hunch such as “suppliers forget the order number” becomes a claim you can test and be wrong about.

Each stage has one job. The Institute for Healthcare Improvement (IHI) spells them out. Plan: state the objective, the questions the test should answer and your predictions, and decide who does what, when, where, and which data to collect. Do: carry out the test and write down problems and surprises. Study, the IHI’s word for check: compare the data with the predictions and summarize what you learned. Act: refine the change and plan the next test.⁴

DMAIC (define, measure, analyze, improve, control), the data-driven cycle at the core of Six Sigma projects, is a five-phase relative.⁵ PDCA can be much lighter: a team can plan a small cycle at one weekly meeting and review it at the next. It is also the loop underneath many of the methods covered in our guide to process improvement and where to start.

A quick test of whether you are running the cycle: before anything changes, can you point to a written prediction and the one measure that will check it? If not, you are still planning.

Cutting invoice errors: the four stages on one office problem

The clearest way to learn the PDCA cycle is to follow one small problem through all four stages. The example below, invoices sent back for correction, is illustrative rather than a real case, built on an office task most organizations share.

Plan: count the errors and write a prediction

A finance team that pays supplier invoices notices that many bounce back from approval. Before changing anything, it logs every returned invoice for a month and sorts them by reason. The largest group is a missing purchase-order number; the next is a wrong tax code, whether that is VAT, GST or sales tax where the team works. If the reason is not obvious, a short root cause analysis of why the error keeps happening belongs here. The team picks one change: send five regular suppliers a one-page note showing where the order number goes. It writes a prediction: “Invoices from these five suppliers returned for a missing order number will fall to almost none within three weeks, with no rise in other errors.” The measure is returns per week from those suppliers, by reason.

Do: run the test and log surprises

The note goes out, and one person keeps the log. The log also catches the unexpected: one supplier’s accounting software has no field for an order number, so it starts putting the number in the email subject line.

Check: put the results beside the prediction

After three weeks the team puts the weekly counts side by side with the prediction. Four suppliers now send clean invoices; the fifth still fails the check, although the number is sitting in the subject line. The prediction was partly right, and the miss teaches something: the fix depends on each supplier’s systems, not only on the note.

Act: adopt, adapt and standardize

The team adopts the note, adapts the intake step so a clerk copies the number from the subject line, and plans a second cycle with more suppliers. Once the change holds, write the new routine into a standard operating procedure so it outlasts the people who designed it.

Nothing in that month was large or expensive. The value came from writing the prediction first, which turned one supplier’s failure from an annoyance into the most useful finding of the cycle.

Where the PDCA cycle came from: Shewhart, Deming and Japan

The PDCA cycle began with Walter Shewhart’s work on quality control in the US, was reworked by W. Edwards Deming in lectures in Japan in 1950, and was recast as plan, do, check, act by Japanese executives afterwards, according to a 2010 history by Ronald Moen and Clifford Norman.⁶

Shewhart’s 1939 book described quality control as three steps, specification, production and inspection. He first drew them as a straight line, then argued they must go in a circle, corresponding to a hypothesis, an experiment and a test of the hypothesis. In a line, inspection ends the job; in a circle, what it finds feeds the next round. Deming, who had edited the lectures behind that book, presented his own version at an eight-day seminar in Japan sponsored by the Union of Japanese Scientists and Engineers: a wheel of design, production, sales and research, turned continuously.⁶

The four familiar words came next. Masaaki Imai, in his 1986 book on kaizen, reported that Japanese executives recast Deming’s wheel as plan, do, check, act; nobody has claimed the revision. Kaoru Ishikawa later widened the plan step to include setting goals and methods, and added training to the do step.⁶ Moen and Norman write as insiders: Moen worked alongside Deming for more than a decade, and both are partners in an improvement consultancy.

1. 1939Shewhart: specification, production, inspection
2. 1950Deming wheel taught in Japan
3. 1951Japanese plan-do-check-act
4. 1985Ishikawa widens the plan step
5. 1993Deming publishes plan-do-study-act

The cycle kept other names along the way. Wikipedia’s entry lists the Shewhart cycle, the Deming cycle, the control circle and plan-do-check-adjust, which is why the same loop can turn up under four labels in one company.⁷

From Shewhart onward, the loop was meant to go round more than once. Whatever your colleagues call it, agree on one name and one worksheet, and judge a project by whether it reached a second cycle.

Plan-do-study-act: why Deming rejected “check”

W. Edwards Deming never fully accepted PDCA as his method. In his seminars of the 1980s he warned that the English word “check” means “to hold back”, and by 1993 he was teaching the loop as plan-do-study-act (PDSA), which he called the Shewhart cycle for learning and improvement.⁶

Be sure to call it PDSA, not the corruption PDCA.

The difference is more than a word. The W. Edwards Deming Institute explains that check, in the PDCA version, asks whether a plan succeeded or failed and then corrects the plan if it failed. Study asks the team to predict the result, examine what happened and compare the two, so that the theory behind the change can be revised.⁸ A check tells you the invoice fix worked for four suppliers; a study tells you why it failed for the fifth.

Whether the label changes behaviour is an open question. One review of published health-care projects noticed that those calling the method PDSA more often ran linked cycles than those calling it PDCA, and its authors suggested Deming’s distinction might help explain it; the comparison was small and observational.⁹

Keep whichever name your organization uses, and run the study version: compare the result with a prediction you wrote down before you started.

How to run small, fast cycles with a prediction and a measure

Small, fast cycles keep the cost of being wrong low. The IHI advises scaling tests down, for instance sampling the next 10 cases rather than 200, running a test in one place for one week, and asking what change could be tested by next Tuesday.⁴

The same guidance gives the rest of the recipe. Test with willing volunteers, since agreement is needed to implement a change but not to test one. Keep the data simple: record measurements and sketch trends with paper and pencil rather than wait for software. Plan a couple of cycles ahead, imagining what you would try next under each possible result. And be prepared to stop a test that is not helping; the IHI treats failed tests as a normal part of improvement.⁴

1. Small test: one change with five suppliers for three weeks, with a written prediction
2. Adapted test: the change revised from what cycle 1 showed, tried with more suppliers
3. Wider use: every supplier, then written into the team’s procedure and kept under watch

The measure matters as much as the size. Record it at regular intervals, in time order, rather than once before and once after. Measuring over time shows how much a process varies on its own, so one good week is not taken for a lasting gain; Taylor and colleagues list data over time among the core features of the method.⁹

Four ways teams break the PDCA cycle

Four PDCA mistakes recur: running one cycle and treating it as finished, never writing a prediction, testing too big, and skipping or rushing the check. A 2014 systematic review of how health-care teams applied the method, led by Michael Taylor at Imperial College London in the UK, found the first three widespread in the published record.⁹

The study

Moderate evidence

Did published teams run the cycle as designed? A 2014 review of 73 published articles

The reviewers checked 73 peer-reviewed articles on health-care projects, mostly from the US and UK, against five features of the method: linked cycles, a prediction, small-scale testing, data over time and documentation. Only 2 of the 73 met all five, and only 4 of the 47 studies with enough detail stated an explicit prediction. The review assessed how the method was used, not whether projects improved care.⁹

The finding matters because each missing feature removes a way to learn. With no prediction on paper, a team can call almost any result a win; without linked cycles, the lesson of one test never shapes the next.

Reed and Card explain where the fourth mistake comes from. In a culture of “just get on with it”, teams hurry from plan to do, get stuck doing, and sometimes jump from do straight to act without studying the result. They also warn against settling for weak changes, such as more training or a new policy, without considering stronger options, and stress that a well-run cycle promises learning, not the outcome a team hopes for.³

Myth

PDCA is a four-phase project plan you complete once.

Fact

It is a repeated test. Each act step plans the next cycle, and most changes need several linked cycles before they are ready to spread.

Small-scale testing is often missing as well: the 2019 Danish review found it in only about one project in seven.² Evidence that the method itself improves results remains thin, and Taylor’s team, citing earlier reviews, describe the evidence base for improvement methods of this kind as poor.⁹

The practical defence is to fix the check before the change starts. In the meeting where you agree the test, book the date you will compare results with the prediction and name who will plan the second cycle.

A one-page PDCA worksheet you can copy

A PDCA worksheet is one page that holds a single cycle: the aim, the prediction, what happened and the decision. The prompts below follow the IHI’s four steps, with an aim row taken from the first two questions of the Model for Improvement; copy them into a document or onto a whiteboard, and start a fresh page for each cycle.

Keep the finished sheets together. Taylor’s team notes that documenting each stage supports local learning and keeps knowledge in the organization, and a stack of sheets shows a new team member why the process looks the way it does.⁹

The bottom line

The PDCA cycle gets its value from the parts teams skip: a prediction written before the change, a measure recorded over time, and a next cycle planned from what the last one taught. Start with one recurring error, a handful of cases and a week, and write down what a failed prediction taught you before planning the next cycle.