A3 Dojo: Share and Discuss A3s with Other Lean Thinkers

For all the coaching we provide about the value of A3s and their underlying thinking, we recognize that actually following this approach is hard work. And not simply because developing these habits can be counterintuitive at times; but because so many human roadblocks litter the path of lean. There are all too many reasons why the A3 process can be thwarted; and we’ve heard most of them. So, in the spirit of teeing up these problems by first trying to understand them better, here are some challenges you might be facing. What others can you suggest?

CHICKEN is to EGG as A3 PROCESS is to MENTOR?

Sorry for the flashback to your standardized testing days.  But this is a common challenge to getting started. In fact, every time I teach a group about A3’s I am shocked if I do not hear,  “I shouldn’t be learning about this alone, my boss should be with me. I need a mentor to coach me.” You cannot gain traction without the support of your leader—and yet your leader may not be buying in without seeing how this approach can work for you. Unfortunately, no matter your position in an organization you could apply that line of logic, and soon we have the CEO saying, “I need my board of directors to attend an A3 workshop with me!”  It can become a classic chicken-or-the-egg dilemma. 

In a situation like this the best way to start is simply…to start. I would suggest you employ a classic lean method – TRY – by running an experiment.  You can choose to be either the mentor or the student, but pick a role and try. And then try again. Now let’s explore one approach a little more closely.

THE ODDLY BEHAVING MANAGER:

Picture this scene. Jim, an employee of four years, is sitting in his office when his boss Deborah walks in. Deborah explains that they are having issues in developing their monthly financial forecasts for corporate, on time, and she would like Jim to take the lead in solving this problem.  As Jim is asking a few clarification questions Deborah pulls out a blank 11 x 17 paper and writes the words, “THEME, BACKGROUND, CURRENT SITUATION, and TARGET” spaced out along the left-hand side.  She then explains to Jim what is meant by each section and asks him to document his thinking in this flow. By the way, she adds, before beginning to analyze the situation, “can you fill in these sections so we can discuss your findings before you proceed?”  And so we encounter another A3 implementation paradox. What might be running through Jim’s mind at this point?  Perhaps, “why do you want to see my THINKING?” “you usually ask me for answers, why the change?  Did I do something wrong?” “Don’t you trust me?”  As the process unfolds and Deborah begins to ask questions at every stage of Jim’s project (in an effort to mentor him!!!), Jim is now wondering, “why so many questions?”

The moral of the story is, if you choose to introduce A3’s into your organization, then you must be willing to play the role of the mentor. And when you do, take the time to briefly explain the process to your subordinates.  It would be great if you could give them the same A3 education you received, but we often can’t afford to send EVERYONE to training.  Use a staff meeting to explain the concept.  You could even tap into John Shook’s webinar for his book, “Managing to Learn.” http://www.lean.org/Events/WebinarHome.cfm   

Once the employees in your organization understand the basics of the process then give it a try.  Provide each person with a problem to resolve and have them utilize the A3 process, with your mentoring, to get agreement in the organization and implement an appropriate countermeasure.  Establish an A3 beachhead in you department.  As you utilize the process, take time to reflect on what is working, what isn’t and why.  Ask your employees for feedback on your effectiveness as a mentor.  Ask them if you are asking the right questions at the right time or are you providing “the answer?”  As you successfully engage others beyond your department, the concept WILL spread.  Trust me.

What do you think?

What other ways have you found that A3s fall down in your organization?

What did you do about it?

Tracey’s last column, “A3: tool vs. process? Both”, really struck a chord with me, and got me thinking (great job Tracey!!!). I would like to share a story that illustrates this point.

“Eric, remember, the tools are not the purpose.”

These words still echo in my head. It was one of those personal epiphany days when many things became much clearer. There I was standing, Yamada-san staring back with one of his all-to-rare smiles.  I was an industrial engineer by degree with many years of experience in multiple functions under my belt. We had been though many “phases” of continuous improvement with quality circles in the early 80’s, JIT for America!! in the late 80’s, and synchronous manufacturing with kaizen events in the early 90’s.  This was now the late 90’s and we were attempting to take our continuous improvement to the next level.

I had been blessed with the opportunity to work with many good senseis (teachers), and this one in particular reset my views on continuous improvement. Up to that moment I had been laser focused on understanding the next tool and applying it. Better yet I was looking for a series of steps, a checklist, to organize the tools within.  Armed with the latest knowledge in tools and a checklist of steps I developed through experience, I thought I could walk into any area and solve any problem.  Better yet, I could leave that knowledge and checklist behind allowing the area to continue to solve problems themselves. 

