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
- 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.
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.