Plan-Do-Check-Act (or PDCA) is one of the key elements in lean manufacturing, or for that matter in any kind of improvement process. In my view, it is the most basic framework for any kind of change. All other lean tools are only on top of the PDCA.
In my experience, most lean projects in the Western world fail not because they do not have some detailed tool, but because the PDCA is neglected. Of course, (almost) everybody knows what the PDCA is, but there is a huge difference between knowing the theory and doing it correctly. In this post I will explain in more detail how PDCA should work. In my next posts I will show you the common pitfalls of PDCA, its history, and the many, many different variants of the PDCA that are out there.
What is the PDCA?
The first step in the PDCA is the Plan. As the name says, you plan what you are going to do. Depending on the project, this may be the largest part of the effort of the PDCA. In fact, you can see it as a number of sub-steps or points that you have to address in the Plan. Depending on your progress, you may even have to do some of them iteratively until you get a suitable solution.
- Define the scope: What problem are you looking at?
- Define the target: What do you want to achieve? What are your goals?
- Analyze the situation: Try to understand what the current situation is. Talk to people. Visit the shop floor and observe (Genchi Genbutsu). Collect data.
- Develop solutions: What approaches could help you to fix the problem?
- Select the best solution: Out of the different solution ideas, select which one you think is most promising with the biggest bang for your buck.
The Plan covers a lot of ground. Personally, if I would have to re-invent the PDCA, I would give it a few more letters beyond just plan. Oh, wait, people already did re-invent the PDCA, although I am not always convinced of the results (post with more details on PDCA variants coming up soon).
This is the actual implementation. Change the shop floor, create the product, actually make it happen. In all likelihood you will encounter additional problems during the Do that you did not think of before. That is normal. Just solve them as they come along.
In any case, try to make the Do stick. For example, if you change the way workers work, it is easy to have workers do it in a new way once. It is much more difficult to have them do it in the new way from now on. Depending on the problem you are trying to solve, standardization can really help here. Create a standard, train the workers, and confirm that they are following the standard even a few days later.
This is probably the most frequently overlooked part of the PDCA. Did your implemented solution actually work? Did you achieve your goals? This is a very serious question. Judging from my experience, in most cases it does not, or at least not well enough.
Far too often, management is satisfied with a spiffy-looking presentation, and is ignorant of the reality on the shop floor. Additionally, they are also ignorant of the Hawthorne effect. This effect was first observed at the Hawthorne Works of Western Electric in 1930 and was named in 1950. In many cases, changing something on the shop floor will improve the system, regardless of what you change – but only for a short time! In other words, the management attention during a change process on the shop floor will lead to higher productivity and better quality, regardless of what is actually implemented. However, as soon as the management attention has moved on, everything reverts back to the old state.
This is a very common trap. You do a project, the KPIs improve, you move on, and the KPI then reverts to what it was. For an improvement project to work, the improvement not only has to actually work, but also has to continue working. That is the whole idea of the Check part in the PDCA.
The Act is to decide what to do next. This depends on the outcome of the Check. If your implementation failed to achieve the targets, you have to find out the reason. Why did your solution fail to perform as you expected? This will lead to a repetition of the PDCA with another Plan to figure out a new or better solution to achieve your goals.
If you managed to achieve the goals (without falling back after two weeks, mind you!), you should congratulate your team and show your appreciation! With shop floor teams, I always had great success with a three-pound bucket of gummy bears or similar.
However, work never stops. Now you have to think about which problem to solve next. Prioritize your problems, pick the most relevant one (usually the one with the best expected benefit for the effort), and start a new PDCA.
Overall, the PDCA is for me the basic fundamental framework underneath all improvement activities. And I know it is not easy. I often find myself skipping steps or doing the PDCA sloppily if I do not pay attention. It takes a lot of focus and concentration to do it well. While the first two steps, Plan and Do, come naturally to most project managers, actually checking if it works and acting upon it is much rarer. I sometimes even have the feeling that the Check and Act are not really wanted in industry. Pointing out that the newly installed immensely expensive equipment does not work is something not everybody wants to hear. I will talk more about the possible mistakes in a PDCA and the history of the PDCA in my next post.
I hope your boss has an open ear for such things, and you can go out and not only Plan and Do but also Check and Act in order to organize your industry!
6 thoughts on “The Key to Lean – Plan, Do, Check, Act!”
Very good points are presented here. But like you said if the latter 2 steps are omited(and most of the time are ) you remain with a nice presentation until next year when the next management observe the new/ same state.
Absolutely. In my next post I will go into more detail about omitting C&A.
I agree. You do need to follow up on your projects to make sure that it sustains. People tend to change based on their mood of the day. It is important to track to make sure it is the right change. If they have a better method to the process then review that while you sustain the project that has been implemented. This lets people know you are willing to take their suggestions to consideration and respect their ideas.
With the utmost respect to you and your work I cannot understand why people still want to promote PDCA when in fact DMAIC is a much more well balanced, logical, easier to teach, easier to follow methodology. You admit yourself that the work ‘Plan’ is too generic a word. Are we not ‘Planning’ and ‘Refining the plan’ all the way through a project ? You will recognize that ‘Plan’ is an activity the is only one activity recognised the PMBOK of the Project Management Institute, started in the ‘Initiate’ phase. The project plan is constantly being updated. In fact ‘Define’ is a what we are trying to do as a first step in any project. Define the problem we are trying to solve. Define the stakeholders. Define the project team. Define the scope. Define a high level plan.
The next biggest issue I have with PDCA is that the word ‘Do’ and the word ‘Act’ are so similar in meaning. Why do we have One Quarter of the Methodology ( 1 letter out of 4 ) describing the activity of moving onto the next thing ? Would not the word ‘Close’ be better ? Do we really need to take up 25% of the letters for this step ? In DMAIC the word ‘Control’ is a far better description of the post-Implementation step. I believe the Walter Shewhart and W. Edwards Deming would both agree that DMAIC is a better description of what we really need to be doing in a Process Improvement project.
Can you really defend PDCA when it goes up against DMAIC ? I would be interested to hear how you do that ? Thank you.
Hello John, I already have a post prepared for May 3rd comparing different PDCA variants, including DMAIC. Overall, I am absolutely not impressed with DMAIC. I don’t think the sequence is very stringent. For example, the whole PDCA is supposedly part of the DMAIC improve step. But my biggest problem is that the idea of checking if it actually worked is extremely weak or completely absent in DMAIC, even though for me it is the most important part where most projects fail. In any case, more on May 3rd.