Quality in Practice — Lesson 4: PDCA: The Most Underrated Improvement Cycle

Quality in Practice · 4 min read · 29.09.2026

The fourth lesson in the Quality in Practice series. In the previous lessons, you covered where quality is created, how to find the true cause of a problem, and how to run a complaint as a project. Today: the PDCA cycle. Everyone knows it; very few carry it through to the end. We'll show why improvements vanish after a few months, how to write one as a hypothesis, and how to turn it into a standard that survives a change of operator.

Why Improvements Disappear Three Months After Rollout

In manufacturing companies, we keep seeing the same pattern. A team designs a solution, approves the budget, and starts implementing. Three months later, it's all over. The shop floor looks the same as before; all that's left is the invoice.

The problem usually isn't a lack of ideas. Companies complete only half the cycle — P (plan) and D (do) — and call it "done." They skip C, verifying that the solution really works, and A, writing it into standards, instructions, and training. Without them, every improvement is just an experiment nobody saw through.

An example from our projects: an engineering company with 140 employees was struggling with burrs after drilling. It bought new clamping fixtures for EUR 18,000. Six months later, defects were still at the same level. Nobody measured before the purchase or after launch. The money went toward an assumption, not a verified cause.

An improvement without measured data is just an opinion with a budget.

Plan: Measure Before You Change Anything

The Plan phase doesn't start with a solution, but with defining the problem in numbers. Without a baseline, you can't even prove that you've moved forward.

So in the burr case, we started with measurement. For two weeks, the operator logged every part with burrs. The result: 4.1% defects at the drilling machine. The existing estimate was "around 2%." Reality was double that — nobody had ever counted it.

A well-written plan takes the form of a hypothesis: If we change X, Y will improve by Z by a set deadline. For example: "If we shorten the drill bit replacement interval from 2,000 to 1,200 drilled parts, the defect rate will fall below 2%." This format forces you to define what you measure, by how much, and by when.

Remember the second lesson of the series? 5 Whys and the Ishikawa diagram belong in the Plan phase. A hypothesis can only be built on the true cause. Otherwise you treat a symptom and the cycle goes in circles.

Do and Check: Test on a Small Sample, Not on the Entire Production

Do doesn't mean a rollout across the whole production. It means a controlled experiment on a small sample — one machine, one shift, one line. If something goes wrong, the damage is small. When it works, you roll out a verified solution, not an assumption.

In the burr case, we changed the drill bit replacement interval on one drilling machine and one shift. Three weeks of measurement. Defects dropped to 1.4%. Only then was the change rolled out to all six machines.

Check compares numbers with numbers, not feelings with numbers. "We feel it's better" is not a result. A result sounds like this: 4.1% before, 1.4% after, same machine, same part type, measured the same way.

And what if the experiment doesn't work out? That's a result too. You've avoided implementing a solution that wouldn't work, and you know more than before. You go back to the Plan phase with new insights. That's not failure — it's another round of the cycle.

Act: The Step That Decides Whether the Improvement Survives

Act turns a verified experiment into a standard. In concrete terms: rewrite the work procedure, update the operator instruction, enter the drill bit replacement interval into the planned maintenance system, and train colleagues from other shifts.

Without this step, the improvement falls apart at the first operator change or the first rush of orders. The process reverts to its original state, because "that's how it's always been done here."

The 8D report from the third lesson is essentially PDCA broken down into disciplines. Whoever masters 8D masters PDCA as well. The only difference is the trigger — a customer complaint or an initiative from the shop floor.

This Week's Exercise

Pick one small, recurring problem from the shop floor: searching for tools, waiting for the hoist, minor defects. For five days, measure the baseline — how many times per shift the problem occurs and how many minutes it costs. Write the numbers on a single sheet of paper. Then formulate a hypothesis ("If we do X, Y will drop by Z") and next week, test one change on one shift or machine. At the end, compare the numbers and decide: keep, adjust, or discard. The whole cycle fits on a single A4 sheet.

If you'd like to bring quality tools to your foremen and quality specialists right on the shop floor, take a look at our e-learning offering. The next lesson takes you upstream of the defect — FMEA will show you how to uncover a problem in process design before you have to deal with it through the PDCA cycle.

Quiz — test your knowledge