The situation

On Tuesday the team changes a seal on the molding cell. On Wednesday the line runs. On Thursday a new fire starts elsewhere, and the seal is forgotten. Was the flash problem fixed? Nobody knows. The action list says “done”. The scrap bin has not been counted.

This is the most common way improvement fails. The team did Plan and Do. Nobody did Check.

What PDCA is for

PDCA stands for Plan, Do, Check, Act. It is a small loop for testing a change before you make it permanent.

  • Plan: say what is wrong, what you think causes it, what you will change, and what number will prove it worked.
  • Do: make the change in a small, controlled way.
  • Check: on a date you fixed in advance, measure the result and compare it with the target from Plan.
  • Act: if it worked, make it the standard way of working. If not, learn from it and start a new loop.

Three terms:

  • Hypothesis: your best guess at the cause, written down so it can be proven wrong.
  • Target: a number with a unit, such as “flash scrap under 0.5%”.
  • Check date: the day you will look at the data. Pick it during Plan, not afterwards.

Plan, Do and Act feel like work. Check feels like paperwork, so it is the step people drop. It is also the only step that tells you whether you were right. Without it you have an opinion with a deadline.

A short history

Walter Shewhart described a three-step cycle of specification, production and inspection in 1939, in Statistical Method from the Viewpoint of Quality Control. W. Edwards Deming presented a wider version to Japanese engineers and executives through JUSE in 1950. JUSE members then simplified it to Plan-Do-Check-Act around 1951, and the shape became known as the Deming Wheel. Later, in Out of the Crisis (1986), Deming preferred “Study” to “Check”, because he wanted people to understand results, not only inspect them. Both names are in use today. The exact details of who changed what and when are not fully settled, so treat the dates as commonly reported.

Where it applies, and where it does not

Use PDCA for:

  • Small experiments: a tool, a setting, a layout, a work step.
  • Kaizen ideas, where you want proof before you rewrite the work instruction.
  • Testing a countermeasure on one line before copying it to others.

Do not use it for:

  • Emergencies. If bad parts are reaching a customer, contain first. Sort, block stock, protect the customer. You can run PDCA afterwards on the cause.
  • Validated standard work. If the work instruction is proven, follow it. Do not experiment on a running process.
  • Very large programmes. A new building needs formal project governance, not a card on a board.

How to do it

Our example is at Valvetech Assemblies, a fictional valve plant. Marek is the shift leader. Tomasz is the molding process technician. Check valve housings from Injection Molding Cell 03 show seam flash.

  1. Plan. Write the gap: flash scrap is 4.2% at the inspection camera. Write the hypothesis: cavity 4 loses pressure because the shut-off collar seal is worn. Write the target: flash scrap below 0.5%. Write the check date: Thursday 14:00, after 48 hours of production. Tomasz and Marek agree that 48 hours is enough parts to count.
  2. Do. Tomasz replaces the collar seal with a Viton ring and raises clamp force by 3%. Shift 2 records the run parameters and anything odd they notice. Only this cell is changed.
  3. Check. On Thursday at 14:00 the camera has logged 1,450 parts. Four are scrap. Four divided by 1,450 is 0.28%. That is below the 0.5% target, so the answer is clear. Marek writes the number on the card, not “looks better”.
  4. Act. The result met the target, so the change becomes standard. Machine recipe CV412-REV4 is saved, the work sheet is updated and the finding is shared at Friday’s line review. If the result had been 2%, they would write what they learned and start a new cycle with a new hypothesis.

One more thing. They also note that two changes were made (seal and clamp force). If they need to know which one did the work, the next loop tests them separately.

Three ways it goes wrong

  1. Plan-Do-Plan-Do. The Check never happens. The change is assumed to work, and the team moves to the next fire. The fix is a check date written on the card on day one, with a name next to it.
  2. Containment called an experiment. Adding an extra inspector at the end of the line is not a countermeasure. It protects the customer today and leaves the cause alone. Record it as containment and keep going until the cause is gone.
  3. Opinion in the Check box. “Operators feel the machine runs smoother” is not a result. Write a count, a rate, a cycle time or a gauge reading. Compare it with the target from Plan.

Our recommendations

  • Put the check date and the target on the card before you start the Do step.
  • Give the check to a person, not to “the team”.
  • Allow enough run time. Checking an hour after the change proves little.
  • Use the same measure in Check as in Plan.
  • If Check shows failure, that is a result, not a failure of the team. Write it down.
  • Keep each loop short: days, not months.

Try it

The PDCA tool will give you a one-page card with the check date at the top, plus a calendar reminder file. It runs in your browser with no account. It is coming soon: PDCA card tool.

From the book

PDCA is Chapter 9. The chapter’s message is the same as this page: closed is not solved. See the book page.