Operations Deliver

PDCA

PDCA is plan, do, check, act: the basic cycle of continuous improvement.

The questionWhat do we expect this change to do, and what did it actually do?

Also the Shewhart cycle, the Deming cycle or wheel, and PDSA (plan, do, study, act).

Process · Walter Shewhart, W. Edwards Deming, 1939 to 1950s

PlanState the change and predict the result.
DoRun it small, on a trial scale.
CheckCompare what happened with the prediction.
ActAdopt, adapt, or abandon, then plan again.

One pass of the loop. The Act step feeds the next Plan.

When to use it

A process problem has a plausible fix that nobody has tested, and a full rollout would be expensive to reverse.
A team has to show that an improvement is real before the standard procedure is rewritten.
Several improvement ideas are competing and you want to try them one at a time, small.
Improvements get declared finished at the end of a workshop and nobody can say later whether the result held.

When to avoid it

The cause is unknown and the real work is diagnosis. Find the cause first with something like Kepner-Tregoe. PDCA tests a fix, it does not find the cause.
The result of a change takes months to show or is buried in noise, so one cycle cannot tell you anything.
The fix is already known and mandated, such as a regulatory change or a safety recall. Implement it.
The question is about direction or organization design. A four-step loop is too small for it.

Overview

PDCA frames an improvement as a small experiment. You state a change and what you expect it to do, try it at limited scale, compare the result with the expectation, and then decide whether to adopt the change, adjust it, or drop it. It supports one choice: whether to roll a fix out now or test it first.

The check step is where teams cut corners, and where the value is. A check needs a baseline and a prediction written down before the trial, otherwise the review becomes a conversation about how everyone feels. Deming preferred the label plan, do, study, act for this reason. His point was that a trial should test your theory of the process, not only report pass or fail.

What it is not

A project plan with a loop drawn on it. If the Plan step has no prediction in it, the Check step has nothing to compare against.
Identical to PDSA. Deming held that Check suggests pass or fail, while Study means comparing results with a prediction and revising your theory. Many practitioners use the two names interchangeably, and the difference matters most when a result surprises you.
A single pass. The point is repeated small cycles, where the Act step produces the next Plan.

The steps

State the change and the prediction

Write one sentence on what you will change, one on what you expect to happen, and the measure and baseline you will use. Say how big the effect should be. A prediction that cannot be wrong cannot be checked.
Run it small

Pick a scale where a bad result is cheap, such as one shift, one line, or one team. Keep everything else as steady as you can, and note anything that changes during the trial.
Check against the prediction

Compare the result with the baseline and with what you predicted. Look at the gap between the two as well as the result itself. Record surprises, because a prediction that failed is information about how the process works.
Decide what to do with it

Adopt the change, adjust it, or drop it. If you adopt it, update the standard work and tell the people who run the process. If you adjust it, write the new prediction before the next trial.
Start the next cycle

Set the date and scope of the next trial while the team is still in the room. What comes out is a running list of tested changes, each with a result next to it.

In practice

Wrong-item picks run at about 1.8 percent of order lines in a distribution center, and the operations manager wants handheld scanners at every pick face. That is a large purchase. The team writes a prediction first: most errors come from mislabeled bin locations in the fast-moving zone, so relabeling the bins and adding a confirm-scan in that zone should cut that zone's error rate by at least half within two weeks. They run it on one shift, with the same zone in the prior month as the baseline.

The zone's error rate falls from 2.4 percent to 1.9 percent. That is well short of the prediction, which is useful: relabeling helped a little, so labels are not the main cause. The second cycle starts from a sample of the actual errors, which turn out to cluster among look-alike items shelved side by side. The scanner purchase is not rejected. It is deferred until it can be judged against a cause that has been measured.

What you leave with

A written prediction, with a measure and a baseline, for each change tried.
Results from a small trial, set beside the prediction.
A decision on each change, to adopt, adjust, or drop it, with the reason.
Updated standard work for any change that was adopted.
The scope and date of the next cycle.

Failure points

The check never happens

Teams feel the work is done once the change is running, so they skip from Do to Act. Checking needs a baseline collected in advance, and it risks showing that the change did nothing, so it loses out when time is short.

No prediction in the plan

Without a stated expectation, any result can be explained afterward. A modest improvement is called a win, and a flat result is blamed on the trial.

Cycles that are too big

A six-month change cannot be repeated quickly. By the time results arrive, demand, staff, and supplier behavior have all moved, and nobody can separate the change from the noise.

Adopted but not standardized

The change works on the trial shift, and then the other shifts continue with the old method. The gain fades because the standard was never updated and nobody trained the people who run the process.

Noise read as a result

A small process with a few dozen events a week will swing without any change. Teams claim a win from one good week. Run the trial long enough to see the usual range first.

The failures above are usually Leverage & IP: it was used once, and nothing was left that makes the next engagement easier.

Origin

Walter Shewhart, a statistician at Bell Telephone Laboratories, described quality control as a loop of specification, production, and inspection, and tied it to the scientific method of hypothesis, experiment, and test. His 1939 book Statistical Method from the Viewpoint of Quality Control sets this out. W. Edwards Deming took the idea to Japan, and by his own account the Japanese participants in his lectures of 1950 and 1951 shortened it to plan, do, check, act.

Deming later disowned the Check wording and taught plan, do, study, act, which he introduced in the United States in 1993. Both names are in use, along with Plan-Do-Check-Adjust. Nobody owns the term, and there is no trademark or licensing to worry about.

PDCA

When to use it

When to avoid it

Overview

What it is not

The steps

State the change and the prediction

Run it small

Check against the prediction

Decide what to do with it

Start the next cycle