Toyota Practical Problem Solving (PPS)—Countermeasures and Implement

In this post of my series on the Toyota Practical Problem Solving (PPS), we finally get to the part many were excitedly waiting for—the development of countermeasures and their implementation. Some people like this part of actually doing the improvement (and hence finally the “Do” part of PDCA) so much that they skip the “Plan” part almost entirely. Don’t do that! Properly prepare and analyze before implementing a countermeasure. Without the plan, the countermeasure may be flawed.

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

Develop Countermeasures and Implement

The task is to develop countermeasures and to implement them. The countermeasures to resolve the problem (or at least to make the problem less common or less damaging) should be based on the root cause. If you have multiple root causes, you may need multiple countermeasures for each of your root causes. Even if you have only one root cause, you may still consider and investigate multiple countermeasures. Look at all possible options that could influence your root cause. Since this is a bit more complex, I have divided it into subsections on developing multiple countermeasures, selecting the most promising countermeasures, and finally implementing them.

Developing Multiple Countermeasures

Developing, or at least considering, multiple countermeasures is actually quite common at Toyota. In the West, the first solution is often followed through, no matter how good the solution actually is. At Toyota, they often consider multiple solutions and compare them.

For example, when Toyota developed the first commercially successful gasoline-electric hybrid, the Prius, they developed around eighty initial concepts for an ultra-low-fuel consumption car. This included everything from fully electric vehicles, to fuel cells, to diesel engines. These eighty concepts were then evaluated and narrowed down to thirty, which were studied further. From these thirty concepts under closer evaluation, the best ten were chosen and studied even more. Out of these ten, a list of the top three promising concepts were selected, and even more research and effort was put in to understanding and developing these three even further. The final winner in the last round was a gasoline-electric hybrid power plant for the Prius.

Hence, let your creativity run wild and think of anything you can that could improve the root cause for your problem. Don’t worry too much about the feasibility (yet), since this will be looked at during the next step. Similar to brainstorming, there are no bad ideas, as any idea with not-so-much potential could be an inspiration for an even better idea. More is clearly better here. Do this for all of your root causes.

Selecting Countermeasures

Pick the right ones...
Pick the right ones…

Hopefully you have more than one countermeasure for every one of these root causes you identified. If you have multiple root causes, some countermeasures may impact only one root cause, while other countermeasures impact multiple root causes. Now you need to pick which root causes you actually want to implement.

You may not need to look at eighty different possible solutions to resolve your root cause. But you should definitely take more than one solution under consideration. Look at multiple ideas on how to resolve the root cause, compare them, and pick the most promising ones for implementation. When comparing different solutions, you should consider how effective the solution will address your root cause(s), but you should also consider factors like safety, quality, productivity, cost, timing, and the ease of implementation, as well as its impact on other functions. It is probably best to make a table here with one row for every countermeasure and one column for these performance parameters.

Also, do not to get sidetracked to implement something completely different just because it is a nice idea; instead, make sure that your possible actions do improve the root cause! Additionally, try to see it from the view of different stakeholders, answering the question “What is in it for me?” from the point of view of the customer, company, employee, and also yourself. For the Prius, they went with a single final and most promising concept, as they wanted to design only one car model. For your problem-solving, you could implement multiple solutions.


You could theoretically implement all selected solutions at once. However, Toyota prefers to implement them one by one to see how much of an impact each solution has on the root cause. There are obvious exceptions when, for example, combining two root causes will significantly reduce the cost (e.g., buying a new machine that has two features/solutions at the same time). But just being faster is not necessarily a good cause for merging the implementation of your solutions. Especially for organizational changes (which are common in lean), you could make a trial period to try it out in order to evaluate its effectiveness and feasibility.

It is really helpful to also build a consensus here, including employees, management, and other impacted departments. This will greatly improve the acceptance of your countermeasures. But if you did the right thing and already involved these stakeholders while clarifying the problem, breaking down the problem, setting a target, doing the root cause analysis, developing countermeasures, and evaluating them, then these stakeholders should already be on board and supportive of your plans. Also consider who has to be informed and who has to approve.

Based on this, you should create a plan for which solution to implement or try out first (probably the most-promising one/highest-value-adding one unless there are other reasons not to), which one second, and so on. For each you should decide what needs to be done by whom and by when.

And then, finally, just do it! Follow through with your plan and implement or at least test these countermeasures. In my next post we will look at the “Check” and “Act” parts of PDCA, where we monitor the process and results as well as standardize and share the learning. Now, go out, do something about your problems (preferably the right thing after a thorough “plan” of PDCA), 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.

