The real secret to success with the A3 process: No standard, no problem? Actually, it is a big problem
Part three of a seven-part series, “The real secret to success with the A3 process”. Learn how the A3 process goes beyond problem solving and the other facets of the practice you must understand. Read the previous articles: part one - It is as much a social process as a technical problem-solving process and part 2 - PDCA is actually CA-PDCA – and it is the CA that makes the PD work.
One of the biggest barriers to A3 problem solving in many North American companies is that there are usually few or no performance measures and standards at the process level. Most companies have KPIs (key performance indicators), but they are generally operational results or end-of-process measures. They are also “lagging indicators,” because they show the outcome of the work performed, but not how smoothly and efficiently the work is flowing through the process – unless they fail to hit the output KPIs. Without process or work standards, those who carry out the process have no way of assessing their performance or knowing where to focus problem solving when there are problems with production results.
The situation at Toyota, where the A3 process originated, is quite different. They have a saying: “No standard; no problem,” which for them is true. If there is a point where the company needs to measure performance in order to manage or improve it, they have standards for what should be happening. They have performance measures that start at the individual operation level, including defined processes and procedures. And there is tracking based on these standards that runs from the team up through the group, area, department, operation and company levels. In manufacturing operations, for example, digital signs display the number of vehicles produced compared to plan at any point during a shift.
Having no standard may not be a problem for Toyota, because they have created or will create performance standards and work standards wherever they need them. But for many of the companies I have worked with, that is not the case – it is a problem, a big problem. Without a standard, there is no way to see what improvements need to be made to improve performance or to see the impact of the changes that have been made. It is hard to improve on a foundation of chaos. You can make changes, but amid the confusion, disorder and instability, how can you know whether you are heading in the right direction? How can you know whether you are making a difference in a chaotic, unstable situation?