But I was frustrated.  Our initiatives were not succeeding.  We were often late in implementation, were not seeing the results we expected, and continually ran over budget. Don’t even ask about how well we sustained our gains. With our new sensei, there was a glimmer of hope. We had just made a successful transformation of one of our assembly lines, on time, within budget, and; with reduced manufacturing costs significantly at a time when this was critical to our business. “One line down, nine to go”, I thought. I was ready to push forward with our next line with my tool/checklist mentality.

This is when my sensei stopped me. The next line was different. Not on the surface, but when you closely observed, it was very different. Different product mix; different skill sets; different customers; different critical features – and the list could go on. I can’t explain why “the tools are not the purpose” resonated so much that day, but a light came on.

I realized that tools ARE absolutely essential – but don’t make them your goal, your purpose. When tools become your purpose you often implement countermeasures that do not address the root cause of your issue. You forget that from problem to problem or project to project, many things change. What doesn’t change is the need to be successful (on time, within budget, impact the business, sustain results). And the need to rely on others in all phases of your project understanding, analysis, recommendation, implementation and sustainment. The A3 as a process will help you achieve all of this. My sensei was essentially telling me to FIRST step back and really understand the situation. Observe the process. What was really happening? What was the REAL problem? Creating a new line layout was not the purpose. There needed to be a benefit, a problem addressed. “Kaizen is not a hobby” is another phrase he used on me many times.

You may be asking, “how does this relate to me?”  I think that Tracey’s fundamental point can’t be stressed enough: BOTH tools and process are essential. The tools are indeed useful and powerful—but they are a means to an end. That’s why coaches like me and Tracey and David spend so much time on this board urging you to, using whatever tools you have, grasp the situation BEFORE getting into deep analysis.  And keep posting your questions – they are great!  But don’t be surprised if we keep pressing you for more understanding on the current situation before we get into a tools discussion.  Remember the Charles Kettering quote, “A problem well stated is a problem half solved.”  So lets get to the gemba, observe and grasp the situation. 

Several recent posts in the dojo have raised the important question of whether the A3 is a tool, or a process. I’d like to answer this question by saying…the A3 is both.

Having said that, I will add that individuals in organizations that are practicing A3 thinking need to understand the difference between the A3 as the tool, and the A3 as the process. These are separate and distinct things. They must be willing to explore why this activity pays off. Unfortunately, many organizations only see the “tool” side—focusing only on the piece of paper and not the thinking behind it—resulting in short term gains and a “flavor of the month” mentality.

In Managing to Learn, John Shook calls an A3 report a visual manifestation of our/your thinking. As a container for this process, consider the piece of paper with the various size boxes as a blank canvas to capture your work. And your work is done by engaging people at the gemba. I see too many organizations getting hung up on using a specific template, or requiring finished A3s to be so similar that the individuals doing the work are drilled into thinking about the template as a tool, and not the thinking behind it. Learning to follow this PDCA sequence is a practice that takes patience and discipline. Individuals whose primary goal is to complete the form will start with solutions first because their conception of the tool as a mere piece of paper means filling in the boxes in the quickest way possible.

Now, let’s remember that the value of the A3 as a tool can’t be understated. We just need to clarify how. And that is what I like to call “lean communication,” or a “5S of information” enabling you to share your thinking with others. Once we have used the PDCA process in the correct sequence we can then produce a document that others can see and understand easily. This form of “standardized story-telling” (to cite Managing to Learn again) is key within any culture practicing lean thinking and can be a powerful tool to engage and empower leaders, as well as the front lines. The A3 as a tool in this regard cuts across all silos and can become the common language for successful lean transformation.

The Japanese often referred to the A3 as a storyboard. It does just that, telling a story that follows the PDCA process, allowing anyone at any level to be involved, sharing the learning experience in the form of shared wisdom. Can you imagine how important this practice could be to a company and the improvement of their key performance indicators and strategy deployment? Some refer to this practice as catch-ball, the sharing of information back and forth between leaders and workers working towards the improvement of the company business plan/strategy. When an A3 owner uses the tool side to explain his/her process side, then the learning and development is complete, fulfilling the A3 management process.  

So never lose sight of the thinking process that enables you to complete an A3—which then serves as a way of capturing, communicating, and building on what was learned. Remember what goes into the A3. As I see it, when an individual decides to become an A3 owner it’s important to follow the PDCA process when you pick up that paper and pencil and head to the gemba. It’s not about just “filling in” the boxes in some random order based on an assumption; but rather a specific process that asks a series of questions that requires engagement of people showing them respect where the work is being done. This process can be followed at the worker level as well as the company level to always understand where we want to be in regard to where we are.

