ANALYTICAL PROBLEM SOLVING

Paul R. Haviland
The Haviland Consulting Group
Grand Rapids, MI 49506
(616) 451-9860
www.fmeca.com

SUMMMARY

Throughout the post-WWII evolution of various quality concepts, many tools and methodologies have been developed to
deal with how companies should respond if they are so unfortunate as to have a defective product or service reach their
customer. These unfortunate events are frequently referred to today as Quality Problems. Obviously these problems need to
be resolved in order to maintain customer satisfaction. As the quality requirements of customers have become more
demanding over the years, the methods of solving problems have become more disciplined and analytical. Also, the
emphasis in many cases has appropriately shifted from Problem Solving to include Problem Prevention techniques. Further,
the systems and processes used to address these issues have expanded in some cases to include Process Improvement.
Because of this progression, it is now more difficult to discuss Problem Solving without some reference to these other
processes. In fact, at times the language can actually get confusing and various quality tools can even be misapplied. This
paper will try to focus primarily on Analytical Problem Solving by defining “Problems” from a somewhat narrow viewpoint
that makes it practical to identify useful tools and processes for dealing with this important “after the fact” quality process.
The methodology of Problem Solving will be presented here in Four Phases with a discussion of various tools that can be
effectively applied at each phase.

INTRODUCION

It seems that for many companies, one of the first broad based employee training efforts they engage in (after perhaps
Orientation) is the exposure of a large number of employees to some Problem Solving methodology. There is a lot of
acceptance for the notion that it is a good idea for a lot of people in the organization to have good problem solving skills so
that they can immediately spring into action at the first notification that something has gone wrong. And thing go wrong
frequently enough that an “all hands on deck” approach to fire fighting seems to make some intuitive sense. Some
companies may think this because for them, the first inkling that they need to improve their quality comes from a sense that
their company is receiving too many customer complaints. The reaction is entirely understandable.

This notion, that Problem Solving training should be the subject of employees introduction to quality, I think merits some
thoughtful consideration. I say this, despite my own early experiences in the field of Professional Quality in 1988. My
formal introduction to Quality Management came at Ford Motor where, as an outside contract trainer, I was exposed to an
important tool in Ford’s quality tool box: the 8-D Problem Solving Methodology (8 Disciplines or Steps). I spent the next
several years helping Ford deploy that process throughout their company and their supply base. I spent several years working
to fulfilling that goal. But with one of Ford’s suppliers, things were a little different. Right after the Problem Solving training
was deployed, the development team I was working with was directed to begin working on a broad based training
deployment in FMEA, Failure Mode and Effects Analysis. This was a Problem Prevention methodology. That opened my
eyes to the many connections between Problem Solving and Problem Prevention. One of the most important relationships
was a notion popularized on TV commercials several years ago with the catch phrase, “you can pay me now or you can pay
me later”. You can either pay up front for Problem Prevention, or you will pay later in Problem Solving costs. And when
you have to pay later, it probably will cost more than if you had dealt with the Problem up front. The idea that it will cost
more to fix later rather than earlier is one that many of us have actually experienced. The old adage says a stitch in time
saves nine. So does it cost nine times more to deal with a problem after the fact as opposed to before? Or is it 50 Times? Or
is it100 Times? How much more is it? Let me relay a real life example.

In the early 1990’s at the 7th Annual Quality Forum in New York, the President of RIHCO, Hiroshi Hamada addressed the
conference and gave a wonderful example. He outlined the expenses his company had incurred in the process of recalling one
of their office machine products because it had a defect. In his presentation, he traced the total expense of dealing with the
problem all the way back to the original cost of the error. By the time the whole ordeal was all over, it had cost the company
67,000 times the original cost of the error. I have always remembered that presentation as a valuable example of the Problem
Prevention principle “pay now or pay a whole lot more later”.
 Another example can be seen in The Six Sigma methodologies that are becoming more and more popular. Practitioners of
this approach acknowledge that most existing processes cannot achieve Six Sigma levels of quality with just Problem
Solving/Process Improvement methods and tools alone. So they look to Design for Six Sigma (DFSS) tools to achieve the
desired World Class levels of defect free products and services. They understand the benefits of investing up front in defect
free designs so that they don’t have to pay the greater costs of compensating for oversights by creating process “work
arounds” such as in-line repairs and rework.

So here is some food for thought: perhaps Problem Solving (the pay me later approach) may actually not be the best place
to start a large-scale training introduction to quality. Maybe Problem Prevention should come first. Might it not be more
valuable to expose large numbers of employees to the concepts of Error Proofing first? Maybe we should teach Design for
Manufacturability (DFM), Design for Assembly (DFA) Design for Service etc. and engage people first in these aspects of the
company’s quality process.

