PDCA Cycle

The PDCA Cycle - Plan, Do, Check, Act - is a four-step loop for improving a process by testing a change on a small scale, studying what happened, and then either standardising what worked or adjusting and going round again. It is one of the most widely used continuous-improvement tools in the world, partly because it is simple enough to explain in a sentence and flexible enough to fit almost any kind of work. This guide walks through each step, where the cycle came from, how to run it with your team, and when it is the right tool to reach for.

What is the PDCA Cycle?

The PDCA Cycle is a structured way to make a change without betting everything on it working first time. Instead of rolling out a new process across a whole organisation and hoping for the best, you plan a change, test it somewhere small, check the results against what you expected, and use what you learn to decide your next move. Each pass round the loop is a small, low-risk experiment.

The thinking behind it is the scientific method applied to everyday work. A scientist forms a hypothesis, runs an experiment, examines the data, and refines the hypothesis. PDCA does the same thing for a team process: you have a hunch about what might improve things, you try it carefully, you look honestly at what happened, and you adjust. The discipline is in not skipping the looking.

The cycle is also known as the Deming Cycle, the Deming Wheel, or the Shewhart Cycle, after the two people most associated with it - and there is a small but meaningful debate about what the third step should be called, which we will come to. It sits at the heart of continuous improvement and is closely tied to Kaizen and Lean ways of working. But you do not need to be running a factory to use it. PDCA works just as well for improving how a team handles requests, how a service responds to its users, or how a meeting actually runs.

Where the PDCA Cycle came from

The cycle has a longer and more tangled history than its four neat letters suggest, and getting it right matters because the people involved disagreed about what it was for.

The original idea belongs to Walter Shewhart, a physicist and statistician at Bell Labs in the 1920s and 30s. Shewhart was working on quality control in manufacturing and proposed a repeating three-step cycle - specify, produce, inspect - drawn straight from the scientific method. His insight was that quality was not a one-time inspection at the end but something you build through a continuous loop.

W. Edwards Deming, who had worked with Shewhart, carried these ideas to Japan in the 1950s, where he taught them to engineers rebuilding the country's industry after the war. Deming expanded Shewhart's cycle into a four-step pattern, and it took hold so thoroughly that it became known there as the Deming Cycle. In 1951 the Japanese Union of Scientists and Engineers (JUSE) reshaped Deming's version into the Plan-Do-Check-Act sequence most people recognise today.

There is one wrinkle worth knowing. Deming himself was never happy with the word "Check". He preferred Plan-Do-Study-Act, because "check" suggested simply confirming whether you hit the target, while "study" meant genuinely understanding why the result happened. It is a small change of word with a large change of meaning, and it is the difference between a team that ticks a box and a team that learns something. We will return to it, because it is the single most common way the cycle gets used badly.

How the PDCA Cycle works

The cycle has four steps, and they run in order. The diagram shows them as four blades of a wheel that turns - because the point is not to run the four steps once, but to keep turning, with each full turn leaving you a little further ahead than the last.

Plan

You spot a problem or an opportunity, get clear on what is actually going on, and design a small change to test. The work here is in the framing: what exactly are you trying to improve, what does success look like, and how will you know whether the change worked? A good plan decides upfront what evidence it is looking for, so the Check step later is not a matter of opinion.

This is also where you keep the scope small. PDCA works because each test is contained - one team, one process, one fortnight - so that if the change does not work, you have lost very little.

Do

You run the change. On a small, controlled scale, you put the plan into action and gather data as you go. The discipline in this step is restraint: you are running an experiment, not launching an initiative. Resist the urge to tweak things halfway through, because if you change three things at once you will not know which one made the difference.

Check

You study what happened. You compare the results against the goal you set in Plan, and - this is the part that earns its keep - you ask why they turned out the way they did. Did the change work? If it did, what was it about the change that helped? If it did not, what got in the way?

This is the step Deming wanted to call "Study", and the reason matters. A team treating this as a Check asks "did we hit the number, yes or no?" and moves on. A team treating it as a Study asks "what did this teach us?" - and that question is where continuous improvement actually lives. The number tells you whether to keep the change. The understanding tells you how to make the next change better.

Act

You decide what to do with what you learned. This step has a fork in it, and the fork is the heart of the whole cycle:

• If the change worked, you standardise it. You make the new way the normal way - update the process, train people, lock the gain in so it holds and does not quietly slide back to the old habit.
• If it did not work, you adjust. You take what you learned, revise the plan, and turn the wheel again with a better experiment.

Either way, the cycle does not stop. A standardised win becomes the new baseline for the next round of improvement; a failed test becomes the starting point for a better one. This is why PDCA is drawn as a wheel rather than a line - and why each turn should leave you higher than the last, building on the previous round rather than circling back to where you started.

How to use the PDCA Cycle with your team