6 thoughts on “Toyota Practical Problem Solving (PPS)—Countermeasures and Implement”

  1. Christoph thank you again for one more “very rich” article. I’m not sure if what I’ll said is really correct or not since I didn’t find a definition in the “Lexical Lean” book about the word “Countermeasure”. In my understanding the meaning of “countermeasure” is some action to improve the current status, not exactly “solving” the problem to assure it’ll no more happen again, as the definition for “corrective action” in the ISO9000 standard. In this way the mindset is the continuous improvement, always pursuing the perfection, doing the PDCA runs very quickly and all the time. Is my understanding correct?

  2. Hello Mario, I think this is a question of wording. At Toyota, improvement almost always starts with a problem to be resolved. This could be for example a defect (clearly a problem), or merely to improve cost (a wider definition of a problem). Generally, for Toyota, a problem is any situation that is not how it should be. The difference to ISO9000 seems to be only wording (although I am neither familiar with nor a fan of ISO 9000)

  3. Interesting! Frankly, I’m out of all this now having retired a few years ago, but what is meant under the PDCA headings seems to vary a lot. Briefly:
    P – involved defining the problem and installing temporary c’measures and mapping out the game plan with 5Ws+1H.
    D – was gathering & analysing data; considering possible cms and planning trials.
    C – was trials & checking
    A – was installing new standard, maiuntenbance procedures and process review.
    A 12-step PDCA was developed at NMUK as the ‘process’ for kaizen teams, and a similar problem solving process adopted. Further afield, Ford used an 8D process, and there were others. All worked if applied as intended, but understanding and application varied, and if permanent countermeasures were not forthcoming it was usually the process rather than the practitioners that was blamed.
    I would say that the number of steps is significant – too few and they become too general and open to (mis)interpretation; too many and people want to take short cuts.

  4. Hi Steve, PDCA is sometimes defined slightly different, but the source of the above is straight from Toyota. But I have also seen the root cause analysis as part of the “do” section.

    As for the 12 steps from NMUK (Nissan Motor UK), my source is from the UK, but from Toyota (TMUK, Deeside), and they teach an 8 step process (1 Clarify the problem; 2 Breakdown the problem; 3 Set a target; 4 Analyse the root cause; 5 Develop countermeasures; 6 See countermeasures through; 7 Monitor the process and results; 8 Standardise successful processes; ) For this post series I found it better to merge step 5 and 6, and hence here you find only 7 steps. The 12 steps seem to be very similar, but a bit finer graded (1. Select theme ; 2. Give reasons ; 3. Set targets ; 4. Plan activity ; 5. Gather data ; 6. Analyse data ; 7. Consider solutions ; 8. Plan trials ; 9. Conduct trials ; 10. Standardise changes ; 11. Review the process ; 12. Further improvement;) Either works. Thanks for the input 🙂

  5. Best re-read “The Toyota Way” pp254 and 255 before p256 and also ISO 9001:2015 Clause 10 “Improvement” and 10.1 “NOTE” on for examples of Improvement and where is fits / is the step as in the Toyoya PPS:
    “Clarify the Problem
    Break Down the Problem
    Set a Target
    Root-Cause Analysis”

    This is true in Toyota as stated above but they use and many others now: use:

    “Concern” (The ‘problem’ with supporting evidence and statistical / graphical analysis to clearly define such “Pareto / Juran” being the most common in Toyota – “The Toyota Way” p255)
    “Containment” (to protect the customer and other stakeholders impacted by the Problem / Concern)
    “Causes (Dr Ishikawa’s 2 types of Basic Causes Analysis for Event Problems and more useful in production, his Type 3 “Process Classification” C&E Diagram – Ishikawa NEVER called his Type A and B Cause Analysis Diagrams the common term of “Fishbone Diagrams”. See his “Guide to QC” ~ 1962 and “Introduction to QC” 1989 books); THEN,
    Finally “Corrective Action” (See ISO 9000:2015 “Action” on page 45.)

    Of course all such problems and causes should have been identified in the PFMEA and as The Toyota Way Book says on p255 “comparing actual situation to the standard”. Otherewise there is no problem without a Standard.

  6. Hello MWMcLean, just grabbed my copy of the Toyota Way, and indeed on pg 256 are quite similar. Differences are that at Toyota 1) they clearly define a prioritized target, 2) root cause analysis is not only 5 why (which i find suitable mostly for smaller problems) and 3) at the end Toyota shares the ideas with other plants/locations. Either works. Not sure where the difference comes from, maybe Toyota evolved the method since 2004 (when the book was printed) to 2023 (when I got the info directly from Toyota).

    Making a sequence with all “C” words (concern, containment…) is interesting, but for me more confusing than the “normal” text. Thanks for sharing!

Leave a Comment

Cookie Consent with Real Cookie Banner