Problem Solving By Design

In his book Managing to Learn, John Shook deconstructs the problem-solving journey of one manager and his mentor, and the management mechanism that guided them. The backstory? Shook knows the journey firsthand.

Reading Time: 11 min 

Topics

Buy
Like what you're reading?
Join our community
Member
Free

5 Free Articles per month, $6.95/article thereafter. Free newsletter.

Subscribe
$89 $44/Year

Unlimited digital content, quaterly magazine, free newsletter, entire archive.

Sign me up

Image courtesy of Toyota.

In 1983, a young American named John Shook went to Japan to work for Toyota. He’d been to Japan before, was a student of lean management principles, and was already attracted to Japanese ideas about process improvement, quality and distributed responsibility. But (he admits this now) he still didn’t know what he was getting into. He was about to encounter The Way.

The leading question

At Toyota, John Shook learned the A3 problem-solving process from the inside. What surprised him?

Findings
  • Almost always, the problem you face is different from the one you thought you were facing.
  • Most of us are so eager to find (and deliver) the solution to a problem that we jump to conclusions instead of truly investigating to the problem’s root.
  • The A3 process provides a framework for learning in the “place where the work occurs.”

Shook was the only Westerner in Toyota City then, and he was initiated and trained like any other fresh arrival — hammered into shape on the forge of something called the A3 report. “Every newly hired college-graduate employee began learning his job by being coached through the A3 process,” Shook recalls. “The employee would arrive at his new desk to find waiting for him a problem, a mentor and a process for learning how to solve that problem. The entire process was structured around PDCA [plan, do, check, act] and captured in the A3.”

“A3,” he discovered, was for starters just the international term for an 11-inch by 17-inch sheet of paper.

But at Toyota it had come to stand for something else: a process, a way of thinking and communicating, a way of learning, a way of getting things done and a way of attempting to create an entire organization of problem solvers. “Toyota’s insight many years ago was that every issue in an organization should be described, analyzed and solved on a single sheet of paper that everyone touching the matter can see,” says Shook.

Specifically, says Shook, the A3:

  • depicts an issue;
  • analyzes the situation and its underlying causes;
  • identifies the required outcome;
  • proposes some corrective actions;
  • prescribes an action plan (who will do what when); and
  • creates a follow-up review process — all in one integrated document.

(In “Toyota’s Secret: the A3 Report”, you can see a sample A3, annotated and explained by Shook.)

Not that any two A3 reports do those things in the same way. Though A3s have prescribed sections and a typical order to them (an A3 is a kind of logically proceeding story, at root), they differ wildly in both look and substance. In that sense, Shook says, an A3 is not unlike a resume — another document which has a commonly understood purpose and predictable content, but which varies infinitely in individual execution.

Shook knows all this because he ended up spending 10 years inside Toyota — he was the first American to become a manager at the company — and because, as he now writes in his superb book Managing to Learn (Lean Enterprise Institute):

I have been learning about the A3 process for 25 years, from the very beginning of my experience in Toyota City.

I was mentored, saw others being mentored, mentored others myself. I debated, coached, cursed, and was cursed at. I came to understand others and caused others to understand me. I learned to get things done, to engage the organization, to garner its resources to effectively get things done. ‘John, you must use the organization. It is there for you. Use the organization as if it were a tool to wield, an instrument to play,’ my boss implored me. I honestly had no idea what he was talking about at first. But he kept coaching, kept imploring, kept mentoring. And, eventually, I began to see.

For a glimpse of what Shook began to see, read his personal account. But as interesting as what Shook began to see is why he began to see it. His enlightenment was the consequence of the A3’s power as a management mechanism — a tool designed to produce a desired outcome not by focusing effort on achieving the outcome but instead by engendering a process that ensures that the outcome will be achieved. Don’t tell someone that their report should be sharply focused and should include only what matters; instead just restrict them to a single sheet of paper to write it on, and the tight focus and high selectivity will begin to take care of themselves.

The A3’s potency as a management mechanism is one reason that it, and Shook’s book, deserve greater attention. (The single-sheet-produces-rigorous-
selectivity effect is only the most obvious of the ways that it does its work.) Another reason is that mechanisms in general are scandalously underutilized by managers. Mechanisms are about process. Great mechanisms are about process brilliantly understood. We still live in a management-by-objective world, even if we don’t call it that anymore. Think MBO is dead? Just recall your last annual review, your last strategic plan, your last budget. Consider how many managers are given a “number” and told to hit it, how many organizations still function by intent and directive — increase sales, grow Web traffic, improve margin.


FIRST PERSON: JOHN SHOOK ON AN A3 JOURNEY OF HIS OWN

As I discovered in my career at Toyota, the essence of lean knowledge is learning through doing. Beginning in 1983, I learned firsthand how the process of producing an A3 report as a means of framing a problem or stating a goal fosters the Toyota way of generating knowledge. Moreover, the process revealed to me how the sequence of steps in the A3 process traces the path of company-wide knowledge generation.

I received a new assignment in 1986 to support the company’s newly announced plans to build a major production facility in Georgetown, Kentucky. First I had to learn to understand, and frame, the problem. The Kentucky Camry plant was a huge project with massive requirements on many levels. One of my responsibilities was to design and oversee a process to get the thousands of pages of Japanese technical documentation translated into English. I set about by preparing an A3. (See “Toyota’s Secret: the A3 Report,” an A3 example loosely based on Shook’s document translation challenge.)

In order to clearly understand the theme, or desired outcome, I first needed to investigate the lay of the land. How much documentation could we expect to have? What did it look like, how complex, how difficult to translate? What process was already in place for work like this? This line of questioning took me to the people who had done the same work on the only comparable previous experience Toyota had had, NUMMI (New United Motor Manufacturing, Inc., Toyota’s joint venture with General Motors in Fremont, California).