The PDCA (Plan Do Check Action) is a systematic or scientific way of thinking that ask Socratic-type questions in a preferred sequence allowing the problem to be effectively and efficiently solved. The PDCA has many built-in mechanisms that keep the owner in check. I often say if the process talks to you and you listen then it’s working. If you ignore the process and jump over crucial steps then the process may be compromised and your results could be skewed—or lucky. It’s always good to adhere to the steps and allow the process to work for you so you can repeat that with others and develop your workforce using the same thinking.

Since there seems to be a lot of interest in this topic I welcome you all to weigh in on this subject with your thoughts and experiences. Please add your comments to the dojo on this page.

“Does it always have to be 5 Whys?” is one of the most frequent questions raised in my training classes. The answer is no. As with most lean tools, it’s important to understand the real purpose of this exercise. In this case, the “5 Why” label is meant to encourage you to ask why more than once or twice, in order to dig below the surface where the symptoms lie, and find the true root cause. The actual number of times you ask why is not critical: I have several examples where 2 why’s works best, and others where you might keep going until you’ve asked the question nine times. 

To practice this method you must go to the gemba to determine the actual cause and effect relationship of what is happening, engaging and involving those affected by the issue in the process. Conducting your investigation from behind a desk or in a conference room will often lead to fighting over symptoms not root causes. This approach will invariably be driven by theories and opinions rather than facts, facts, facts. Avoid the temptation to rely on pre-conceived notions since they often take less time to investigate. Whenever I hear that time is an issue, I reflect on a quote by the late John Wooden: “If you don’t have the time to do it right the first time, when will you have time to do it over?”

The important issue with this process is not to go too far. Continuing to ask why after you have located the root cause will change the context of the problem, or the scope of control you may have in forming appropriate countermeasures. You want to make sure that your countermeasure effectively addresses the root cause, and all the symptoms up the chain. You want to reach the level at which making a change will effectively and permanently address the symptom that prompted this exercise. (By the way, clearly seeing the chain of events helps you focus on seeing how the root cause of the problem is tied to one of three categories—lack of Standard, lack of following Standard, or wrong Standard—as opposed to being the “fault” of individual people.)

Consider the following example:

Problem: I was late for work.

Why? I was unable to get there on time.

Why? I overslept.

Why? My alarm clock didn’t go off.

Why? The clocking wasn’t operating as it normally does, in this case flashing when I woke up.

Why? There was an interruption in the power overnight. (Root Cause)

Why? There were lightning storms in the area.

Why? Hot and cold clouds in the atmosphere collided.

Why? Barometric changes took place.

Why? The jet stream causes changes to weather patterns.

Why? There are cycles to the seasons on Earth.

Why? The Earth rotates.

So. Determining that the earth rotates takes our series of whys way too far. This is what happens if you keep asking why. You change the context of the problem. If I try to form a countermeasure based on this exercise, the logical one being to change the rotation of the earth, how will that address my problem of being late? I’ve set my sights on something that is not within my control.

By recognizing that the overnight interruption in power is the root cause of this problem, I can form an effective countermeasure. I can deal with the power interruption by having battery backups. So while I can’t control the outcome of uninterrupted electricity, I can still address and resolve the problem. Going further than this would be a useless foray into issues that are beyond your scope of control.

Finally, as a good way of checking on your 5 Why experience, it’s good practice to ask WHY downward, and THEREFORE upward, as way of establishing Cause and Effect in your chain.

I’ve found that there are essentially four different types of A3s:

Problem Solving

Proposal

Status Report

Strategic Planning

All these reports share a common underlying approach. Regardless of which type of A3 you are dealing with, your approach needs to follow PDCA thinking. The basic steps of this Plan-Do-Check-Act cycle are:

Make a plan (grasp the situation). Establish where you are, and compare this with where you want to be.

Put the plan into action/implement.

Check for effectiveness. Modify if necessary.

Reflect/Standardize, and Share.

Let’s take a look at each of these A3 categories, and see where we can use them.

Problem Solving A3: In my experience at Toyota, I spent 75-80 percent of my time on these A3s. These problem-solving A3s will always follow the 8-step PDCA problem solving process. They should always be quantified and measured, stating a clear Gap to solve. There are “caused gap” problems, since they are created by situations where we aren’t able to maintain a standard, or an ideal situation.

