The Many Flavors of the PDCA.
Problem SolvingAnalysis, Critical Thinking, Lean Tools, Problem Solving
PDCA VariantsIn 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, 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.

introducing-agile-scrum-xp-and-kanban-14-638

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 Observeadded at the beginning. For me, this is part of the Planin 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

Six SigmaThis 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 Definestep. However, I think that Measure and Analyzeare 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 Modelpart 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

Ford Motor LogoThis 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:

Determine a vision or direction
Grasp the current condition
Define the next target condition
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

United States Department of Defense SealThis 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.

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!

The Many Flavors of the PDCA.

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.

ACEPTAR
Aviso de cookies