At this point, my boss, K. Kunieda, asked me how I wanted to handle it. My first suggestion was merely to approach the problem the same way as NUMMI: After all, why reinvent the wheel? Rather than correct me, he asked for my evaluation of the way the documentation translation process for NUMMI had been handled. This type of inquiry required me to investigate to more fully understand what process had been used previously, the thinking behind it, and to evaluate it according to some defined criteria. His actions made clear that my first task was to go see, and ask why.

What I found was that there had been many problems with the document translation work on the NUMMI project: overall inconsistency, poor quality, unpredictable timing , and confusion due to multiple vendors. This helped me see that I needed to design a process that addressed these issues.

I proposed that we send all the documentation to one translation vendor. But upon further investigation, I learned that the vendor with the highest quality also had the longest lead time, as well as the highest cost. Moreover, not everyone thought the quality of work was necessarily higher, since some Toyota factory people considered the firm difficult to work with. It became clear to me that I needed to add another evaluation criterion, “easy to work with,” considering the factory side as another customer; and I would have to address the inconsistent quality and poor delivery timing issues. This required understanding the entire document translation process itself, from beginning to end.

And so I went to the translators with my concerns, which I wanted them to fix by just doing a better job. Their reaction was to inform me — with considerable irritation — of the many problems they had experienced on their side. Many of the documents they received from the factory were virtually illegible. They often spent more time formatting documents than doing the actual translation of words from Japanese to English. The documents they received always had many drawings and charts, which were daunting to translate and recreate faithfully.

So I went back to my boss Mr. Kunieda with the additional proposal that we had to do a better job of standardizing our process of getting the documentation to the translators. He seemed to understand and even to agree. But he also asked me why was it that sometimes the translators had no difficulties with any of these issues. Why was it that sometimes they could complete the translation on time and with excellent quality? My first thought was simply that, naturally, some translators are better than others. But, this time, before jumping to a conclusion, I decided to go back to see exactly how the process worked.

While I didn’t realize it at the time, Mr. Kunieda was pushing me to keep asking why the current state existed until I arrived at the root cause of the problem. I found that not only were there different “levels” of translating skill among the translators, there were also different types of translators. Some were skilled at understanding technical language, while others were more skilled at nuances of Japanese-American translations, and so on.

Therefore I suggested a viable alternative to the current state, one that directly addressed the causes of the problems. What if the translation process went through three steps, each performed by a translator with the appropriate skill?

Mr. Kunieda liked the idea, but asked how I knew it would work. We would have to test our hypothesis in action. While it sounded good in principle, it also involved its own brand of complexity. Indeed, on our trial samples, the hand-offs didn’t go as smoothly as we hoped. As a result we introduced a timing chart to show where each document was in the process, highlighting any document that was stuck somewhere in the flow.

Yet simply implementing improvements was not the end of the process. We had to share what we had learned among the team. I was asked to design a management review process to ensure everything was working smoothly from the point of view of each person at each step through the process. This was accomplished by ensuring that people at each step along the way knew the preceding and following process and had instant, continual feedback regarding timing and quality.

All this was captured in the form of an A3 that was used as the collaborative tool to compile feedback prior to implementation and attain consensus among everyone involved. The system design was transparent and took into account everyone’s concerns. While my job was to design the job itself, the ultimate goal was to eliminate the work altogether: My job was to eliminate my job!

— John Shook


Not that objectives are valueless; they’re good for pointing an organization or individual in one direction rather than another. But they don’t go very far toward enabling progress in that direction. They’re about results — and they house no hint of curiosity about how the result will be achieved. They don’t help solve problems, or conceive plans, or improve how an organization works.

The A3 does all those things. As you’ll see in our “Toyota’s Secret” feature, or the sidebar to this article, or Managing to Learn, the A3 is as much a method as a report. An A3 requires its author to gather and report facts, to seek and account for feedback, to identify the owners of each piece of work and to construct a clear follow-up loop before any work begins. It is almost limitlessly iterative. And most of all, Shook says, it forces all learning to be based not in abstract study but in the “place where the work occurs.”

He states: “Improvement and reflection are rooted in the nuts and bolts of shop or office front lines. Sharing and discussing the report leads to effective countermeasures and solutions that are based on facts and data. Individuals learn through doing.”

And what do they learn most frequently when tackling a problem-solving A3 (there are also proposal A3s and planning A3s)?

“They learn that what they first thought the problem was, turns out not to be the problem,” says Shook. Usually they make that discovery because of how relentlessly the A3 process drives the author toward identifying root causes through investigation and listening to others. “Completing and then discussing the material in an A3,” Shook writes in Managing to Learn, “forces individuals to observe reality, present facts, propose working countermeasures designed to achieve the stated goal, gain agreement and follow up with a process of checking and adjusting for actual results.

As a result, the A3 represents a powerful tool for problem-solving, making improvements and getting things done.”

Or, as Shook says separately, because A3s make the key elements of a plan visible and understandable to everyone, they “become the common currency through which managers discuss how to get from a current state to a future one.”

And they become the mechanism that spreads responsibility for getting there to everyone.

Topics

Reprint #:

50401

More Like This

Add a comment

You must to post a comment.

First time here? Sign up for a free account: Comment on articles and get access to many more articles.

Comments (3)
The Way - Tagplus
[…] https://sloanreview.mit.edu/article/problem-solving-by-design/ […]
ak0793
Useful info, 'process improvement' here displayed possibility for both products/services type industry.. hope to get a hand on the book and get to know all about how to develop an action plan that is more tangible :)
davidjung
Wow...so simple, that it blows my mind.  I loved the line:  "Great mechanisms are about process brilliantly understood."  I think that sums it up best.