Proposal A3: A proposal A3 is future state oriented, articulating where and how you want to improve the situation by suggesting an idea. This type of improvement is normally focused on an area or department and targets the performance of a specific indicator. Also in this category would be the Strategy A3, which is similar, yet focuses more on value streams and higher level processes related to the company business plan.

In these types of A3s you start out by explaining the current state or background and why it needs to be improved. Is the current state affecting a Key Performance Indicator (KPI) of the company? Can you show some benefit analysis for the idea, and recommend how you will implement this, with timelines and milestones? As the implementation begins you will need to evaluate its effectiveness and have a follow-up plan that ensures the work conditions are sustainable. This type of A3 is often called a “created gap.” You are trying to raise the bar or improve the situation or standard.

Status Report A3: A status report A3 can be a specific report showing the progress (on an weekly, monthly, quarterly basis) of a long-term project. It may show a Plan vs. Actual status, based on the expectations of the plan or project. Depending on the status, you could be asked to develop a short-term plan to get yourself back on the expected schedule if you fall short of a deadline.

I don’t use this particular A3 often, and did so particularly when a product/model change required detailed long-term planning to ensure success at the end date. The benefits are that it brings the PDCA cycle to use once more, asking the right questions of where we are and where we want to be at the right times.

Strategy A3: A strategy A3 is normally focused on the company Hoshin (business plan) over the longer term—anywhere from 1 and up to 15 years out. My experience with this was mainly around the 1, 3, and 5-year planning. I would include the Proposal A3 in this category, since it’s similar in nature to the strategy A3 but more narrowly focused. This A3 seeks to narrow the company gap from a current to future state based on what current business indicators are telling us what needs to happen. These types of A3 are normally authored by leadership at a higher level. They deal with topics such as a value stream between product and delivery that needs improvement—something that cascades downward throughout all levels of the organization as individuals focus their daily work on this specific goal. I may have excessive warranty claims, for example, and want to reduce this by improving the quality of the product itself by a specific percentage. This high-level goal needs to be tracked as it cascades down to the daily work of people and teams. And, as will all categories, this A3 should follow PDCA thinking. 

Does every problem require an A3?

In short…no.

Here are some thoughts that may help you if you have just begun your journey with A3 thinking and problem-solving. During my time at Toyota I didn’t have a particular matrix or set standard that we followed. Our people and culture, however, shared a way of thinking that applied to different types of problems that could arise on a daily basis at many different levels. Here is how those problems were categorized in my experience.

LEVEL ONE

This type of problem does not require someone to write a formal A3 report, but it’s important to recognize the importance of the thinking approach one takes nonetheless.  In most instances a team member/associate can handle this problem on their own. The root cause is often apparent, and minimal resources are needed to implement a countermeasure.  The value of A3 thinking here is to detail the actual work or process that the individual does.  The individual can then identify the “problem” because they can see a discrepancy (even if there isn’t a standard defined necessarily).

Problems at this level can be immediately tested/solved, without necessarily producing a formal A3. Companies can track these problems with something like a tic-mark sheet, counter or some other visible indicator. Above all it’s important to see that these types of problems are not just things to be “fixed”, but opportunities to develop a way of thinking. These types of problems challenge associates to think constantly about when they are out of standard (and they should also force leaders to develop standards with them if none exist!) Interestingly, this is the level where most of the team members were at Toyota. They did a lot on their own and also participated in Quality Circles. The company culture empowered the associate to “think.”

My experience is that 60-70% of the problems will/should fall into this category. For this to happen, of course, the PDCA practice of asking the right questions must be practiced through the leadership.  And remember one principle that is the foundation for this practice: establish standards, because this is the best way to make problems visible. 

 LEVEL TWO

These problems require an A3; or at the very least, detailed documentation that shares the learning with others (developing associates) as well as developing the ones responsible (supervisors).  Remember, developing the correct thinking of PDCA is always the underlying priority behind the A3 process.  And as I’ve been told, an A3 is only as strong as the dialogue that creates it. So the questions we ask to produce the facts and the countermeasures must be made clear to everyone.

So you may end up with a Level 2 problem when Level 1 problems resurface.  The reason could be that the associate did not get to the correct root cause or ask enough “whys”.  This could be a recurring problem that no one understands the root cause of. At the prior level, people may have only diagnosed the symptom and missed the deeper facts and chain of events.

Problems at this level may require stronger support and coaching, possibly from the next level of supervisor. They could require resources like maintenance, engineering, tool and die, and higher-level decision making authority.  This level is more than likely affecting the key performance indicators (KPIs) of the company in some way. 

