So what actually constitutes one PDCA cycle in real life? Consider the process of getting up and going to work, and a target condition of being in the car and ready to drive to work 60 minutes after waking up. Here is one possible PDCA cycle for that process:
- Plan: Be in the car 60 minutes after waking up. (Target condition)
- Do: Wake up and go through the morning routine, get into car.
- Check: Once in the car check how long it took.
- Act: (Next step to be determined)
As we sit in the car and check how long the morning routine took, we find that the total time was 64 minutes, or four minutes over the target condition. What have we learned about the process from this experiment? As depicted in Figure 6-10, not much! The total time taken was over 60 minutes (too long), but we cannot tell where in the morning routine the problem lies. Furthermore, it is too late to make an adjustment that would allow us to still achieve the target condition. When I use this waking up and going to work example as a classroom exercise, participants invariably begin making improvement suggestions right away, such as setting the alarm clock four minutes
Figure 6-10. Only checking outcomes produces little learning
earlier or taking less time to shower, even though they have no further information about the problem. The urge to go directly to proposing and implementing countermeasures is surprisingly strong in us, and is fostered by our prevailing outcomeor results-based managerial system.
There are two things wrong with this PDCA experiment: (1) The “check” comes too late for us to learn anything useful about the process, or to make adjustments on the way. (2) The target condition specifies only an outcome, which means that it is not actually a target condition at all.
History shows that many seemingly large and sudden changes developed slowly. The problem is that we either fail to notice the little shifts taking place along the way or we do not take them seriously. In contrast, Toyota states clearly that no problem is too small for a response. For an organization to be consciously adaptive, it would ideally recognize abnormalities and changes as they arise and are still small and easy to grasp.
Consider, for example, the dieting quote, “I got fat slowly, then suddenly.” If you are gaining unwanted weight and notice it when you’re one pound overweight, you can see the causes, correct easily, and hit your target. On the other hand, if you only notice the gain, or take it seriously, after 15 pounds, then the situation is much more difficult.
Turning back to the getting-up-and-going-to-work process: to be able to experiment in shorter cycles, we need a more detailed target condition. A target condition generally includes the following information:
- The steps of the process, their sequence and their times
- Process characteristics
- Process metrics
- Outcome metrics
Ensuring that there are both process metrics and outcome metrics allows Toyota to have shorter and finer PDCA cycles (Figure 6-11). There is a longer overall cycle that checks the outcome, and, more important, many short PDCA cycles that check process metrics along the way. If that sounds too complicated, it simply means this: every step on the staircase toward a target condition is a PDCA cycle (Figure 6-12). Each step is a hypothesis, and what we learn from testing that hypothesis may influence the next step.
Figure 6-11. Outcome metrics and process metrics
Figure 6-12. Every step = a PDCA cycle
With the shorter PDCA cycles that check process metrics, we have now reached the level in an organization—the fractal—at which continuous improvement, problem solving, and adaptation can be done effectively. For example, natural selection may favor one family of birds over another, but this is played out at the detail level, such as the length of their beaks or other attributes. We can have a vision of ending hunger, but achieving that will involve details like trucks having gasoline, roads being passable, and so on. We may want to develop and offer an electric automobile, but it is at the detail level that this desired condition will or won’t be achieved.
Interestingly, the detail level is something that many popular management concepts—such as management by objectives as we practice it, employee motivation schemes, and so on—do not reach. This may explain some of the difference in the improvement and adaptiveness performance of Toyota versus its competitors.
Of course, to work this way you will have to define in advance the expected result of any step. This then puts you in a position to recognize abnormalities early and make the necessary adaptations and improvements on the way to a desired condition.
Figure 6-13. Experiment setup for the getting-up-and-going-to-work process, including steps, sequence, process metrics (step times), and an outcome metric
Let us put together a more effective experiment for the process of getting up and going to work, beginning with a better target condition that looks like the chart in Figure 6-13.
Now we have set ourselves up to make checks and learn and adapt along the way. As you can see in Figure 6-14, the step “Make breakfast” has taken four minutes longer than the planned time. Now we not only know where the problem is, but we can also make adjustments to the remaining steps to allow us to still achieve the 60-minute outcome.
Compare this approach to the first experiment, which only checked the outcome. Adding process metrics and short PDCA cycles is like putting on a pair of glasses and seeing clearly for the first time. It is no wonder that process operators sometimes get annoyed when managers visit a process for a short time, create performance incentives, drop some random suggestions for eliminating waste, and then head back to their offices.
Figure 6-14. A clearer view of what is happening
In the getting-up-and-going-to-work example, we are still not yet ready to introduce a countermeasure, because we do not yet know what it is about making breakfast that caused the problem. The next step would be to pay close attention to the current breakfast-making routine and ask, “What is preventing us from making breakfast in seven minutes?”
Consider a manufacturing example. Say a process target condition includes producing 32 boxes of product over two shifts. If we check the outcome at the end of each shift and find a shortfall, we will have difficulty tracing and understanding the cause. A variety of small problems will have occurred during the shift (think of those 1,000 andon pulls per shift at a Toyota assembly plant), and the context that caused those problems is gone. We are not adaptive and also have few options now to make up for the shortfall in time for delivery to the customer.
On the other hand, each box or associated kanban card represents 30 minutes of production time and can be used as a process metric—an early warning indicator (Figure 6-15). We can check every 30 minutes, and if there is a shortfall on one of those checks, the root cause trail is still hot and we can still make up for the shortfall.
Figure 6-15. Kanban cards can be process metrics
This is an interesting contrast to how we work in our factories. In many cases we instruct the operators to call for a logistics pickup when a pallet of boxes is finished. Not only is this too infrequent for effective PDCA, but the logistics person comes by when the boxes are actually ready rather than when they are supposed to be ready. In this setup there is no experiment whatsoever. Why do we work this way? What are our assumptions? How do these assumptions differ from Toyota’s assumptions?
If we want to check in short increments and utilize the information, then support personnel must be able to respond appropriately. For example, many of our factories have whiteboards for checking hourly production at their processes, which look exactly the same as such boards in a Toyota factory. But in many of our factories the comments written on these boards are used more to justify why a target production quantity was not reached, rather than to trigger quick response during the shift. A good example of copying a technique rather than the thinking behind it.
The right heart. Frequent process checking is sometimes inter- preted as a means for policing people to keep them working hard (Figure 6-16). Ironically, this would create an artificial situation that obscures the true condition and inhibits our ability to improve. For example, if people tighten up and alter their behav- ior when the leader approaches, then the leader loses sight of the true condition. To improve in the Toyota style we will need to adopt the right heart: we are checking for problems because we want to find the problems.
Figure 6-16. How you think will affect how people react
Since it is the refuted hypotheses—the problems, abnormalities, and unexpected results—that show us the way forward, Toyota is highly interested in seeing the next problem or obstacle as soon as possible. Since we can only see the next obstacle when we take a step (one PDCA cycle), we should take that step as soon as possible.
As mentioned in Chapter 2, at Toyota you are generally taught to strive for single-factor experiments, that is, to address one problem at a time and only change one thing at a time at a process. This helps us see cause and effect and better understand the process. But this would be too slow if each cycle takes a long time.
Figure 6-17. Experimenting in rapid cycles
For these reasons, individual PDCA cycles are turned as quickly as possible, sometimes even taking only minutes for one cycle, along the lines articulated in Figure 6-17.
The desire to turn rapid PDCA cycles has an influence on the nature of the steps that we take toward a target condition. The idea is to not wait until you have a perfect solution, but to take the step now, with whatever you have, so we can see further (Figure 6-18). A provisional step now is preferable to a perfect step later, and investing in prototypes and experiments up front, which may seem like extra expense, often reduces overall cost in the long run.
One example is from the factory in Germany, mentioned in Chapter 5, where part of the target condition for the assembly process was a planned cycle time of 16 seconds. The pair of observers timed 20 successive cycles asked themselves, “What is preventing us from having a part come by this point every 16 seconds?” They noticed that the operator had to periodically walk away from the line to get trays of parts, which caused instability in the line cycle time.
The next step proposed by the two observers was to develop a better logistics concept, whereby the parts would be brought to the operator. But how long will it take before this can be done? If we wait
Figure 6-18. Do it now, with whatever you have on hand
until the material handling department develops cyclical material routes with point-of-use delivery, that will take weeks, at least, during which time we would not eliminate this variable (Figure 6-19). Make a logistics concept and plan, okay, but don’t wait for that to be completed. If possible, make the change right now in a temporary fashion, so you can then see the next problem and keep moving forward.
Figure 6-19. Don’t wait to take a step
Another example comes from a factory that makes hydraulic cylinders for a nearby customer factory that assembles earth-moving equipment. Finished hydraulic cylinders come in a variety of sizes and are packed on pallets by size, one size per pallet. Each pallet has a special fixture to securely hold several cylinders, but only of one size. Therefore, the minimum shipping quantity for each cylinder size is a one pallet quantity. The customer, however, only requires two cylinders of any size at a time, and thus has an aging inventory of several opened pallets of cylinders in its receiving area.
A proposal for the next target condition closer to a 1×1 flow between the two factories was to ship only pairs of cylinders the customer actually needed. This would require a different fixture, so that several pairs of different size cylinders could be packed on one pallet. However, such a fixture would have to be designed and built, which would take several weeks.
In the Toyota way of thinking, this delay is not acceptable, and a provisional fixture solution—even if it temporarily adds some waste— would be introduced as quickly as possible. Not only can Toyota then see the next obstacles to achieving a 1×1 flow between the factories, but the fixture idea can be fine-tuned before expensive fixtures are fabricated. Perhaps even smarter solutions will be developed and fancy fixtures will not be needed after all.
Many years ago I learned the hard way the benefits of fine-tuning a provisional step rather than going right into full implementation. At a large automobile supplier factory, we had designed a new assembly process and needed some flow racks for parts presentation at the line. When I showed the maintenance department—which fabricates such things in this plant—our sketches of the racks, I was told building them would take three weeks. However, since our project had some priority, the maintenance department agreed to fabricate the racks over the weekend as a favor.
Monday morning our racks were there exactly as we had specified them. They were made out of angle iron, with some of the finest welds I have seen, and nicely painted the same blue color as other equipment in the plant. Once we had the racks at the line, we started
our production trials. Of course, the trials led to many little adjustments in the line, which included shifting some work elements from one operator to another. This meant that the associated parts would now have to be moved to a different flow rack. We also found the need for adjustments to the flow racks as we moved things around, changed reach heights, and so on.
Imagine the good cheer with which I was greeted at the maintenance department when I now brought back the beautiful, weekendmade flow racks for some changes. This time it did take three weeks. Clearly, we should have started with some provisional racks, even though up front that seemed like extra time and expense, and worked up to something more fancy if necessary when the situation stabilized. Again, we often leap ahead with too much faith in our planning, and thereby fail to leave room for learning and adaptiveness.
Keeping an Open Mind
The next step may not be what you expect, so you need to be as openminded and scientific as possible as you go through PDCA cycles. It is difficult to not be biased in looking at a situation, and it is probably a lifetime’s effort to teach oneself to view occurrences without preconceived notions about those occurrences.
We have misunderstood why Toyota is more successful than other organizations in achieving the challenges (target conditions) it sets for itself. It is not primarily because Toyota people have greater discipline to stick with a plan or experience fewer problems, as is often thought. Rather, they spot problems at the process level much earlier, when the problems are still small and you can understand them and do something about them. Toyota’s success is not due to sudden innovation or having airtight plans, but about the ability to execute more effectively in the face of unforeseeable obstacles and difficulties.
In contrast, we find out late that a plan has failed (although frequently this is not even admitted). Information about the little problems along the way was never picked up and acted upon. What do we then assume is the cause of the plan failing? Poor planning, poor discipline in execution, and human error.
What do we think is the solution? Make a new plan. Plan better. More discipline in implementation. More countermeasures. Motivate people to be more careful or work harder. We may apportion blame, to increase pressure on people to be more careful, or even replace people. Unfortunately, none of this addresses the actual causes of the plan failing. I once heard a colleague summarize our approach as: “It’s always ‘no problem’ until the end, and then we have a big problem.”
While taking problems at face value is a basis for Toyota-style continuous improvement and adaptation, inside many other companies I find way too much of either sweeping little problems under the rug or placing blame, both of which inhibit the ability to see reality and adapt to actual conditions. When you combine hiding problems with the popular idea of trying to manage from afar via targets and managerial accounting metrics, it means that even less accurate information gets through to managers, who thereby either fail to lead in the making of appropriate adjustments—small course corrections—or try to do it too late.
A lot has been said and written about learning organizations. With the way it applies PDCA, Toyota has developed a learning organization in a pragmatic way.
- What is the target condition? (The challenge)
- What is the actual condition now?
- What obstacles are now preventing you from reaching the target condition?
- Which one are you addressing now?
- What is your next step? (Start of next PDCA cycle)
- When can we go and see what we have learned from taking that step?
Figure 6-21. The five questions
The Five Questions
The five questions in Figure 6-21 are a summary of Toyota’s approach for moving toward a target condition, and are perhaps the most useful information in this book, now that you know what they mean. They are highly effective in practice.
The five questions come into play once you are “on the staircase,” that is, in the PDCA phase of the improvement kata, after a target condition has been established. The questions build upon one another. The better you’ve defined the target condition, the better you’ll be able to assess the current condition. The better you assess the current condition, the better you can recognize obstacles. The better you recognize obstacles, the better you can define your next step. Note that before a target condition has been established, the order of questions 1 and 2 is reversed from what is shown here.
This sequence of five questions is a device to give you a routine and mental pattern for approaching any process or situation, and to help you learn the improvement kata. The questions distill part of the improvement kata down to a point where it becomes accessible and usable by anyone. They are a “minikata,” if you will, perfect for practicing. I keep the five questions in mind any time I visit a process, and apply them to many other activities as well. I highly recommend that you use and internalize them.
What Toyota Emphasizes in Problem Solving
Despite what the words “problem solving” might lead us to think, the primary focus in problem solving at Toyota is not solutions, but understanding the current situation in a work system so deeply, firsthand, that the right solution (called a countermeasure) becomes obvious and practically falls in your lap. Most of the effort of problem solving at Toyota is placed in grasping the situation—deeply understanding the conditions that led to the problem—as opposed to hunting for solutions.
We often mistakenly think that good problem solving means solving the problem, that is, applying countermeasures, and we may even propose and apply several countermeasures in the hope that one of them will stop the problem. In contrast, in Toyota’s way of thinking if the solution to a problem is not yet obvious, it means we have not yet understood the situation sufficiently. Time to go and see again (Figure 6-22). An example: A factory that makes precision-cast turbine blades for aircraft engines was experiencing a quality problem. One of the last processes in the turbine-blade value stream is a spray-coating line, much like a paint line, and some blades were coming out of the coating process with dents from banging against one another. Due to the damage, these expensive parts would have to be scrapped. Engineers quickly put forth a number of potential countermeasures, such as hanging the blades farther apart on the coating line chain conveyor, putting a protective shield between each blade, and so on.
Figure 6-22. What does “problem solving” mean?
One engineer took a different approach and simply observed the coating process in action. After about three hours of watching he noticed something at a point in the process where the chain conveyor makes a 90degree turn. As the turbine blades went around this corner, some of them would rotate counterclockwise a little and slightly unscrew the hook upon which they were hanging. When the hook became unscrewed far enough, it allowed the blade to swing and on occasion contact the neighboring blade. Once the engineer understood the problem, then the right countermeasure became obvious: prevent the hooks from unscrewing.
Few of us actually take the time to keep observing a process until the cause of a problem becomes clear. We tend instead to reward firefighters and expediters who temporarily fix a problem. We will explore Toyota’s thinking about problem solving in more detail in a case example in Chapter 8.
It Keeps Going
Once you begin working with the improvement kata at a process, there is no end (Figure 6-23). If the target condition is achieved with some consistency day in and day out, it may be time to develop the next target condition for this process. Without a target condition (challenge) to strive for, a process will tend to slip back.
Figure 6-23. Reaching one target condition sets the stage for the next target condition
This is the time to make an overall reflection, to summarize what was learned in this complete improvement kata cycle in preparation for the next. While you are working to achieve the current target condition, you will usually begin to see elements of what should be the next target condition. If not, then you’re probably not struggling enough with process details.
You may not arrive at a target condition 100 percent. For example, it is unlikely that a production process can ever be 100 percent stable. At production processes you may reach a state where you are just reacting to deviations and abnormalities, rather than still striving to reach a challenging target condition. A question I sometimes ask myself is: “Are we still working under a challenge here?” If not, then it may be time to define the next target condition.
Occasionally you will not achieve a target condition on time, but this is sometimes acceptable. Why? Because we learn the most from failures.
For a few years I chaired a manufacturing conference in Munich, and one year several speakers, in presenting improvements they had made, ended their presentations with a photograph of the award—a trophy or plaque—they had won. After this happened a few times in a row, I felt compelled to point out that sure, Toyota too would show its awards, but this would not be the last slide in its presentation.
Toyota’s last slide would describe the next challenge. It is okay to celebrate successes, but we should always be looking ahead and focusing on a target condition and the next step. If we decide to use awards, then they should not be seen as an end, but rather as a beginning, a doorway to more learning.
The benchmark to beat is yourself and your current condition.