The Many Flavors of the PDCA

In my last posts I explained the PDCA (Plan, Do, Check, Act), common mistakes, and its history. However, there is a whole fruit stand of additional versions with some modifications that have popped up: PDSA, SDCA, OODA, ODCA, DMAIC, LAMDA, FACTUAL, Kata, and 8D – and probably more that I do not know of. Let me explain a bit on the different offshoots and alternatives of the PDCA.

PDSA: Plan, Do, Study, Act

The PDSA was developed by Deming. The main difference is that the Check was replaced by Study. Deming said that the original Check would mean in English to “hold back,” and hence he called the original PDCA a corruption. Maybe my English is not good enough, but “hold back” would not have been on my mind when I heard “check.”

In any case, the implied meaning is nearly the same. The Study part analyzes if it actually worked and improved the situation, and also tries to learn from the Plan and Do parts.

OPDCA: Observe, Plan, Do, Check, Act

Yet another PDCA variant, this time with Observe added at the beginning. For me, this is part of the Plan in the original PDCA, but I am also fine with giving it a separate letter. The Plan in PDCA would benefit from more letters anyway.

SDCA: Standardize, Do, Check, Act

And yet another PDCA variant, where the Plan is replaced by Standardize. You may wonder why there is a Standardize at the beginning, while in the PDCA it is part of the Do. The idea is to observe the current standards and see where the workers deviate from the standard. You can continue with Do, Check, Act if they deviate to find out why, and to change the system that either the standard is updated or the worker follows the standard.

However, in my view, I think this limits the list of problems you can solve. If all your cycles require you to have a standard first, then you can only improve things that have a standard. This would exclude non-standardized steps (infrequent or simply just not yet standardized), and limit many other approaches like machine problems or product quality. Hence, I do not like it too much.

DMAIC: Define, Measure, Analyze, Improve, Control

This DMAIC (Define, Measure, Analyze, Improve Control) is a PDCA offshoot in the Six Sigma offshoot of lean manufacturing. While it has more words, the meaning is somewhat similar. However, I do think DMAIC has some shortcomings compared to the PDCA.

The original Plan from PDCA is split into Define, Measure, and Analyze. First, the positive side: I like that the project is clearly defined in the Define step. However, I think that Measure and Analyze are not always sequential, but rather iterative. Usually you measure, you analyze, and then you go back to measure some more. The goal at the end of the Analyze step is to understand the root cause.

The development of the solution, which at PDCA is still part of the Plan, is now mashed together with the implementation as the Improve step. What really irks me here is that DMAIC has the entire PDCA included as part of the Improve step merely to test solutions. I think that is just wrong. But then, Six Sigma in general has an irksome tendency to claim that it is on top of the world, and even “lean” is just a tool in their toolbox.

The last step, Control, aims to ensure the results are sustainable, usually through standards. What I completely miss in the DMAIC is the Check part of the PDCA. It seems at no part does DMAIC actually check if the implementation worked! For me, this is a crucial flaw if someone follows the DMAIC by the books! Overall, DMAIC goes in the right direction, but it falls short in a few key areas.

LAMDA: Look, Ask, Model, Discuss, Act

LAMDA is actually specialized on product development (i.e., a similar task as the original Shewhart cycle). It also aims to be a PDCA replacement in this field, but for me it has some shortcomings too. Additionally, different sources define it differently. Luckily, it is rarely used.

The Look represents observations on site (i.e., the shop floor). Ask stands for asking questions. So far so good, similar to Genchi Genbutsu. The Model part creates engineering models, simulations, or prototypes. Discuss is more talking about the models and the product. With Act, you would think it is the same as in PDCA, but unfortunately, no. It means to test the experiment or to implement. Hence, it is closer to the Do part of the PDCA. Another definition of LAMDA I have found copies the Act from the PDCA, meaning you try to learn from the previous process.

Did you notice that LAMDA never defined the problem? LAMDA never considers what you want to achieve, or which problem you want to solve. Due to the inconsistency of the Act part, it either never asks if it actually worked, or it never actually generates a finished product. Either way, too many holes in the method for my taste.

8D: Eight Disciplines Problem Solving

This one comes from Ford. Since it was created, a ninth “D” was added at the beginning. Hence, the 8+1D are:

• D0: Plan
• D1: Use a team
• D2: Describe the problem
• D3: Develop an interim containment plan
• D4: Determine and verify root causes and escape points
• D5: Verify that permanent corrections for problem will resolve problem
• D6: Define and implement corrective actions
• D7: Prevent system problems
• D8: Congratulate your team

Overall, not too bad, although I still miss the Check from PDCA, where you check if it actually worked.

Kata

Maybe you are surprised to see Kata here. Currently quite the hype in the lean community, Kata, I think, has a goal similar to PDCA, although it is more oriented toward the big picture. First, Kata is not an abbreviation but a Japanese word for repetitive exercises in martial arts (among other meanings). The four steps of Kata are:

1. Determine a vision or direction
2. Grasp the current condition
3. Define the next target condition
4. Move toward the target using PDCA

Of course, there is quite a bit more detail – for example, the exact definition of target condition (it is not a target, but more of a longer term vision). The PDCA is actually part of the KATA step 4. Overall, I think KATA is useful, but also way too over-hyped in the lean community. After all, the underlying ideas are not really that new, and already existed, for example, during the World War II TWI (Training within Industry) program.

OODA: Observe, Orient, Decide, Act

This one actually comes from the U.S. military. In industry, it is sometimes used for higher level strategic decisions rather than practical problem solving of the PDCA. As such, it is also a possibility if you have higher level strategic issues to solve.

FACTUAL: Focus, Approach, Converge, Test, Understand, Apply, Leverage

After I completed this post, Nicolas below suggested yet another PDCA variant: FACTUAL. This is part of the Shainin toolbox developed by Dorian Shainin (1914-2000). The Shainin approach is using quite a bit of statistics to determine the relation between cause and effect, and to determine the most relevant cause, also known as the Red X. Hence, it is no surprise that FACTUAL is structured around this statistic. Focus defines the problem. Approach investigates the desired effects. Converge identifies the possible causes, including the Red X main cause. Test verifies the Red X. Understand establishes the statistical relation between cause and effect, including the tolerance limits. Apply implements the corrective actions. Finally, Leverage determines the lessons learned.

In my view, you don’t always have the luxury of a deep statistical understanding of the problem, which means you cannot always use FACTUAL. Even so, the focus is on the statistics of understanding the problem, and very little on developing a solution, let alone checking if it worked.

Which One Should I Use?

Okay, so now we have eight variants or other methods that move akin to the PDCA. Which one should you use? Good question. I personally tend to use PDCA, simply because I am used to it, although I think the Plan could have benefited from one or two additional letters to make it clearer. PDSA and OPDCA are also fine. I am not too fond of SDCA, DMAIC, LAMDA, and 8D. Kata and OODA are good for more strategic thinking. To answer the question: Use whichever suits your problem best. If in the past you had good results with DMAIC, continue to use it. If you are a fan of SDCA, go ahead. If you are new and are just starting this type of thinking, probably stick to the traditional PDCA, since it has the most information and support online, and avoids some of the flaws of DMAIC, LAMDA, and SDCA.

In any case, whichever method floats your boat, use it to go out and organize your industry!