Forget About Causes, Focus on Solutions
This training module was taken from the article "Forget
About Causes, Focus on Solutions" by Fred Nickols, and it is being used
with his permission. For more interesting articles you are encouraged to
visit his web site at
The subtitle of this
paper does not mean that solutions should run around in search of problems.
Rather, it is meant to draw attention to the obvious, namely, that to solve a
problem you must take action, you must intervene, you must change something with
a purpose or outcome in mind. The search for a solution is always a search for a
course of action that will produce the desired results. This is true regardless
of the cause of the problem, if a cause can even be said to exist.
The gaps in results
that give rise to the problems we attempt to solve come about in various ways —
five to be specific. In many cases we are not able to do anything about the
origins of the problem and must content ourselves with bringing about the
desired results through some avenue or agency other than that originally used.
In short, as a purely practical matter, we should generally forget about causes
and focus on solutions.
But before examining
the ways in which problems come about and the general form of their solution,
let us first spend a little time examining the basic notion of a gap as the
basis for defining a problem.
The Murky Origins of
It is not clear who
originated the concept of a problem as a discrepancy between actual conditions
or what is and desired conditions or what should be.
Charles Kepner and
Benjamin Tregoe lay claim to it in their 1965 book, The Rational Manager. In its
annotated bibliography, they credit Herbert Simon with independently developing
the same concept at about the same time.
The reference to
Simon leads to research that Allen Newell, J.C. Shaw, and Simon were conducting
at the Rand Corporation in the 1950s. Newell, Shaw and Simon were bent on
developing a "general problem solver," a computerized problem-solving program.
Their research culminated in Newell and Simon's 1972 book, Human Problem
John Dewey, the great
educator, alluded to discrepancies as an element in the definition of a problem
in his 1910 book, How We Think. Dewey's formulation of the problem-solving
process was so sound that psychologist J. P. Guilford once observed that, with
minor modifications, Dewey's steps have been rather persistent over the years.
Roger Kaufman, a
noted authority on needs assessment, has been writing about needs as
discrepancies in results for at least 35 years. Kaufman's view differs from most
in that he uses a discrepancy in results to define a need and he defines a
problem as a need that has been selected for resolution.
It seems impossible,
then, to give credit to a single party for creating the concept of a problem as
a discrepancy between what is and what should be. So, with credit given where
credit is due, we can turn our attention to a much more important matter;
namely, the ways in which gaps in results come about and what these origins say
about the general form of the solution.
what is and what should be come about in four different ways, two of which can
combine to form a fifth. These are briefly discussed and illustrated below.
Gap # 1: Something's Gone Wrong
1 Guilford describes
Dewey's formulation of the problem solving process as consisting of the
following five steps: (1) a difficulty is felt, (2) the difficulty is located
and defined, (3) possible solutions are suggested, (4) consequences are
considered, and (5) a solution is accepted (p.313).
Figure 1 - Something's gone wrong
This gap in results
happens when things are going along just fine, what is and what should be are
aligned, and then - Wham! - something changes and performance
deteriorates, usually in a hurry. Blown fuses and tripped circuit breakers offer
examples close to home. So do flat tires. "The computer just went down," is a
phrase that should be familiar to many readers. This something's-gone-wrong
problem is the kind on which Kepner and Tregoe lavished most of their attention.
It exemplifies the category Harvey Brightman labels "operating problems." An
important characteristic of this kind of problem is that the deviation in performance
is from a previously attained level or standard of performance.
The search for a
solution in this case is to first attempt to identify the change or changes that
account for the fall off in results. If it can be corrected, it makes eminent
good sense to do so. If it can't, some other means of closing the gap will have
to be employed.
Not all discrepancies
come about because of equipment, component or personnel failure, or other
unwanted or unforeseen changes, and not all performance standards have been
previously attained. There are other classes of problems to be considered.
Gap # 2: Raised Expectations
As Figure 2
illustrates, a discrepancy in results also occurs when expectations are raised.
Suppose a firm has been enjoying a steady but un-spectacular rate of return on
investment (ROI) of seven percent. Suppose a new CEO takes the helm and commands
a doubling of this figure. A discrepancy in results exists. There is
definitely a problem to be solved. But it owes to raised requirements, not
because something's gone wrong. Any search for cause will be futile unless
someone is willing to point the
finger at the new CEO yet, the task of achieving the new goal remains.
Figure 2 - Raised Expectations
This class of problem
is neatly captured in Rajat Gupta's response to questions regarding the kinds of
changes he planned on making when he became the new managing director of
McKinsey & Company: "Nothing is broken," he said, "But our aspirations are
An interesting and
challenging variation on this class of problem occurs when expectations or
standards are in a state of flux. In such circumstances, the goal is a moving
The search for a
solution in this case amounts to a quest for new ways of operating or doing
business. There is nothing wrong with the old ways or old system; indeed,
everything is (or was) working just fine. But the old system and the old ways
won't produce the new results. Change, innovation, invention, redesign and
perhaps reengineering are called for.
deteriorate and expectations are raised at the same time. This produces the next
category of gap.
Gap # 3: Double Whammy
Cost center and
division managers are intimately familiar with this class of problem. It is
referred to in some circles as "a double whammy" and in others as "caught
between a rock and a hard place." Other terms for this class of problem include
"between the Devil and the deep blue sea,"
Figure 3 - The "Double Whammy"
"between the hammer
and the anvil," "between the sword and the stone," and "between Scylla and
Charybdis (the man-eater and the whirlpool). We have so many terms for this
class of problem because such problems are so commonplace. A new system is
rolled out, it doesn't work, and service delivery suffers as a result. At the
same time, budgets are cut, and demands for improved service are made. On a
grand scale, new competitors gobble up market share, eroding revenues and
profits, and casting doubt on the value of the existing product line. Meanwhile,
shareholders and analysts press for improved financial performance. (It is
tempting to say that managers and executives who haven't faced and surmounted
this class of problem haven't been adequately inducted into the mysteries of
Just as this gap is
created by a combination of circumstances, it is possible that the general form
of the solution will entail a combination of measures, some amount of correction
or remedying of things gone wrong coupled with some amount of innovation and
invention. Then again, it is also possible that it is not worth the time and
trouble to try and fix things and so the general form of the solution will be
that of redesigning and reengineering the system in question.
The first three cases
we have examined all involve the creation of a gap as a consequence of some kind
of change in the system. In other words, up to a certain point, conditions have
been acceptable. In the next instance, this is not the case.
Gap # 4: It Never Did Work Right (A "Day One" Problem)
More than one new
system has failed to perform to expectations or requirements. The same can be
said for many new products or procedures. Many problems can be cited as
examples of what Kepner and Tregoe call a "Day One" problem, a gap in results
that has existed since the system, product, or procedure was first introduced.
Perhaps the best-known example of this kind of problem is "the lemon," a
brand-new automobile plagued by one problem after another. The process called
"systems development" has produced its share of computer-based processing
systems deserving of the label "lemon." Some of these are now known as "legacy"
systems. Poor specification, poor design, and poor execution are generally the
Figure 4 - It Never
Did Work Right
Here is a situation
in which the root cause analysis so favored by TQM devotees can play an
important role. Clearly, there is something wrong with the system, be it design
or execution. One avenue of attack is to take it apart, a piece at a time, and
find and fix whatever is not functioning properly. However, another approach is
to simply scrap it and start over, to redesign and rebuild the system.
The four classes of
problems presented so far have two qualities in common: (1) a history and (2) an
existing system. The next and last kind has neither of these qualities.
Gap # 5: The Basic Engineering Problem
feature of this class of problem is its lack of history. In addition, there is
no existing system to troubleshoot or diagnose. Results have been specified for
the very first time. The goal is to design, build, install, operate, and
maintain a new system that will produce the desired results. Any solution to
this class of problem must be "engineered" in every sense of the word
Brightman, this situation calls for "strategic problem solving." Clearly,
solving this kind of problem is not a matter of figuring out what went wrong or
of figuring out how to cope with changed expectations. It most certainly is not
a combination of the two. There are no "root" causes to be unearthed. It is this
class of problem that most clearly calls for the first-time creation or
engineering of a solution. It is this class of problem that also most clearly
calls into question the concept of cause.
The Concept of Cause
For many managers,
executives, consultants, and academics, the concept of cause is defined in two
basic ways. First, we will examine the Kepner-Tregoe view, then the Total
Quality Management (TQM) view.
In the first edition
of The Rational Manager, Charles Kepner and Ben-jamin Tregoe defined the cause
of a problem as an "unwanted change." In so doing, they confined their
problem-solving method to the "some-thing's-gone-wrong" kind of problem
represented by Gap 1 above. Sixteen years later, in The New Rational Manager, Kepner and Tregoe maintained their original definition of cause, but
acknowledged circumstances in which the should be condition has never been
attained. Kepner and Tregoe termed this a "Day One" problem. It corresponds to
Gap 4, the "It-never-did-work-right" class of problem.
Under the precepts of
TQM, the "root" cause of a problem must satisfy three criteria. First, it can be
shown logically to explain the problem, that is, a cause-and-effect sequence can
be traced. Second, it is directly controllable. Third, the effects of correcting
it can be determined.
Root causes are not
necessarily causes in the Kepner-Tregoe sense of unwanted changes, they are
factors that contribute to the current state of affairs. In complex situations,
the number of contributing factors is enormous. To isolate those few factors
that can be said to "drive" a situation is the essence of effective analysis.
That is what makes this approach so useful in addressing a Day One problem or in
wringing continuous improvements out of systems that are essentially performing
As an area of
professional practice, TQM is blessed with numerous tools and techniques for
eliciting and organizing knowledge of the factors affecting results. The
Ishikawa or "fishbone diagram," tree charts, flowcharts, process charts, and
various means of displaying statistical data come immediately to mind. But,
whether or not the TQM tool kit contains the kinds of tools needed to engineer
solutions to business problems from scratch is debatable. In general, in this
writer's opinion, TQM tools support refining and improving upon existing
business processes, but not engineering or reengineering new ones.
Most important, root
cause analysis simply does not apply to problems created by new requirements or
to novel situations. It is clearly most relevant when something’s gone wrong and
to the Day One class of problem.
Regardless of the
origin or cause of the gap in the figures above, the goal with respect to all
problems, regardless of how they originate, is to close the gap, to get from
where one is to where one wants to be. This means all problems can be approached
from the perspective of engineering a solution. But not all problems can be
treated successfully by searching for, finding, and fixing causes, because not
all problems have causes. Moreover, not all causes are controllable or
correctable. When the stock market crashed in October of 1987, there were
doubtless many people who would have liked to put things back the way they were
the week before. That was clearly impossible.
There is an important
point to keep in mind here. Pointing to causes beyond one's control is not an
acceptable response. That things go wrong is understood. That these things very
often cannot be corrected is also understood - and irrelevant. The task of the
effective manager and executive is to innovate, to invent new ways of achieving
improved results at lower costs. Pleading causes beyond one's control is to beg
two tasks that are ever at hand: figuring out how to achieve the results desired
and then achieving them. There are no excuses. Solutions must be engineered even
if causes can't be found or aren't fixable.
A problem exists when
there is a requirement for action coupled with uncertainty regarding the action
to take. The requirement for action is generally rooted in a discrepancy between
what is and what should be. This discrepancy alone is not sufficient to launch a
problem-solving or solution-engineering effort. Not all discrepancies in results
are reason for concern and not all are worth remedying. So, in addition to the
discrepancy, there must also be dissatisfaction coupled with determination to
do something about it.
To solve a problem,
something must be changed. In complex systems, change is typically indirect.
Results are achieved as a consequence of intervening at points that are often
far removed from those where results are measured. Revenue, for example, is not
increased directly, but is increased as the result of actions such as price
increases (or price reductions), sales promotions, better-targeted advertising
and so on.
When engineering a
solution, the search is not for the cause of the problem but for those factors
that, if changed in certain ways, would produce the result desired. This search
is made more efficient and effective if it is carried out by systematically
examining the structure of the situation in which the problem may be said to be
systematically through the structure of a problem for the factors to change to
achieve some desired result is the essence of a goal-oriented approach to
problem solving called "solution engineering." Solution engineering is marked
by its intense focus on the solved state, on achieving what should be without
worrying a great deal about why what is exists. In short, with the exception of
the first gap above, Solution Engineers generally forget about causes and focus
After completing this instrument, provide your Staff ID number, click you work
"content area" and "job location". Forward to the Training Department. Your name
is verification that you have read and understood the content of this module
and have completed this learning program in good faith, and are
willing to practice the principles outlined.