At this level a deeper look into how the problem was defined is necessary. This means a disciplined analysis of the true "pain to the organization" caused by this problem. For example, we sometimes frame problems in the sense of "productivity issues", but the bigger problem may be "scrap rate".  Decreasing the scrap rate would in turn improve productivity/efficiency.

And so Level 2 problems are mainly for line supervisors/group leaders and above, with the support of their associates.  The supervisor would be responsible for the documentation of the 8-step problem-solving process. My experience is that 15-20% of the problems are Level 2.

 LEVEL THREE

This is when a problem/defect may "flow out" to the customer (internal or external), creating downtime, quality, or safety issues for the customer which in turn can affect your own company indicators.  This activity should engage a higher-level manager, who is responsible for the documentation of the A3, and also for getting support and buy-in from the line supervisors and associates.  Engaging the plant manager/high level leadership should create the accountability at that level to be responsible for his/her production floor as well as developing their people to understand how this happened. Again, this process reminds us of the fundamental role of setting standards, which establish how things should be done, and enable everyone to better understand what has gone wrong.

Any defect that got past an area/department and made it to the customer is unacceptable, and should trigger an immediate countermeasure to stop the bleeding and ensure that no other defective product flows out. This should also prompt the finding of a permanent countermeasure using the 8-step process by the plant manager. This individual must take the initiative, gathering the necessary resources necessary, involving their people to ensure this will not happen again, and overseeing the process so that everyone learns from it for the next A3.  

Problems at this level could also be related to potential recalls, external customer complaints, missed orders etc.  Also there could be situations in-house where there may be a major breakdown that shuts your customer down in turn.   There could be an internal safety incident where someone was severely injured.

Problems of this level must be addressed by management. Their ability to lead responsibly is crucial.  Remember the associate’s capability is only as strong as their leader’s capabilities. My experience is that 5-10% of the problems are Level 3.

LEVEL FOUR

This level of problem solving is more of the "raising the bar," proactive problem solving. Some call this exercise purposely creating a gap. This approach ties into the process of DAMI (define-achieve-maintain-and improve.) Working on these problems helps one raise the bar from maintain to improve.  I faced such a problem when a trainer of mine saw waste in my processes and told me to go from 10 team members to 9 team members. He was raising the bar on me, changing my current standard. 

This is sometimes called a Jishuken event, or management driven continuous improvement event.  I was involved with several of those at Toyota where we improved our productivity/efficiency by rebalancing manpower, and not hiring new people as a result.   This is a practice in seeing waste, and asking the right questions. What should be happening vs. what is happening?  Is this standard acceptable?  Can we raise the bar to improve our company?  It gets the people who are practicing level 1 problems to see deeper, think deeper and see how what they are doing is contributing to the company/business indicators. 

Going back to problems is another way of defining job security.  Doing so allows people to assist in the other levels of problem solving, and developing a better problem awareness, which can in turn prevent many Level 2 or 3 type problems from occurring in the first place.  Jishuken should be part of your culture, not deemed as a "special activity".  Unfortunately most companies are always putting out fires. And so this level of problem, where companies actually create gaps on purpose, is a very LOW percentage. Less than five percent and closer to zero. Companies think it is crazy to purposely create a problem. Yet over the long term, those that don’t will end up far less sane…

This column is going into uncharted territory – some might call it the dark side – of the organizations where we work – their cultures.  The question I want to raise is, Exactly what is the nature of a culture that could be called a problem solving culture?  In an earlier column I talked about Toyota having a “culture of responsibility.”  Now I want to try to describe what I believe that animal looks and acts like based on my experience, and beyond that, what contributes to its development.

I’ll start with what I understand an organization’s culture to be.  It is a set of assumptions-in-operation.  By that I mean it consists of the generally shared beliefs, both spoken and tacitly held, about how things really work, are done and not done, and how the people doing the work should deal with one another as they go about the business of the organization.  It is a set of guidelines that is generally more assumed than stated. That means we are going to have to focus on the social and people side of an organization to “go to the gemba” of its culture. 

Machines, materials and methods do not make and hold assumptions. People work in the mechanical and technical systems and the organizational structures of a company and over time develop shared assumptions about what it means to live and work there. The people – all the people, not just management – are the keepers of the culture of an organization. But executives and managers are without doubt the key contributors to the development of a company’s culture.

