As I started to write about how Lean might look like an “undisciplined” way of work I started with the relationship to standards, but almost as high on my list was the idea of the PDCA method. Often we, coaches, and teams as well, tend to react to a problem by saying “just try it out” , do a PDCA cycle. This might look as if we warranted some kind of headless trial-and-error methodology where we need not think, we will anyway try the idea.

This is an understandable but very misleading view. It is understandable, because it generally surfaces as a reaction to an exasperating “analysis-paralysis” type of behaviour. Often, steering committees use the lack of the final (this time really-really final) analysis as an excuse to avoid taking risks. After all, changing something is risky, asking for another data collection and analysis is safe. The worst that can happen is to prove that “in our high risk environment general methods like Lean or Six-Sigma do not work” and no one will be hurt, Looking at this kind of, unfortunately rather frequent, attitude it is understandable to react by asking to simply try an improvement and collect the learnings.

This is even more valid, given the universal human behaviour of taking something seriously only when it really threatens to change something. Theoretical risks and action plans will universally be agreed by the teams . Vital information and objections surface only in the moment when the measures start to be implemented – so, actually implementing something, though incompletely researched and analysed can serve as a trigger to learn more about the system we work with.

These are valid points, but still, this does not preclude carefully thinking through the phases of a PDCA cycle.

The PLAN phase includes the following steps :
1. Check the difference between our present condition and target condition
2. Define ONE problem that hinders us in reaching the target condition
3. Plan an action to either mitigate the problem OR learn more about it.

Especially in the 3rd step, looking at possible risks is something no one in their right mind would neglect.

The DO phase then is executing the planned action and collecting the learnings (and I intentionally do not say data here as the learnings can be much more extended then mere data points,)
CHECK means evaluating the learnings and finally
ACT is what we do with them – change standards or just rework our list of hindering factors or any other reaction that makes sense.

An impression that teams often have, especially if trained in DMAIC earlier, is that we would use a PDCA for simple problems and DMAIC for complex ones. This is sometimes, but not always, true. The two methodologies can work in a way, that one is included inside the other. I would definitely advise running a few turns of a PDCA cycle in the Improve Phase of a DMAIC, if we do not know enough about an improvement action. It can also happen, that in the first run of a PDCA we realize that the factor hindering us is the lack of concrete knowledge about how the system is operating, so the first few cycles the actions might simply be about collecting the right information (again, not just data).

So, how do we decide which method to choose ? Though a long time DMAIC fanatic, I would start with the PDCA in most cases. Defining a target condition and measuring the distance between our as is and our target is simply a much more powerful idea then defining a CTQ and a target value. However, I would never forget the DMAIC toolset and would be ready to include all of it in PDCA cycles, should they be necessary.

So, is PDCA undisciplined? I do not think so. It is our job, as coaches, to make sure that the teams get the right message – which is DO PLAN before you DO !