I offer these thoughts because at several points in this paper, as we explore the methods of good Analytical Problem
Solving, the need for Problem Prevention and Process Improvement is likely to arise. In real life, the root cause of a problem
that we are trying to solve frequently is a design issue. By making these distinctions, we have an opportunity for clear
analysis, good decision making and better processes in the future.

The objective of this paper is to look at a really good “pay me later” process: Analytical Problem Solving. Since preventing
all quality problems is practically impossible, learning to deal with these situations effectively a very good idea. A huge
challenge is created when we have problems that effect customers. How are we going to satisfy a customer after we have just
delivered what they consider to be a defective product or service? The only way I know of is to resolve the problem in a way
that assures the customer that at least they will never see that problem from you again (and hopefully none others like it).
That means we need to know how to do good Problem Solving.

THE APPROACH

Individuals who are untrained in Analytical Problem Solving tools typically use an intuitive approach to problem solving,
based on their experience. They collect information about the problem until their intuition and experience tell them they have
enough data to hypothesize on a cause, which they then go check out. If they are wrong about their hypothesis, they collect
more data and repeat the process as many times as necessary until hopefully they find the actual root cause. The weakness
with this approach is twofold: first, it can take a long time to test a large number of theories one at a time and second, if the
cause of the problem is outside of our experience and intuition, we might not collect the correct data (because it wouldn’t
seem logical to do so) and therefore never find the root cause. The analytical approach says: as an initial step, let’s go collect
up front, all the data we can about What, Where, When and How Big the problem is and then start to eliminate causes until
we narrow the possibilities down to a handful that can be finally tested to verify which is the real root cause. When I was first
introduced to this concept, it was a real revelation. I would have never come to this approach on my own: collect all the
possible causes and then eliminate the ones that can’t be the root cause.

THE PROBLEM SOLVING PROCESS

Over the past 20 years of observing various Problem Solving Processes, I have concluded that there are 4 major phases to
solving a problem where the root cause of the problem is unknown. These four phases evolved in part because different
skills are used in various aspects of problem solving, and many practitioners put these into four groups. Further, there seem
to be some “general” categories of where we can go astray in the overall process, and there seems to be four of those as well.
Out of each of these four phases can come additional steps leading to a methodology with 6 steps, or 8 or 10 or however
many the authors deem important depending on what details they want to emphasize. So by identifying only four Phases, it
was not my intent to diminish in any way the importance of additional aspects that others have found to be important, such as
Team Building, Recognition, etc. I do so only for the purpose of focusing on the fundamentals.

This paper will explore in some detail, these four basic phases of Analytical Problem Solving.

1. Describe the Problem

2. Identify and Verify the Root Cause
3. Decide how to eliminate the Root Cause
4. Implement the solution
ANALYZE THE SITUATION

We discussed earlier the relationship between Problem Solving and Problem Prevention. Another distinction that is
sometimes blurred but which I think merits understanding is the difference between Problem Solving and Process
Improvement. I have seen Problem Solving methodologies that begin at Step 1 with something like this: Identify the
Problem or Opportunity. These words are used here in an analytical context not a marketing context, where we might be
able to turn a problem into an opportunity. The point of the analytical context is that quality problems might be different from
opportunities in very important ways. And if they are, the tools we use to address one situation might be different from the
tools we use to address the other. For example we know that in the Six Sigma methodology, the DMAIC Steps (Define,
Measure, Analyze, Improve, Control) and all the tools that go with them, are used to address primarily Process Improvements
(although the term Problem is frequently used). And while many of these help with Problem Solving, some can be
misapplied. And there are other tools that are very helpful in Problem Solving.

Walter Shewhart and Edwards Deming helped us understand one possible distinction between Problem situations and
Improvement opportunities with their development of language to describe the different types of variation that may exist in a
process. They made a distinction between Special Causes of variability and Common Causes of variability. I have found it
useful to think of “Problems” as coming from Special Causes of variation. They usually have only one source (assignable
cause) and are not a normal part of the variation usually seen in the process. On the other hand, “Improvement”
opportunities can be thought of as coming from Common Causes of variability. Typically this situation evolves from
multiple sources i.e. the 5 Ms (Methods, Measurement, Materials, etc.). Sometimes these sources even interact with each
other to create excessive variation. They are in the process on a normal basis. So the focus of improvement efforts in this
situation is to identify and then reduce the largest sources of this variation.