In his book on change leadership, Beyond the Wall of Resistance, Rick Maurer refers to Douglas McGregor’s work in the 1960’s describing opposing sets of assumptions that managers can have about human nature.  In The Human Side of Enterprise, McGregor distinguishes between Theory X assumptions which hold that people are basically irresponsible at work and have to be directed and controlled to perform as needed; and Theory Y assumptions, which are based on the belief that the desire to be responsible, to contribute and perform effectively, is basic to our human nature and the way most people will approach their work if allowed.  Maurer suggests that in spite of fifty years of management thought and talk to the contrary, many people and managers continue to be Theory Xers in “sheep’s clothing.”   If Theory X assumptions are indeed still in operation, how would they affect managers’ decisions about giving employees problem solving responsibility?

To illustrate by contrast, consider the response by the former chairman of Toyota, Fujio Cho, when John Shook asked him about the keys to lean leadership. Mr. Cho suggested three simple behaviors.  First is, “Go SEE.” Managers including senior managers must spend time on the plant floor to know the actual conditions they are trying to manage. The second is, “Ask Why.” It is critical for managers to question their observations, interpretations and assumptions as well as those of others by persistently asking what facts underlie them.  And the third is, “Show Respect.”  

The first two behaviors can be considered part of technical problem solving but the third is clearly on the social side and is not often part of our problem solving thinking.  With regard to “Respect” Shook further explains that Mr. Cho is saying, “Respect your people” – the people who do the work and create the value in your company.  What does it mean to actually “respect your people” as part of your way of managing in a more concrete form than saying, “our people are our greatest asset”?  Drawing on both the Toyota example and my experience with the ups and downs of lean thinking in North American I would suggest three interpretations.

First, Toyota’s focus on eliminating waste ensures that the work is organized so it does not waste the time and effort of employees.  One of the basic principles in establishing standard work is that the operator should not wait on or work for the machine.  Machine cycling should be planned to allow the operator to do other value-added work and free him or her to attend to more important things like safety and first-time-through quality. Also it is management’s responsibility to organize the work flow and work place starting from the needs of the operator out so that he or she can the perform value-added work with as little interruption as possible.  This responsibility extends to organizing work processes and information flow to assure the operator can move and perform safely and to minimize rework due to unclear instructions, standards and status indicators. 

A second manifestation of respect for the employee is to start from the positive rather than the negative assumption about his or her willingness and ability to take on responsibility beyond simply carrying out tasks as instructed.   That basically means operating from the assumption that employees who resist taking on greater responsibility when allowed are the exception not the rule.  Daniel Pink in his 2009 book, Drive, reviews fifty to sixty years of study into what motivates people at work, and reports that the most effective motivators, particularly for work that requires thinking, are not extrinsic rewards and financial incentives but the basic human intrinsic drives for autonomy (having some control over their work), mastery (the chance to grow and to increase capability) and purpose (feeling you are contributing to something bigger than yourself.)  This would seem to indicate that managers and executives would do well to start from the assumption that their employees want no less than they themselves want in their work lives.

The third, and most critical interpretation, is to give people the respect of recognizing they can and will think if allowed. It has been said the most flattering and affirming thing you can do for another person is actually listen to and acknowledge what he or she is saying. I suggest there is a degree of respect beyond that and it is to demonstrate you assume there is thought behind what they say and it is worth attending to.  In a work environment that takes the form of first giving employees responsibility for recognizing and addressing problems within the scope of their work and their work area and second, and even more important, not taking back the responsibility after giving it.  The impact of discounting employees by taking over problem solving responsibility is so great that it is better to never give it in the first place.  Managers need to be especially sensitive to this because it is so easy to do.  Even suggesting an enhancement to any employee’s idea can be disempowering.

Skeptical that the assumptions leaders hold make a difference?  Consider this research, which has been repeated numerous times with groups of school kids.  Teachers are given groups of kids who have demonstrated on tests and through their work that they have equal abilities.  The kids are randomly divided into two groups and the teachers told one group has less ability than the other.  Within a short time the group credited with higher ability is consistently outperforming the other group.  The factor that is observed to have the greatest influence on the performance of the two groups is the difference in the way the teachers treat the groups depending on whether they have high or low expectations of them.  Are managers any less likely to be influenced by their unconscious and unquestioned assumptions? 

Managers and executives are not evil people who set out to create organizations that diminish the value and human dignity of their employees.  In many ways they are victims of the assumptions they hold as well.  The Theory X underlying assumptions about employees that were prevalent in management thinking for the first two-thirds of the twentieth century may be so deeply engrained in our organizations and management practices that we are not conscious of their influence.  But if the people who do the value-creating work in a company are indeed its most valuable asset, it is going to be difficult for companies to realize their full business potential if they waste or ignore much of their employees’ potential to contribute.

