The D in PDCA stands for Do, not Discuss

Standard

PDCA is abbreviation for four simple steps: Plan, Do, Check and Act. Its main idea is that any change (Act) should first be analysed (Plan), tested (Do) and verified (Check). PDCA is probably the most prominent concept of Lean. In fact, many confuse PDCA—and the related practice of continuous improvement—as Lean Management’s main objective, disregarding many other important principles like Flow, Jidoka or Genchi Genbutsu.

PDCA Cycle

Where does the Discuss appear?

Many time when running a PDCA cycle I witnessed that the Do is being confused with a Discuss. So once a situation has been analysed successfully, it is far too common that root causes and possible solutions are being thoroughly discussed for days or even weeks. While alignment among stakeholders is very important, it gets dangerous if this agreement is confused with the Do and Check part1It is even worse of course if the agreement is obtained by the HIPPO (HIghest Paid Person’s Opinion). of the PDCA cycle. Just because everyone agrees on a solution, it doesn’t mean that this solution will actually bring some improvements. As a result, many untested solutions are implemented on a large scale, a lot of money is being wasted, and whole Lean initiatives are getting discredited.

Where does the Discuss come from?

There are two reasons behind this behaviour: Anxiety or fear of failure.

Anxiety might lead you to believe that your untested solution will work for sure. So you like to gain time by jumping the Do and Check steps. From my experience, this behaviour is catastrophic since untested solutions always miss some important points.

Fear of failure is closely linked to a negative error culture2See also the first chapter of Gigerenzer’s book Risk Savy: How to make good decisions. The origin of this fear might come from the top (autocratic bosses), the bottom (workers expecting the engineers coming up with perfect solutions) or outside stakeholders (clients or suppliers who like to take advantage of admitted mistakes). The result is that nobody likes to run small tests which could expose problems. Instead, everyone looks for the biggest possible implementation scope in order to justify a long lasting analysis which delays the discolsure of any errors to the latest possible moment. Since this behaviour is rooted within the company culture, it is very hard to break and requires a lot of coaching of all stakeholders.

How to do the Do?

So in order to insert the Do and Check step between the Plan and Act step, it is important to step back and assure that any of the points below have actually been done, before starting any large scale implementation:

  • Pilot the solution so that the most important aspects can be verified in a couple of hours or days.
  • Build an prototype of your solution. Any quick & dirty solution will be just perfect3I personally prefer paper and cardboard for physical prototypes. They are cheap and can be build in a couple of hours. In software development and the service sector, I prefer to build a first version of the solution which captures the main points and will be ready in a day or two.. Present this prototype to others. Try to use it during lunch break or in the after hours.
  • Simulate a new process on paper and pencil, or with a simulation software. However be sure what you simulate also adverse situations, and not only the business as usual.

Any of these points above will assure that you gained some initial learning before investing serious time and money.

Final Considerations

Even if you can control your anxiety, which is often my problem, and even if you don’t have to deal with fear of failure, it can be rather difficult to maintain the discipline of following all four PDCA steps. So it is important to remember that you shouldn’t try to be smarter that Scorates how said almost 2.500 years ago: “I known that I known nothing”.

Footnotes   [ + ]

1. It is even worse of course if the agreement is obtained by the HIPPO (HIghest Paid Person’s Opinion).
2. See also the first chapter of Gigerenzer’s book Risk Savy: How to make good decisions
3. I personally prefer paper and cardboard for physical prototypes. They are cheap and can be build in a couple of hours. In software development and the service sector, I prefer to build a first version of the solution which captures the main points and will be ready in a day or two.