It may seem like it has taken us a long time to get to this point of actually coming to understand what a “Problem” is, but it
is valuable to have done so. Clear language allows for good understanding of the situation and effective problem resolution.
Currently we owe to Ford Motor Co.’s 8-D Problem Solving methodology (now called Global 8-D) the succinct definition of
a Problem as: a Deviation from a Standard. What does this look like? Imagine a stable process that is operating capably. And
then suddenly it starts producing defects. The Standard in this case is the normal level of Common Cause variability that is
usually present in the process and considered acceptable. A (negative) deviation from this Standard would be evidenced by
the defects that the process unexpected begins producing. This is what we call a Problem. What follows are some tools that
have proven to be helpful in finding the source of this “special” cause of variability i.e. the Root Cause of the Problem. The
situation is that the cause is unknown and needs to be identified and eliminated. Of course, if the root cause is already known,
you don’t need to use many of the problem solving tools. Go directly to Phase 3 and decide what to do about it.

PHASE 1: Describe the Problem

You may have heard the phrase “ a problem well described is half solved”. I have come to understand this adage and
subscribe to it wholeheartedly. On numerous occasions I have witnessed the cause of problems to be revealed, almost
miraculously, because the problem description was done well. It is impossible for me to over emphasize the importance of
completing this phase well.
Assuming that the root cause of the deviation is unknown, the very foundation of the problem solving efforts is the
development of a good Problem Description. The Problem Description is a thorough statement of the symptoms of the
problem and should avoid suggesting causes (that will come later). If the symptoms of the problem are not thoroughly and
accurately described, finding the cause is much more difficult. It’s like going to a doctor and expecting them to find out
what’s wrong with you without you telling them how you feel and not running any tests.

There are 3 key elements that make up a good Problem Description:

1. A clear Problem Statement

2. Determination of the Problem’s Scope
a. Cause and Effect Diagram
b. Process Flow Diagram
3. An organized list of Symptoms (Is/Is Not Matrix)

The Problem Statement should be a clear concise statement of the primary symptom(s) of the problem. A great deal of
detail can be avoided at this point because it will all come later in the Is/Is Not Matrix. A simple two part statement is ideal:
What is the object having the problem and what is wrong with that object (Object plus the Defect).
 A Cause and Effect Diagram is usually thought of as belonging in the next Phase when we are actually looking for possible
causes. I like to use it here however, to begin setting the scope of the problem. By starting the C&E diagram here, one gets a
sense of the possible sources of variation and becomes more familiar with important factors influencing the problem. This
analysis will be re-visited in the next Phase.

A Process Flow Diagram is a graphical representation of the process using symbols and connecting lines to show the
sequence and relationship of the various steps in the process. It is done here as a further attempt to understand the scope of
the problem and to begin to understand where in the process the cause may lie. It will be used later to eliminate some
potential causes and can be combined with the C&E diagram for further cause analysis.

The Is/Is Not Matrix is a most valuable and vastly underutilized technique for describing the symptoms of a problem. By
describing not only what the symptoms are, but also what symptoms might have been present but were not, this technique
puts a kind of boundary around the problem and makes the testing of hypothesis much easier. Both “is” and “is not” data are
collected describing the symptoms around the following characteristics of the problem: What, Where, When and How Big.
If any of this data is missing, you know what further information needs to be collected before moving on to try to find the
root cause. Also, the matrix gives us a valuable way to organize information about the problem. If some piece of
information doesn’t fit anywhere in the matrix, it probably isn’t really a symptom of the problem and belongs somewhere
else in our analysis. Changes around a process for example are very important but belong elsewhere in the analysis of
potential root cause.

PHASE 2: Identify and Verify Root Cause

The objective of this second phase is to develop hypotheses about what could be the root cause and then test the hypotheses
to verify which one is correct. It is not uncommon to use combinations of tests to add weight to the verification process. I
view verification methods as falling into three Groups:

1. Theoretical tests
a. Logical fit of the data
b. Comparative Analysis
2. Statistical tests
a. Proof tests
b. Probability
3. Experimental tests (Physical proofs)
What follows is a brief discussion of these six topics.

One of the tremendous advantages of the Is/Is Not Matrix not previously mentioned is that by organizing the data in the
matrix, sometimes the root cause becomes immediately apparent. In these cases a hypothesis presents it self and explains all
of the data in the matrix. The next step is then to do a final verification (if possible). If several hypotheses seem apparent,
test them all against the Is/Is Not data and see which one makes the most sense (Logical fit of the data). Further verification
tests can then be conducted based on which hypothesis explains the greatest amount of data.