In situations where there is a performance goal or standard that is not being met, a problem-solving A3 is used to close the gap. In situations where a problem or need is recognized but there is no performance goal or standard, a proposal A3 is used to define one.
An improvement in an unstable situation is like a drop in the ocean. It makes a splash, but it disappears very quickly. The fundamental principle of lean thinking, continuous improvement and performance improvement that I have learned over the years is to first stabilize as best you can, standardize as much as possible, and then work on improving.
Recently, I saw an example of the confusion caused by unclear standards while I was coaching an engineering manager. He was the leader of a large new product development project for a customer. He was frustrated with his engineers over the handling of engineering changes. After the product design had been set in the original plan, the engineers learned some things while developing it that made changes necessary. The problem, for the manager, was that the design engineers were often late in submitting these changes to the customer. And late changes meant penalties for his company.
The contract specified the point in the schedule by which engineering changes had to be submitted to the customer. When changes were not approved in time, the original cost applied, and the manufacturer had to absorb the difference, which was usually larger. The engineering manager reminded his engineers about this frequently and could not understand why the changes were so often late. I suggested that we follow the process and talk to the engineers to find out what was happening.
We started at the end of the process, where the engineers submitted the changes to a team that coordinated the master schedule and sent them on to the customer company. We learned from the person responsible for forwarding the changes that more than 50% were late, which created extra work for her. I asked about the work process, and she said the engineers have many different responsibilities on the project, and they all know this is one of the things they are supposed to do.
I suggested we talk to the engineers. We found that most of the engineers in charge of making engineering changes were young, relatively inexperienced and new to the company. They had not been trained or given guidance on how to make engineering changes. More importantly, they needed information on the costs of the changes but lacked the experience to calculate them. And they had not been told where they could get this information from the estimating department. Many of them said they were afraid of getting the estimates wrong. That is why they were usually slow to submit change requests.
In lean, we talk about the importance of standards and how they are needed to clarify problems and manage performance. And we usually think of standards as goals, objectives and KPIs. But processes, procedures and a defined workflow are also standards; they are work standards. Toyota's standardized work is a well-defined example. If you set goals and do not give people a well-defined path they can follow to achieve those results, you are not enabling them to deliver the performance you want. You do not have a goal or a standard. You are just hoping they will get the results through their own effort.
The engineering manager realized that he was responsible for developing the processes he wanted his people to follow and for training them to make sure they knew how to use them.
Reaching agreement on a standard
Fundamentally, a standard is a statement that says we agree on how things should be (or how we need them to be) in a performance situation. It specifies what is expected in a given work situation. But a standard is not effective as an expectation that will guide behavior unless it is agreed upon, documented and communicated. Whenever possible, agreement on a standard or goal should be reached with those who must meet it.
I saw an example of this in a Human Resources department where I was a consultant. I was asked to coach a newly hired HR specialist who was struggling with his first major project. He was supposed to deliver training to supervisors on a revised policy they were to implement, and attendance was very low.
Although relatively new to the company, he was responsible for updating an important employee benefits policy and teaching managers and supervisors how to play their role in carrying out the policy. This young specialist was brilliant and had done solid research on the policy changes required by recent legislation. He had also created an effective program to inform leaders about the changes and show them how to help employees who qualify for the benefits. He had even done his first A3 and laid out a plan to implement the training. He walked me through the left side of the A3, and I understood what he was trying to accomplish.
When he described the right side of his plan, I asked whether everyone agreed with the schedule that had been set there. His answer was yes, that his manager and the vice president had approved it. I asked whether the management of the supervisors who needed to attend the training (mainly the production managers) had also agreed to the plan. He said yes, he was sure they had. That raised some doubt in my mind. I looked at the training schedule and went over it with him. I noted that he had enough sessions to cover all the supervisors. And in the “Responsible” column, he had listed the managers from the other department as responsible along with himself.
I asked how he had gotten their support given the preparations for the new model launch that were happening at the same time. He replied that he was sure they would do their part and support the training. It is their responsibility, he said. My question was whether he had agreed on the training schedule with them. Well, not directly, he said. The executive committee had approved the training.
I asked whether they had seen the schedule, and he said no; it was not ready when they reviewed the policy. So I asked how he planned to get the managers' support to improve attendance, now that he was running the training and getting few participants.
The answer was two or three minutes of silence. Then he told me he had sent an e-mail a month before the sessions began saying that the training was mandatory and that it was their responsibility to make sure their people attended. He added that he would remind them that the law requires them to complete the training and that the executives had approved it.
I suggested that he needed to test the idea that they had really agreed to the schedule. I asked him to go to each department head or manager he had listed as responsible, who led people who needed to attend, with an updated plan with additional sessions. I asked him to have them sign the responsibility column to indicate that the leaders would support it by scheduling their people's attendance.
I did not hear from him for about three weeks. I hoped he was out in the plant talking with people and learning two things: first, you cannot simply leave responsibility to other people. You must make sure it works for their situation and priorities so that they can commit to it. And second, you have to understand the broader context of what else is going on in the company when you ask for agreement on a plan.
There is a Japanese term, nemawashi, which translates as “preparing the ground for planting.” Nemawashi is a standard practice at Toyota for building a foundation of agreement on the purpose, process, plan and responsibility in order to gain support for an improvement initiative, project or A3 problem solving. The following week, the HR specialist told me he had reached agreement with the managers on a revised schedule that would start after the model changeover.
The A3 is not just a tool for reporting problem-solving activities, seeking approval of countermeasures and executing a plan. At Toyota, it is part of the process for leading change and meeting the needs of the operation and the business. It is a tool for documenting what is learned about how to improve performance and for gaining agreement and support for the necessary changes.
The A3 process is a technical problem-solving process based on the Plan-Do-Check-Adjust cycle. It is also a social process of engaging and listening to people and incorporating their knowledge and thinking into the development of a change plan. The key to the whole process is that, through it, the change leader gains agreement and support, because it reflects the best options, methods and timing available for everyone's situation.
The A3 process works because Toyota trains its leaders to use it, and everyone knows that this is how problems are handled and improvements are made for the good of the business. In other words, it is Toyota's standard work for solving problems, initiating improvements and leading change.