Using PDCA (Plan-Do-Check-Act) to Solve Problems That Stay Solved

The PDCA cycle — Plan, Do, Check, Act — is a four-stage loop for making improvements that hold. You plan a change based on evidence, do it on a small scale, check whether it actually worked, and then act to standardise it if it did or to try again if it did not. The power of PDCA, as I have watched it work on the shop floor, is that it treats every change as an experiment rather than a decree, so you learn quickly and cheaply before committing. Problems stay solved because the loop insists on verification and standardisation rather than stopping at a hopeful fix.

This article explains each stage of the PDCA cycle, how to run it on a real operational problem, and why the loop is more reliable than the one-shot fixes most teams default to.

Why one-shot fixes fail

The usual pattern for solving a problem is a single leap: someone decides on a change, rolls it out everywhere, and moves on. Sometimes it works. Often it does not, and because it was never tested small, the failure is expensive and hard to unpick. Worse, nobody checks whether it worked, so a change that quietly made things worse can persist for months. As an auditor I have found plenty of those — corrective actions signed off long ago that nobody ever confirmed.

PDCA replaces the leap with a loop. Each turn of the loop is deliberately small and reversible, which means mistakes are cheap and lessons are fast. Over time the cycles compound: each one leaves the process a little better and a little better understood.

The four stages

Plan

Start with a clear problem and its likely cause — this is where root cause analysis earns its keep. Then design a specific change and, crucially, predict what you expect to happen. A plan without a prediction cannot be checked. Decide in advance what you will measure and what result would count as success. Keep the scope small: one cell, one shift, one product line.

Do

Carry out the change on the agreed small scale. Follow the plan, and record what actually happens — including the awkward details and anything that did not go as intended. I always tell teams that the awkward details are the honest ones, and they are usually where the learning is. The "do" stage is a trial, not a launch, so resist the urge to expand it before you have the evidence.

Check

Compare what happened with what you predicted. Did the measure move in the direction and by the amount you expected? Look honestly at the data and at the side effects. This stage is where discipline matters most, because it is tempting to declare success from enthusiasm rather than evidence — and enthusiasm is exactly the thing an auditor learns to distrust. If the result is unclear, that is itself useful information about how well you understood the problem.

Act

Now decide. If the change worked, act to standardise it: update the procedure, train the team, make the new way the default. If it did not, act to adjust — refine the plan and run the loop again with what you have learned. Either way, the cycle turns again, because standardising one improvement usually reveals the next problem worth attacking.

Running PDCA on a real problem

Say a line suffers frequent short stoppages that nobody has pinned down. A single PDCA turn might look like this:

1. Plan — evidence suggests a particular changeover step causes most stoppages. Predict that a revised changeover sequence will cut stoppages on that line over a two-week trial, and decide to measure stoppage frequency.
2. Do — run the revised sequence on one line for two weeks, logging every stoppage and any new snags.
3. Check — compare the stoppage log against the previous fortnight and against the prediction. Did they fall as expected, and did anything else get worse?
4. Act — if stoppages fell and nothing broke, write the new sequence into the standard and roll it to the other lines; if not, revisit the plan and try again.

The numbers here are illustrative, but the rhythm is the point: a small, measured, reversible test rather than a factory-wide gamble.

Why PDCA makes fixes stick

• It demands a prediction, so you cannot quietly move the goalposts after the fact.
• It tests small, so failures are cheap and reversible.
• It checks with evidence, so you know whether the change truly helped.
• It standardises deliberately, turning a successful trial into information the whole team follows.
• It never really stops, so improvement becomes a habit rather than a project.

That last point matters most. A team that runs PDCA continuously does not lurch from crisis to crisis; it grinds steadily forward, converting each problem into a slightly better and better-understood process. The teams I trust most are not the ones with the tidiest paperwork — they are the ones who genuinely believe the Check stage, and act on what it tells them.

Frequently asked questions

How is PDCA different from just trying something and seeing if it works?

The difference is prediction and verification. PDCA asks you to state what you expect before you act, then check the result against that prediction with evidence. "Trying something" skips both, so you rarely learn whether the change worked or why, and improvements do not accumulate.

How small should a PDCA trial be?

Small enough to be reversible and quick to learn from, but large enough to give a meaningful result — often a single cell, line or shift. Starting small keeps the cost of being wrong low, which is the whole point. You can always scale up in the Act stage once the evidence supports it.

How does PDCA relate to root cause analysis?

They fit together. Root cause analysis tells you what to change; PDCA is how you test and embed that change safely. A strong Plan stage usually rests on a solid root cause analysis, and a weak one is often the reason a PDCA loop fails to move the numbers.

Where to go next

PDCA turns problem solving from a one-off event into a continuous capability that compounds over time. If you would like a structured way to score your operation and identify the improvement loops worth running first, ProgressXL is coming soon. To talk through a problem that keeps returning despite your best fixes, get in touch.