Tag Archive | PDCA

PDCA and marshmallows

What I like the most about PDCA is that it is practical and simple, what makes it ultimately sophisticated (thanks, Leo). Simple does not equal easy, the proof is that it took the mankind millenniums to develop the scientific method.

Check out this TED video called “build a tower, build a team” (aka “the marshmallow challenge”):

The video shows very important and not so evident ideas about thinking and developing new solutions: The most important are:

  • Pure planning does not work well. The “Plan” phase of PDCA is very important, but not the most important (let’s say it is as important as the others). Planning without doing is useless. Planning without being prepared to fail and learn from the things that went wrong is naïve. Many people are trained to find the “single right solution” and then execute it. This is a wrong strategy (by the way, this is how many people think PDCA and DMAIC work. Wrong!)
  • The value of prototyping: Prototype + Refine is a great strategy. Build something that works and then make it better, so that the development team gets continuous feedback about what works well and what does not. For this, of course, it is critical to know what is your marshmallow, this is, what is your goal or the critical customer need you want to meet. It is so common to find teams who don’t really know what they are doing…
  • The importance of facilitation: The importance of the process! A development team with technical people and process people is a winning team. Diverse teams with different people of difference areas may move slower (not necessarily) but will definitely get further. The importance of people who can facilitate, organize and solve conflict is often underestimated.
  • The effect of incentives: “Incentives + High skills” lead to success most of the times but high stakes with a low level of skills might be catastrophic: everybody panics and nothing gets done. Use incentives intelligently.

All these concepts apply to Lean thinking. It is basic to know your goal (your marshmallow), use prototyping (continuous improvement), create a diverse team (respect for people) and use incentives wisely. Keep this in mind and your probabilities of success will be higher.


Voltaire, détail du visage (château de Ferney)

Voltaire, détail du visage (château de Ferney)

Voltaire once said “Le mieux est l’ennemi du bien“, perfect is the enemy of good.


If you think, it is not a bad description of how PDCA works. Try a solution that makes sense, sounds reasonable or can help you learn. It does not matter if it is not perfect, just try it and see what happens. If you wait for the perfect solution before you start doing, you’ll probably wait forever.

Myths about PDCA


PDCA is a simple and powerful way of thinking. There is, however, some misunderstanding about its use. Yesterday I participated in a training session with some students and Lean teachers about how to use PDCA. These are some of the most interesting questions we discussed at the session:

  • PDCA is for engineering: PDCA is great for solving technical problems. This does not mean that it can only be used for that. Things like “how to design a training session” or “how to create a robust communication plan” can be studied and implemented using PDCA. At the end of the day it is a structured way of establishing hypothesis and testing them.
  • The “P” phase is over when you have a project plan: “P” (Plan) does not mean “create a to-do list”. The most important part of “Plan” is to establish a hypothesis and define a goal for your experiment. It is incredible how many “so-called PDCA cycles” are begun without knowing what you want to test. Therefore the tests will probably be useless or, in the best case, will provide very limited information. If you don’t have a goal, any direction is valid.
  • The “A” phase does not look too important: “A” (Act/Adjust) provides the time to think about what you learned in your previous experiment. The “Act/Adjust” phase creates the learning cycle, links one experiment with the following one and increases dramatically the chances of success. If you don’t stop to think, you are not learning, you are just shooting in the dark.
  • PDCA is about trying things and testing if they work: Well, yes, but this is only half of the work. If you just do things and check if they work, what you get are several DC (do-check) tests, not PDCA cycles. The difference is important at least in 2 ways:
    • Do-Check skips “Plan” and jumps directly to “doing”, which is not a good strategy (see again bullet 2)
    • Do-Check skips “Act/Adjust” and does not link experiments, which, again, is not a good idea (see again bullet 3).
  • It’s so difficult to check if things have worked! This is typically a signal that the “Plan” phase is missing or has been done only partially (and remember, “no goal” means that anything is valid). Sometimes data is really difficult or even impossible to get. In that case use indirect metrics to determine success (for example, one can know if a training session has been fruitful if the number of operation errors decrease)

PDCA is a great friend for any improvement effort. Just use it with love.

Lean DNA


It is always good to remember this: Lean is not about the tools, Lean is a thinking system. The Toyota Production System and its tools (SMED, 5S, Kanban,…) have often been considered the same thing. Everybody working with lean has probably made this wrong assumption at some point, but TPS is much more.

The classic article “Decoding the DNA of the Toyota Production System”, by Steven Spear and H. Kent Bowen (HBR, Sept 1999) helps understand that TPS greatest achievement is to create a global community of scientist who use PDCA to establish hypothesis and test them. In other words, it creates a rigorous problem solving culture. Read the full article here:


Thomas L. Jackson (Hoshin Kanri for the Lean Enterprise) has summarized it this way: “The major question in assessing [Lean] development is: To what extent has scientific PDCA thinking become part of the company’s culture?“. This idea can be articulated in 5 rules:

  • Rule 1: Standardize processes & work
    • Reduces variability
    • Improves quality & learning
    • Creates controlled conditions for improvement
  • Rule 2: Zero ambiguity
    • Customer requirements must be absolutely clear to everybody working in the value stream
  • Rule 3: Flow the process
    • Material and information move in the most direct way
  • Rule 4: Speak with data
    • Decisions taken at the lowest possible level
    • Decisions takes as close to real-time as possible
    • Decisions based in PDCA
  • Rule 5: Develop people
    • Workers who are problem solvers
    • Leaders who are teachers

The best strategy to develop Lean is to find your own way of applying Lean rules and not to simply “copy and paste” Toyota tools. Implementing tools without much thinking rarely works, creates frustration and ultimately makes everybody lose faith in continuous improvement.

Improvement Kata

Kata is a Japanese word that describes detailed choreographed patterns of movements practised either solo or in pairs (thanks, Wikipedia!). Its goal is to transmit proven techniques and make them so natural that they can be used and adapted to each situation quickly and without hesitation. The key concepts here are that katas “are practiced everyday” and “adapt to the circumstances”, they are not strict routines that fit everywhere without much thinking.

The concept of Kata fits well in Lean. Lean means everyday work. Lean means practicing everyday proven problem solving techniques. Lean means adapting to the circumstances. Lean is not a project.

Coaching plays a key role in developing Lean thinking. Asking questions that generate the right mental process and using PDCA cycles to practice and learn are 2 of the most important things to do. This is an example of how to do it, presented at a recent Lean conference by the Lean Management Instituut (Netherlands)


Remember: Small improvement steps (think what to do, do it, see if it works, consider what you have learned) beat big improvement projects.


It’s sooo clear


“Doubt is an uncomfortable condition, but certainty is a ridiculous one.”
― Voltaire
Whenever you work in any improvement initiative, it’s probable to hear managers express thoughts similar to these: “It’s so clear that…”, “It’s evident that…”, “It’s so obvious…” and some other variants that you can easily imagine. These sentences are normally a warning signal, especially if there is clear evidence that the process has problems. Typically you’ll find one of these two situations:
  • Problem one: management is not sharing the needed information with the shop floor. Managers who find everything crystal clear may honestly think that they are doing a great job sharing the critical information (e.g. what process step is causing most complaints). He/she can not understand why others don’t get it. The process may be truly very easy to understand but the information is not available where the work is really done.  A gemba walk can be a great solution for this, so that this person sees in what conditions the work takes place. Once the real situation is clear, excellent next steps can be the implementation of standard work & visual management to make information available and make sure that it reaches every part of the process.
  • Problem two: management is not getting the needed information from the shop floor. In this case, managers are oversimplifying (on purpose or not) a situation that is really more complex than they might think. Again, gemba walks and talking to process experts will work as an eye-opening experience. After this, standard work & visual management will help now too, but in this case you need to focus in making problems visible to everybody, agree actions to solve them as a team and make leaders go to the gemba regularly and track results.
When somebody states that everything is fine without supporting his words with data, take it more as a warning sign and not as a proof that everything is under control. This is especially important if there is no clear evidence of visual management.

People who don’…


People who don’t take risks generally make about two big mistakes a year. People who do take risks generally make about two big mistakes a year.

Peter Drucker

One of the basic concepts of PDCA (Plan-Do-Check-Act) is that you should plan your improvement work before you actually start doing it. In many cases taking baseline data, talking to experts and, of course, going to the gemba is needed for a good “plan” phase.

But unfortunately some people stop here and data is taken as if having a check sheet or an excel file is enough. It is NOT. The plan phase has to be done looking for subsequent action. In other words, get the data you need to move to action in a meaningful way with a controlled level of risk.

Two notes on this:

  1. “Meaningful” does not mean “be sure that you will be right”. It means “be sure that you’ll learn something”. Don’t do useless tests just because you forgot to measure a critical parameter. Sometimes you are lucky enough to prove the root cause of your problem. Hurrah! But proving some hypothesis wrong can be even more important.
  2. Every change has a certain level of risk. There is not such a thing as “no risk”. I’m serious. The good thing (?) is that doing nothing can be even more risky. Not being scared of trying (controlling risk, of course) is key. Creating an environment for safe testing is fundamental.

Once the Plan-Do is done, it’s time to Check and Adjust as needed!