This post of my series on Practical Problem Solving (PPS) looks at what to do after you have done the “Do” part of PDCA. Yes, that’s right, after implementing the solutions you are not done yet. You need to monitor the outcome to see whether it has actually achieved the target you set much earlier. Here, the next steps can go into two directions. This would be the “Check” of PDCA. If you have not yet achieved the target… well… then you are not yet done and need to keep on working on the problem. If you have achieved the target, congratulations! Now share the wisdom with others. This is the “Act” of PDCA. Let me explain in more detail.
A Quick Recap
As listed in my previous post, the Toyota Practical Problem Solving approach consists of the steps below.
- Clarify the Problem
- Break Down the Problem
- Set a Target
- Root-Cause Analysis
- Develop Countermeasures and Implement
- Monitor Process and Results
- Standardize and Share
Monitor Process and Results
The first step is to evaluate the result of your actions. Did your improvements indeed have an effect on the performance? If so, how much? Did you reach your goals? Graphs and diagrams of data, especially with a time-axis showing changes over time, are really helpful here. Keep in mind that these are not the overarching goals but the improvement project specific goals. See my previous post of this series, Toyota Practical Problem Solving (PPS)—Targets and Root Causes, for a refresher.
There are a few points to keep in mind when doing that. First, if you had multiple countermeasures, can you check the outcome individually for each countermeasure? This is a lot easier if you implement countermeasures one by one as suggested in my last post. Otherwise the cause (i.e., the change in the system) and the effect (the improvement) will get muddled and it is hard to understand what caused what.
Second, also check for other effects of your change. Did it also improve some other factors as a side benefit? Did an improvement in the machine availability also somehow improve quality? Such additional effects are actually quite common. Any free additional improvement is nice and welcome. However, it is also possible that something else got worse. For example, did a faster machine speed make quality worse? In this case you have to consider whether the benefit of your improvement is worth the negative side effects.
Also check the views of the different stakeholders. Try to answer the question “What is in it for me?” from the point of view of the customer, company, employee, and also yourself. Is the customer happy about the change? Are the operators happy?
At this point, you have to make a decision. Is the project a success? Did you reach your performance targets and improve the KPIs. Are the negative side effects negligible? If yes, you can continue to standardize and share the results. After that, you can focus on the next biggest issue you have in your area of responsibility. It is rare that managers run out of things to fix. In the pink unicorn situation that you indeed run out of problems to fix, look harder for problems…
If you have not (yet) reached your goals, then the problem is not (yet) solved. You need to go back to understand and break down the problem some more, do more root-cause analysis, and see what you can do differently to achieve your goals.
In my experience, this is often unpleasant and difficult. The final presentation for the project was may be already done, the deadline for the implementation has passed, and focus, resources, and (your) time have already been allocated for the next project. This all needs to be turned back since the problem has not yet been solved. It is, however, a great learning experience. On the other hand, at least some bosses see it as a failure, and hence many employees are worried about how this will impact their career plans. Every company gets the employees it deserves…
Standardize and Share
Now you are almost done. You need to standardize your achievements to prevent backsliding into an older, inferior way of working. You need to update the work standards, train the operators, and do process confirmation that the operators actually follow the standard. This is standard for anybody working with standards (pun intended).
For the company it is also beneficial if you can share the results. In some cases, the project you just did was merely a test on a small scale to see if it works. Maybe you have ten (nearly) identical production lines, and you fixed the problem for one line. Great. Now fix the other nine. Use the lessons learned from your project to apply it to other, similar problems. This may be another improvement project, where the learning from this current project help to speed up PDCA for the subsequent projects.
Some companies provide an infrastructure to share your learning with the rest of the company. For example, Toyota has an internal database where successful improvement projects are uploaded. Other Toyota employees tackling their own problem access and search this database for similar problems from others to get inspirations and ideas for solutions. At Toyota, this is called Yokoten. Prepare and clean up your documentation and share it with your company.
Summary
You have done it. You have solved a problem using the Toyota Practical Problem Solving approach. This is the right way to do it, and much better than continuous firefighting (albeit some companies and some people just LOOOOOVE firefighting, since it looks so good; see my post on Heroes, Firefighting, and Corporate Culture). Now, go out, make sure your problems are solved properly rather than addressing the symptoms, and organize your industry!
PS: Many thanks to the team from the Toyota Lean Management Centre at the Toyota UK Deeside engine plant in Wales, where I participated in their 5-day course. This course gave us a lot of access to the Toyota shop floor, and we spent hours on the shop floor looking at processes. In my view, this the only generally accessible course by Toyota that gives such a level of shop floor involvement.
In my opinion, when you improve but have not met the objective, the best is to stay where you have arrived and, from there, make new efforts to meet the initial objective.
I have made Comments earlier. Why are these not published?
Hi Michael, you commented on another article of this series, I think: Toyota Practical Problem Solving (PPS)—Countermeasures and Implement. I thought it was a useful comment.
I sometimes delete comments if they are spam, others are removed automatically by my spam filter, but I haven’t deleted one of yours nor is one of yours in my (recent) spam filter.
Hope this clears up the confusion 🙂
Hi Christopher, in six sigma we are taught that one-factor-at-a-time experiments are inefficient. I appreciate this clashes with Toyota’s approach. But, what are your thoughts on say putting a Taguchi design in the monitor process & results?
Hi Jonathan, good point. I have used Design of Experiments myself, too, and find them quite useful. The problem is that for a good DOE, you need to switch factors on and off or generally change the variable to find out its impact. E.g. for a simple 2 variable analysis you could have 4 points (Low/Low; Low/High; High/Low; and High/High). This would require you to “undo” previous improvements, which could be a bother and could be detrimental for the sake of understanding the system. Doing the improvements one by one may actually be best in most cases. But, an interesting point. Thanks for sharing!