If a problem solving culture is the means to continuous improvement as a way of doing business it may be helpful to “unpack” the term and consider what it implies.  At first glance neither part of the term seems anything special.  All companies have a culture and all companies solve problems to some degree.  The question, then, is what is different about this problem solving culture that many continuous improvement leaders want to have?  In this column I will consider the nature of the problem solving required for Lean continuous improvement.  In a later column I want to explore the “culture” side of the Lean problem solving culture equation.

Since Toyota is the model most often held up as a problem solving culture it seems logical to see what can be learned from what they do. In my last column I shared some facts about the breadth and depth of Toyota’s problem solving culture. It is an environment in which don’t just have ideas for improvement but take the initiative to get agreement to try them out and if they are proven effective then submit dozens of them as suggestions annually for recognition and reward.  The key question for others wanting such a problem solving culture is what does the problem solving involved look like?

First, problem solving as it is carried out in Toyota has two distinguishing features. One is the requirement that everything described or claimed in the problem solving process (the problem itself; the target condition, the direct cause, the root cause) be based on confirmed facts and not assumption and interpretation. 

The burden of proof on the problem solver is emphasized through questions and expectations such as, “What’s the real problem?”, “Go to the gemba and grasp the actual condition first hand.”, “What is purpose?”, “How do you know that?”, “Keep asking Why, at least 5 times.”, “How do you know you have an agreement to your plan?”  All of these reinforce the expectation that the person claiming to have the solution to a problem or an effective improvement be able to demonstrate with observed facts and data and not just assumptions and opinions why he or she believes a proposed countermeasure to a problem is the right one and will work. 

Is this different from most problem solving practice and if so, how?  Situations observed in two companies are typical of much problem solving practice.  In the first example the managers of production, maintenance, planning, materials handling, quality and safety in a machining operation were in their weekly production meeting. They were discussing being behind schedule on deliveries and how they would make up the shortfalls. Someone mentioned the impact on run time of grinding machines leaking oil.  For 30 minutes the group discussed when the machines could be shut down to fix the leaks, who was to blame for the leaks and issues with the design of the equipment. Finally someone asked exactly which machines are leaking. No one knew.

The second observation was in a center processing credit applications.  A team of specialists had been working for six weeks collecting and analyzing data to determine why the operators were running an average of seventy-five seconds over cycle time for initial review of the applications. In spite of their in-depth analyses and experiments the specialists were unable to find the cause of the delay.  Finally a session with a group of operators to ask their ideas for fixing the problem was proposed.  The group suggested giving the operators a second monitor to have the review guidelines displayed all the time.  Since the guidelines had been revised they were finding they frequently had to get out of an application and bring the new guidelines up on their screens to confirm instructions. During six weeks of studying the operation none of the specialists had thought to ask the operators what they knew about the delays.

These two situations illustrate an all too common pattern.  In many companies problem solving consists of a discussion in a conference room away from the problem.  Problem solving proceeds based on partial knowledge and assumption.  Seldom is there an effort to go to the site of a problem to observe what is actually happening and ask for the input of those doing the work at the site. There is a leap from problem recognition to solution without taking time to determine the real problem or its cause.  This is not the kind of fact-based problem solving that Toyota demands for deciding countermeasures and prosing improvements.

There is a second key distinguishing feature of problem solving at Toyota and it has few parallels in problem solving in North American settings.  It is the recognition that problem solving really begins rather than ends when implementation starts.  Expressions like “Planning is essential; things never go according to plan” indicate the perspective on implementation.  A plan is a theory of both what will address the problem of a cause and what it will take to implement a countermeasure to that cause.  The implementation process is a learning process to find out what actually will be required to put countermeasures in place and eliminate a problem. 

In the Toyota perspective implementation or “DO” is part of the Plan-Do-Check-Act cycle but there are also many smaller PDCA cycles in the DO phase.  It is recognized that a plan is no guarantee of implementation according to plan and that constant checking and grasping the situation are necessary to have things go according to plan. Two key practices during DO in Toyota’s approach to implementation are “managing performance to plan” and checking “Plan versus Actual.”  The emphasis is on picking up gaps between what was planned and what is actually happening during implementation, identifying their causes and making countermeasures to close the gaps.  Another way of looking at implementation as practiced in Toyota is that you are likely to need to solve a lot of problems to actually solve a problem or make an improvement. This approach might be better described as problem resolution rather than problem solving.