In more complex situations where there are many possible theories and none appear obviously better than any other,
additional analysis of theories can be done by looking at two additional factors: Changes and Unique Characteristics
(Comparative Analysis). For changes, a timeline should be developed of all of the changes around the process. Changes are
“special” events and can cause deviations from a standard. These Changes than can be used to develop further hypotheses.
Finally, if even more analysis is needed, Unique Characteristics can be developed from the “Is” information and combined
with the Changes. One would go looking for the Changes that were made around the Unique Characteristics of the “Is”
information.

In my experience, Statistical Proof Tests are usually applied to Process Improvement projects where significant samples
can be taken and tested. Tests can be run for example to test the average value (mean) of a distribution before and after a
change is made to the impact of a suspect cause. Or the shape of the distribution (i.e. standard deviation) can be tested to see
if eliminating a particular cause can reduce the amount of variation.

In statistical proofs, the likelihood (Probability) that a particular cause was the root cause is stated in terms of its
probability of being the root cause. One might not be absolutely certain that they know the root cause but they can calculate
a probability to, say a 95% confidence level (or some other desired level).
 A final kind of verification method is a physical demonstration (Experimental Test) that the root cause has been identified.
The idea here is to show that by making an adjustment to just one element in the process, one can make the symptoms come
and go. Numerous repetitions of this experimental adjustment, each time turning the problem on and off so to speak, adds
confidence that you know the root cause and can control it. Of course in some cases it is impossible or impractical to make
the problem return to show that you know the root cause. In these cases, use one of the other methods, and be prepared to
collect ongoing data after the fix is made to verify that the problem has stayed fixed over a period of time.

PHASE 3: Decide how to eliminate the Root Cause

This third phase of Problem Solving requires totally different skills and tools than were used in the previous two phases.
Here we need good decision-making skills. Also, in this phase we have the opportunity to get creative in coming up with
potential solutions. Brainstorming is one tool that helps us come up with creative solutions. In this process, an environment is
created where lots of ideas can be collected without the normal environment of immediate evaluation or even criticism. So
instead of discussing why a particular idea won’t work, at this phase we just collect all the ideas. We’ll evaluate them later.

A simple way to begin to narrow down a lot of possible choices to a manageable few is a tool called a Payoff Matrix that
directs us to ideas that might be best. The matrix is developed with “amount of effort to implement” on one axis and
“amount of benefit” on the other. The matrix is set up with 4 quadrants: Low Benefit and Low Effort, Low Benefit and High
Effort, High Benefit and Low Effort, High Benefit and High Effort. Suggested solutions are then sorted into the 4 quadrants.
Hopefully there will be solutions in the High Benefit and Low Effort quadrant.

At this point in the process, there may still be more than one logical choice for a best solution. A good method for
determining which is best is sometimes referred to as Criteria based Decision Making. In this process, success Criteria are
identified first and then each option is compared to the Criteria to determine how well each option fulfills that criteria.
Commonly the Criteria are weighted (a scale of 1-10 works pretty well). Then a numerical assessment is made of how well
each option satisfies each Criteria (again on a scale of 1-10 works). With some pretty simple number crunching, a
mathematical evaluation can be made to determine which solution provides the highest benefit. Then a risk analysis is done
and the best, balanced choice can be made.

PHASE 4: Implement the solution

A. Implementation Strategy

The fourth set of skills needed to complete an effective Problem Solving Process are Planning skills. We need these in
order to implement the solution identified in the previous Phase. We realize that even if Phases I II and III were done
perfectly it is still possible to mess up this effort if the planning isn’t executed effectively. Force Field Analysis can be a very
useful tool to help at this Phase. Force Field Analysis looks at all the forces at work on a given situation. Considering what
is going to change when we implement our solution, with these forces are categorized into those that will help us drive
toward our goal (Driving Forces) and those that will impede our efforts to move in that direction (Restraining Forces). By
looking at all the forces, we can combine efforts to increase Driving Forces and reduce Restraining Forces to achieve our
goal. A special application of Force Field Analysis is used to deal with people whose help we need in order to be successful
with our implementation. This is called an Influence Strategy and is used to analyze and increase people’s support in terms
of Driving and Restraining forces that influence their support.

The most effective planning tool I know of is termed Failure Mode, Effects and Criticality Analysis (FMECA or simply
FMEA). It requires that a Process Flow Diagram be done on everything that is important to the plan. Then every important
step or element is examined based on how it could fail. Risks of failure are assessed and plans are made to make sure that
each important element can be carried out with an acceptable level of risk.