Running PDCA well is less about the four steps and more about the habits around them. Here is how to put it into practice.

Start with a problem worth solving, framed clearly. Vague problems produce vague experiments. "Our handovers are messy" is not yet something you can test. "Work is getting dropped when it moves between the design and build teams, roughly twice a week" is. The sharper the problem, the easier everything downstream becomes. A tool like the 5 Whys can help you get past the symptom to something you can actually act on.

Decide your measure before you start. In the Plan step, agree what evidence will tell you whether the change worked - and write it down. This sounds obvious, but teams skip it constantly, and the result is a Check step that turns into an argument about whether things "feel" better. Pick something you can observe.

Keep the test small and contained. The whole advantage of PDCA is that a failed experiment is cheap. Run the change with one team, on one process, for a set period. You are looking for signal, not a full rollout. If it works, you scale it in the Act step - not before.

Treat Check as learning, not judgement. This is where most cycles fall down. Build in a real conversation about what happened and why, not a quick pass-or-fail. The question that unlocks the value is not "did it work?" but "what did we learn?". If the answer to the second question is nothing, you ran the experiment too loosely.

Close the loop, then open it again. When something works, standardise it properly - the gain only holds if the new way actually becomes the way you work. Then start the next turn. The organisations that get the most from PDCA are the ones that treat it as a rhythm rather than a one-off project. That rhythm is what we mean by momentum through work - improvement built into how a team operates, not bolted on as a separate initiative.

An example of the PDCA Cycle in practice

Imagine a customer-support team that is missing its response-time targets. Tickets are sitting unanswered for too long, and the team is frustrated because they feel busy all day.

Plan. Rather than guessing, they look at the data and notice that a large share of tickets arrive in the first hour of the morning and pile up before anyone has worked through the overnight backlog. Their hypothesis: if two people start an hour earlier and clear the overnight queue before the morning rush, response times across the whole day will improve. Their measure: average first-response time, tracked over two weeks. That is the plan, and it is small and specific.

Do. Two team members shift their start time earlier for the two-week test. The rest of the team carries on as normal, so the only thing that has changed is the early-morning coverage. They log response times throughout.

Check. At the end of the fortnight they study the numbers. Average first-response time has dropped noticeably - but when they look closer, almost all the improvement is in the morning, and afternoon response times are unchanged. The early start cleared the backlog, but it did not touch a second pile-up that builds after lunch. The number says the change helped; the study says it only solved half the problem.

Act. The morning change worked, so they standardise it - it becomes the team's normal pattern. But the cycle does not end there. The afternoon pile-up they spotted in the Check step becomes the problem for the next turn of the wheel. They have a measurable win locked in, and a sharper question to start the next round with. That is PDCA doing its job: one turn higher than where they started, and pointed at the next improvement.

Limitations of the PDCA Cycle

PDCA is genuinely useful, but it is not the right tool for everything, and it is worth being clear about where it runs out.

It is built for incremental improvement, not radical change. PDCA refines what already exists. If a process is fundamentally broken and needs redesigning from scratch, running small tests on it is like adjusting the deckchairs - you may want a tool aimed at rethinking the whole thing, such as Process Mapping to see the system before you decide what to change.

It needs patience and repetition to pay off. A single turn of the wheel rarely transforms anything. The value compounds over many cycles, which means PDCA asks for sustained commitment - and that commitment usually has to come from leadership, not just the team running the experiments. Organisations that try it once and move on tend to conclude it does not work, when really they just stopped turning the wheel.

It depends entirely on an honest Check. The cycle is only as good as the learning step, and the learning step is the easiest one to rush. A team under pressure will quietly skip the study, declare victory, and standardise a change that did not actually help. When that happens, PDCA stops being improvement and becomes a ritual.

For complex, high-stakes change, a heavier method may fit better. Where a problem needs deep statistical rigour and formal control - the kind of high-variation, high-cost process where getting it wrong is expensive - a more structured cousin like DMAIC gives you more discipline at each stage. PDCA is the nimble, everyday loop; DMAIC is the heavyweight project method. Knowing which one you need is half the skill.

Getting started with the PDCA Cycle

The simplest way to try PDCA is to pick one small, irritating problem your team keeps running into - not the biggest one, just one that is well-defined and low-risk - and run a single turn of the wheel on it this week.

Write down the problem in one specific sentence. Decide the one change you want to test and the one measure that will tell you whether it worked. Run it small, for a fixed window. Then, before you do anything else, sit down as a team and study what happened - not just whether the number moved, but why. That conversation is the habit worth building, and once a team has had it a few times, the rest of the cycle tends to look after itself.

If you find that the same problems keep coming back round despite your best efforts, that is often a sign that the learning loop is not closing - the work we do in operating model and process design frequently starts exactly there, helping teams turn one-off fixes into a rhythm of improvement that actually holds.