These practices are in contrast to the typical approaches to implementation in North America.  In North American companies many admit the approach is often more P-D than P-D-C-A.  Implementation in North America seems characterized by two extremes.  On one hand is what appears to be the assumption that once the solution to a problem is identified that the hard work is over and everything will fall into place because now the solution is known.  This may be a reflection of the nature of problem solving as experienced in math and science classes in school and college. Students are taught if they take the data given, plug it into a formula in the right places and perform the operation correctly they will get the answer. Problem solved. The difference is textbook problems are structured problems.  Most of the problems encountered in business, technical operations and human systems are unstructured.  The desired outcome is not know; the data is not given; there is not formula to use, and there are often many, not just one answer.

At the other extreme is the detailed project planning and management approach that breaks implementation down into a series of numbered tasks.  The breakdown of goals and actions to identify those tasks is often done by specialists and the tasks are assigned by project managers who are removed from the work processes that will be used or changed.  There are checks at phase gates or major milestones but progress is often evaluated with codes such as green, yellow and red.  What is frequently missing is consideration of the nature and causes of the red and green gaps and whether what has actually been achieved by “green” progress is the outcome that is needed.

Fact-based problem solving, project management following the Plan-Do-Check-Act cycle and Plan-versus-Actual problem solving to drive implementation of countermeasures are key features of the Toyota Way of problem solving.  So is Respect for People as people with problem solving capability?  This column has looked at the technical side of a problem solving culture based on the Toyota example. In a later column I will explore the social system side of problem solving culture.

Welcome to this MTL-mini site within www.lean.org a destination for thought leadership in lean management in general, "managing to learn" and the A3 process in particular.

The goal of this site is to narrow the gap between reading about how to create an A3 and actually doing A3 management. This site within a site is meant to be a shared space for A3 thinking, a place for you to engage with others on the nitty-gritty daily challenges of your specific problems. Even for you to create an A3 and own it in the process.

This mini-site emerged out of the 2008 publication of Managing to Learn: Using the A3 Management Process to Solve Problems, Gain Agreement, Mentor, and Lead. Managing To Learn (MTL) has been successful as a book. It has had strong sales in 14 languages, led to the creation of effective workshops, and inspired much dialogue and enthusiasm in the lean community. I hope it has also led to effective problem-solving, decision-making, organizational alignment, and managing to learn.

Yet the broad interest in A3s has led to a potential managerial hazard: a reductionist approach to the A3 tool. A narrow, short-term, instrumental use of the tool which prevents people from using it in the generative, people-developing, evolutionary manner in which it evolved. We found the same problem with value stream maps. People often mindlessly copy, as Jim Womack said, "getting the words right but not the tune." What is needed is for people to understand the deeper purpose of the A3 management process and to make this tool their own through practice.

Let me quote from a column I wrote introducing the A3 process:

"The challenge isn't in teaching how to write an A3 but in how to use the A3 as a managerial process. If the A3 was presented as a narrow tool, the deeper and broader aspects of the overall process would be lost. I really didn't want to just introduce yet another narrow tool. It has long been my view that using tools for tool's sake (where everything is a hammer looking for a nail) is one of the very biggest problems in 'Leanworld.'" ...

"The most fundamental use of the A3 is as a simple problem-solving tool. But the underlying principles and practices can be applied in any organizational settings. Given that the first use of the A3 as a tool is to standardize a methodology to understand and respond to problems, A3s encourage root cause analysis, reveal processes, and represent goals and action plans in a format that triggers conversation and learning. A good A3 has sound problem-solving -- science -- embedded inside, but it achieves much more, exemplifying this great quote by a great scientist: "

Science is built of facts the way a house is built of bricks, but an accumulation of facts is no more science than a pile of bricks is a house." - Henri Poincaré

In this space we will be engaging the support and dialogue of the lean community - a network of fellow practitioners, who range in their own journey from just beginning to highly-experienced. We hope you will share your problems and solicit the input of people who are facing similar problems, or who have learned something from experience that can help you.

Over the coming weeks you will read columns from individuals with A3 experience and advice. You will be able to share your work in progress and ask for coaching from others. You will be exposed to helpful resources for your ongoing work. Please join in this conversation and help us to improve the dialogue and practice of this important managerial way.

On this side of the dojo, I will be joined initially by my experienced colleagues David Verble, Tracey Richardson, and Eric Ethington. Eventually, we will be joined by others. And, hopefully, by you.