Common Mistakes with the PDCA (and Some History)

In my previous post I explained how the PDCA (Plan, Do, Check, Act) should work. However, while most people know the PDCA in theory, I find that the practical implementation is often lacking. And, quite frankly, I am also sometimes sloppy with the PDCA way more often than I would like to admit. Time for some reflection and observation on what works, and why so often it does not.

Hence, in this post I will show common pitfalls and problems when doing a PDCA. Also, simply because it is one of my pet interests, I will also show a bit of the history of the PDCA and its origins in quality control.

Common PDCA Failures

Skipping Check and Act

Probably the biggest cause of failure in PDCA (and all its variants) is to skip the Check and Act steps. Way too often in industry, people are not really interested if it actually works. Of course, they say that they want it to work, but all their actions show that they do not really care. A spiffy presentation is all that is needed to satisfy them, and they can move on to the next problem.

In fact, I sometimes get the feeling that pointing out that an expensive installation does not work is not very popular in industry. Hence, it is unsurprising that few career-oriented people bring up such an unpopular issue. Soon people will learn that a spiffy presentation is as good for the career as solving the actual problem. Maybe even better. In any case, a presentation is usually easier than solving the issue at hand.

If there is no checking to see if the implementation actually works, there will be a high percentage of projects that won’t work. The problem is not solved, but everybody moves on to the next project. Everybody is running but nothing is moving forward. What a waste! I know it is difficult and I have to force myself every time too, but please do not skip the Check and Act! This is probably the biggest cause of most failures in lean projects!

Developing Only One Solution

There is a nice lean exercise called the Marshmallow Game. You have to build a tower from (dry) spaghetti that has to support a single marshmallow on top. The highest tower wins. This game has been done with many different people. The best results are not with consultants, or engineers, or academics, but with kindergarten children. The adults discuss a lot and eventually build one tower – which often fails. The kids simply try out different things and learn from their mistakes.

This type of problem solving is also good for industry. Of course, you cannot always try out many different solutions. However, you should not only develop one solution and then start implementing. In Japan, there are commonly many different solutions considered, and in the end the most promising one is implemented. See also my post Japanese Multidimensional Problem Solving.

Doing It Alone

A group is usually smarter than an individual. Try to get a few people together when solving a problem. Ideally, it should include at least one person actually working at the site, but additionally a technician for the implementation and a supervisor to authorize things. For me, the perfect group size is between three and five people. This way, it may take a bit longer to agree on a solution, but the solution is almost always better than what a single person could have figured out.

Origin of the PDCA

After a selection of what could go wrong, here now, as promised, is a bit of history on the PDCA:

Scientific Method

Many writers base the PDCA on the scientific approach of conducting experiments and checking the outcome. In this scientific approach, a method is tested with experiments (think Francis Bacon, Galileo Galilei, etc.). I think this is maybe a bit far fetched, but it is a nice bit of history.

Shewhart Cycle

Probably the first to show it as a circle was Walter Shewhart, also known as the father of statistical quality control. However, he originally had only three steps, first in a line and later in a circle: Specification, Production, Inspection. Hence it is also known as Shewhart cycle.

Deming Cycle

A young quality engineer edited Shewhart’s book in 1930. This engineer was Edwards Deming, who later became famous in Japan for teaching the Japanese quality control. Later in 1950, he renamed the steps slightly and added a fourth step: Design, Produce, Sell, Redesign, and taught it in Japan. Hence it is also known as Deming circle/wheel/cycle. In any case, you can clearly see that the origin of PDCA is rooted in product development and product quality, with the idea to constantly improve a product through redesign so that the new product sells even better. In comparison with the modern PDCA, however, I think the Check section of analyzing flaws and improvements is a bit short.

The Japanese PDCA

Deming’s teachings in Japan fell on fertile ground and probably helped Japan significantly improve product quality. He also taught his Deming cycle to the Japanese. Japanese engineers picked up the idea and in 1951 evolved it into the Japanese version of the modern PDCA, consisting of:

• 計画 (Keikaku) for plan; project; schedule; scheme; program
• 実施 (Jisshi) for enforcement; implementation; putting into practice; carrying out; operation; working
• チェック, which is the English word “check” written in Japanese letters
• アクション, which is the English word “action” written in Japanese letters

The Western PDCA

Translating the Japanese version into English (with a tiny bit of liberty) gives the modern Plan, Do, Check, Act. This is also the cycle used by Deming later on, and modified into a Plan, Do, Study, Act.

The original two cycles by Shewhart and Deming are all but forgotten. Most references nowadays give the Shewhart cycle and the Deming cycle as alternative names to the PDCA, although to be frank I have never heard anybody call it by these names. In any case, these references usually mean the PDCA and not any of the earlier versions.

Summary

I hope this overview of causes of PDCA failure and also the history of the PDCA was of interest to you. In the next post I will show you a selection of the different variants and similar methods out there, including PDSA, SDCA, OODA, ODCA, DMAIC, LAMDA, Kata, and 8D. In the meantime, go out and organize your industry!

Sources for the History Part:

• Moen, Ronald. “Foundation and History of the PDSA Cycle.” Associates in Process Improvement–Detroit, 2009.
• Moen, Ronald, and Clifford Norman. “Evolution of the PDCA Cycle.” Associates in Process Improvement–Detroit, n.d.