B. Planning

This is one of the parts of Problem Solving that gets us into the discussion of Problem Prevention. By looking ahead and
planning we can avoid implementation snags.
A simplified adaptation of FMEA gives us a good strategy for less complicated planning. It is outlined in the five steps
below.
 1. Identify the Critical Steps

Identify all of the steps that are critical to the success of your project. Start with those that will totally ruin the
implementation if they don’t go according to plan.

2. Determine what could go wrong at each step?

List literally everything that could go wrong at this step. The task may seem tedious, but remember, you are dealing with
“critical” elements. When it comes to preventing problems, remember, the devil is in the details.

3. Decide how will you prevent each identified problem (Plan A-Prevention)?

Based on your assessment of how likely a particular problem is to occur, decide how you will keep it from happening.

4. Decide what you will do if you can’t prevent a particular problem and it does occur (Plan
B-Protection)?

Some problems can’t be controlled or are so unlikely to occur, that planning for them is unrealistic. That’s realistic, but
what are you going to do if one of these remote problems does occur? Remember, you are dealing with “critical” elements.
If they don’t get done your implementation will fail. Decide now, up front, how you will recover from an unavoidable
problem.

5. How will you know it’s time for Plan B (a trip wire)?
A final element in the planning process is to determine in advance what event will determine that you need to implement
Plan B. This should be some timing trip wire or something that happens or doesn’t happen that will tell you it’s time to
initiate your damage control plan.

C. Prevent Recurrence

There are three more valuable activities that should take place before completing a problem solving activity. The first has to
do with the problem at hand:

1. Determine how you will keep this problem from coming back.
It must be one of the most embarrassing and costly moments any of us can face, to have a problem return after we have just
committed to a customer that we would personally see to it that the problem would be fixed once and for all. It seems it will
take a miracle to keep the customer at this point. It’s really going to get expensive now. Serious actions need to be put in
place to keep a problem from recurring after it has been fixed. Ideally, the solution to our problem included error-proofing
changes that make impossible for the cause to recur. But typically, some monitoring actions still need to be put in place. If
the cause returns, we will want to know about it long before it has a chance to create a serious problem and get to the
customer. In many circumstances a written Control Plan is developed. All the details of the monitoring process are identified
and immediate actions are even spelled out as to what is supposed to happen if the problem does recur.

The last two activities in this phase have to do with leveraging the information just collected in the Problem Solving efforts to
make some other cost saving actions. In many cases these deal with other Problem Prevention and Process Improvement
opportunities.

2. Re-visit the potential causes that were determined not to be the root cause in this case.

Since there are usually several causes that were determined to be potential causes, it makes sense at this point to take steps
to make sure that they do not become actual causes. When the original analysis was done these potential causes were
considered plausible enough to be seriously considered. It must have been thought they could be real. Make sure now that
they don’t become real in the future.

3. Consider if there are any other circumstances under which the problem you just solved could
resurface.

Consider similar situations that might see this problem if you don’t take steps to prevent it. For example, are there similar
processes or sister plants where the same problem could occur? Take steps to prevent recurrence of this in those
circumstances as well. Frequently this points to a system issue. As a final step then, fix the system.

SUMMARY

The key points that summarize good Analytical Problem Solving are these. Phase 1: Develop a clear understanding of the
situation you are addressing: is it truly a deviation from a standard or is it something else? Scope the problem and describe its
symptoms in detail. Phase 2: Analyze the data collected and develop theories for how various possible causes could have
created the problem. Test the theories and determine which is the real root cause by verifying your hypothesis. Phase 3:
Determine the best solution to your problem by identifying a number of alternatives and deciding, which is best. Don’t be
satisfied with only one suggestion based exclusively on experience. Give creativity a chance here. Phase 4: Plan and
implement the solution carefully. Consider the forces at work that may impede your success and deal with them.

ACKNOWLEDGEMENTS

It is impossible to acknowledge all the individuals who have contributed to my acquisition of problem solving knowledge
over the past 17 years of my professional quality career. However, the continuous relationship I have had with Ford Motor
Co. as a consultant and Trainer in their Global 8D process has been invaluable as well as the considerable body of knowledge
contributed to our profession over the years by Kepner & Tregoe and published in their book, The New Rational Manager.
Finally, I would like to acknowledge Clem Goebel for giving me the many opportunities to learn and develop my problem
solving skills by allowing me to train so many people and consult in helping resolve a wide variety of Manufacturing Quality
Problems.