December 2004 Project Management Journal

5
E
ven the best project managers are forever fighting fires. In addition to
routine problems, they occasionally face unexpected disruptions that
may threaten the project and out-of-control crises that could threaten the
organization. Managers who have little explicit problem-solving training must
react to these events as best they can. Project troubleshooting provides a com-
prehensive toolkit that enables managers to react effectively to unexpected
disruptions.
Project troubleshooting is problem-solving applied to projects. Its core
performance engines are problem-solving and high-performance teamwork
(executed by so-called Tiger Teams). Managers are comfortable with problem-
definition tools such as root-cause analysis. But definition is only the first part
of the problem-solving process. Understanding a problems causal factors
sometimes suggests a solution; sometimes, however, it does not.
Solution-finding is the second stage of the problem-solving process. It is
very dangerous to pick a solution, even one suggested by causal factors, with-
out first conducting a disciplined search. I have heard many project managers
say that they understand the cause of problems and believe nothing can be
done to resolve their problems. This statement, however, must be justified.
Case studies show that managers, when under-pressure, often fail to conduct
a disciplined search for solutions and opportunities; as a result, these solu-
tions and opportunities can pass-by unseen. Indeed, this paper presents the
project troubleshooting hypothesis: There is always something that can be
found to improve the project situation.
Tiger Teams are the heart of the project troubleshooting toolkit. Tiger
Team productivity comes from deep, intense, productive conflictan open,
honest struggle to reconcile opposing views. Sequestered offsite and well-suit-
ed for creative problem-solving, Tiger Teams can quickly resolve problems.
While these high-performance teams are most rare, they can be deliberately
set up and nurtured. They are effective in handling both out-of-control crises
and routine everyday problem-solving.
Troubled projects are often viewed as the consequence of management
failure. A common solution is for organizations to employ expert program
managers to assess the program, take charge, and replace current management.
This paper presents an alternative view: Current management possesses the
PROJECT TROUBLESHOOTING: TIGER TEAMS FOR
REACTIVE RISK MANAGEMENT
ALEX PAVLAK, Thales Research, Inc., Severna Park, MD
ABSTRACT
Large long-term projects with many
stakeholders generally entail unforeseen
risks and events that cannot, in principle,
be predicted. Given the impracticality of
pre-planning for every possible contin-
gency, managers must react to inevitable
disruptions, respond to unexpected
events, update risk management plans,
rescope the project, and problem-solve.
Contrary to these all-too-common project
occurrences, management continues to
view the project as a deterministic
process. The belief is that risk can be
anticipated and projects executed as
planned. The view presented in this
paper is that pragmatic project manage-
ment involves a practical balance
between proactive risk management
tools and reactive problem-solving tools.
Keywords: troubleshooting; risk manage-
ment; crisis management; problem-solv-
ing; teams; teamwork.
2004 by the Project Management Institute
Vol. 35, No. 4, 5-14, ISSN 8756-9728/03
6
Project Management Journal December 2004
ule and on-budget.
This size dependency is an impor-
tant observation. It suggests that large
projects are complex systems in the
complexity theory sense: Complex sys-
tems have an inherent level of unpre-
dictability. With large projects, this
unpredictability is the result of several
factors: many stakeholders and the
potential for divergent interests; long
timescales; vulnerability to external
environmental changes; and many
internal interfaces that could potentially
result in unexpected technical surprises.
These numbers are consistent with
commercial capital projects. According
to Lovallo and Kahneman (2003) and
Flyvbjerg, Bruzilius, and Rothengatter
(2003), unfounded optimism, com-
bined with political pressures from
many stakeholders, results in a 10 per-
cent success rate and an average 28 per-
cent budget overrun.
Consider a chart documenting,
over time, the percentage of troubled
U.S. Navy research and development
(R&D) contracts. Thirty years ago,
defense contractors had sound proj-
ect management tools under the
rubric systems engineering manage-
ment. Over the past 30 years, howev-
er, these tools have been only
marginally improved and primarily
in regards to risk management tools,
quality tools, earned value manage-
ment, and computerization. As
Figure 2 shows, these improvements
may have reduced the average num-
ber of troubled projects, but improve-
ments seem insubstantial because 70
percent of programs are still trou-
bled. Over the next 30 years, we can
expect that efforts such as the accept-
basic skills, but needs special tools to
cope with unexpected events.
Total project management
involves a balance between traditional
proactive risk management and reac-
tive project troubleshooting. These two
complementary tasks have different
purposes, employ different tools, and
require different skills. They are com-
patible, non-overlapping toolkits.
What is Project Troubleshooting?
Project troubleshooting is problem-
solving applied to projects. The project
troubleshooting toolkit consists of
those problem-solving heuristics (rules
of thumb) that are relevant to solving
project problems. Since project prob-
lems are highly multi-disciplinary,
project troubleshooting is executed
through high-performance teamwork
by the Tiger Teams.
An auto mechanic troubleshoots
an engine to find out why it will not
start. In this sense, troubleshooting is used
to characterize a deductive effort to discov-
er the root-cause of a problem. With some
problems, the solution is obvious once
the root-cause is understood (e.g.,
replace the fuel pump). Project trou-
bleshooting, however, is broader than
traditional troubleshooting, in that
effort is directed towards defining goals
and overcoming obstructions. Project
troubleshooting involves the total
problem-solving process. Particular
value will come from solution-finding
or creative problem-solving.
Project troubleshooting involves
high-performance teamwork because
project problems are highly multi-disci-
plinary and demand a diverse skill set.
Under the right conditions, teams can
also be adept at finding solutions. The
view here is that the existing project
groups are fundamentally competent,
but may need a temporary turbo-charge
in the form of high-performance team-
work and troubleshooting skills. This
temporary team is a Tiger Team.
Project troubleshooting is best
applied in a firefighting mode: a
focused, temporary, high intensity
effort for the purpose of aggressively
resolving a problem. A trouble-man-
agement effort can be triggered by sev-
eral factors, such as early-warning flags
that exceed a threshold or earned value
analysis pointing to some unaccept-
able deviation from plan.
The Need for Project Troubleshooting
Several studies quantify the magnitude
and impact of project disruptions.
Successful as used in Figure 1
means the project was completed on
budget and on schedule.
In 1999, Keith Buchanan, United
States (U.S.) Assistant Secretary of the
Navy for Research Development and
Acquisition, conducted an earned
value audit of all of the Navys ACAT-I
and ACAT-II (the Navys highest prior-
ity) projects. In a letter sent to me on 9
September 2002, Mr. Buchanan stated
that less than one-third of the projects
studied were completed substantially
on-plan; however, the other two-thirds
of projects despite including among
its team highly trained project man-
agers were seriously disrupted.
The Massachusetts-based research
organization The Standish Group,
which conducts periodic audits of
information technology (IT) projects,
showed in a 2002 audit that only a
quarter of IT projects are successful. In
this report Standish researchers noted
a correlation between project success
and project size: Small projects (under
US$750,000) have higher success
rates; the largest IT projects, however,
are almost never completed on-sched-
SUCCESSFUL
TROUBLED
Success ratio
Figure 1
Today
Defense contracts
%

T
r
o
u
b
l
e
d

p
r
o
g
r
a
m
s
Time
100
90
80
70
60
50
40
30
20
10
0
Perfection is impossible
Figure 2
December 2004 Project Management Journal
7
their job well, they will not encounter
trouble. The record shows that this pre-
sumption is simply not true.
Project management needs a prac-
tical balance between traditional
proactive risk management and reac-
tive project troubleshooting. Proactive
risk management minimizes the occur-
rences of anticipated problems to the
extent that it is practical to do so.
Project troubleshooting, implemented
through Tiger Teams, minimizes the
impact of all unexpected disruptions,
both the large and small.
Risk Management and Project
Troubleshooting: Complimentary Tools
Although todays risk management
tools are developed to avoid problems,
even the most proactive tools have sev-
eral limitations.
Some events are unknown and can-
not be anticipated. These bolt-out-
of-the-blue situations often cause
major disruptions to projects.
From a cost-effectiveness perspec-
tive, preparing plans for every even-
tuality is impractical. Contingency
lists are made and lines are drawn;
but changing circumstances can
cause potential risks that occur
below the line (i.e., risk manage-
ment not funded). These can rap-
idly escalate into major
disruptions. High-scoring risk can
decline in importance, subse-
quently draining resources; new
risks can also appear.
Contingency planning is based
on expectations, tools, and infor-
mation available at the time the
plans are made. From a practical
perspective, these plans influence
perception, blinding the user to
an evolving environment and
contributing to the users tunnel
vision (Weick & Sutcliffe, 2001).
After a disruption has occurred,
these expectations can interfere
with solution-finding.
scriptive: Managers are expected to rig-
orously follow well-defined policies
and procedures. The necessary person-
al skill sets are discipline, planning,
and attention to detail.
Reactive fire-management has the
goal of extinguishing fires. The tools
are physical: hoses, axes, ladders, etc.
Firefighting training is heuristic prob-
lem-solving: Firemen are exposed to
certain classes of fire and taught appro-
priate responses (Flyn, 1996). This is
called recognition-primed decision-
making (Klein, 1996). Firemen are
taught how to fight fires in the same
way that engineers are taught how to
solve problems. Firemen need the
skills to problem-solve: to think and
react under real-time pressure.
Table 1 shows that project man-
agement needs proactive and reactive
parts that are functionally similar to
fire-management. Proactive and reac-
tive management each has different
goals, requires different tools and
training, and demands different skills.
The proactive part consists of tradition-
al risk management programs. The
reactive part project troubleshooting
does not, however, presently exist in
project management. Project trou-
bleshooting is much broader than
root-cause analysis. Project managers
are forever fighting project problems,
yet there is no explicit training about
how to do this. Consequently, every-
one repeats the same mistakes and suf-
fers from the same classical
dysfunctions. In the absence of effec-
tive problem-solving, disruptions spi-
ral into crises that could have been
avoided.
No one would call firefighters
unnecessary because a good fire pre-
vention program exists. It is common
knowledge that in spite of having the
best fire prevention efforts, fires are
inevitable. And yet some senior project
managers believe that they do not need
troubleshooting because if they do
ance of Project Management
Professional (PMP) and OPM3 certi-
fications may provide further incre-
mental improvements. However,
without a revolutionary new
approach, such as project trou-
bleshooting, it is likely that the mag-
nitude of these changes would be less
than the improvements that have
occurred over the past 30 years.
Several observations can be drawn
from this information:
After decades of developing
project management tools, par-
ticularly those created by the
U.S. Department of Defense,
the majority of large projects
remain troubled. These are very
dismal numbers.
The largest projects with the
best and most experienced proj-
ect managers have the lowest
success rates, suggesting that
the underlying cause may
include concerns other than
training.
The U.S. defense departments
project management toolkits are
mature. This suggests that while
better proactive management
may improve outcomes, it is
unlikely to have a major impact,
such as improving the project
performance success rate from
33 percent to 66 percent.
It is possible that a qualitatively
different set of tools may have a
substantial impact on overall proj-
ect performance. This is the poten-
tial of project troubleshooting.
Firefighter Analogy
The need for reactive project trou-
bleshooting is suggested through an
analogy with fire-management pro-
grams. Man has endeavored to control
fire since its discovery. Over millennia,
fire-management systems have become
quite refined. Todays evolved fire-
management systems consist of a prac-
tical balance between two modes of
behavior: proactive and reactive.
Proactive fire-management has the
goal of avoiding fires. The tools consist
of fire codes, structure inspections, and
fire-resistant building materials and
construction methods. Training is pre-
Fire-management
Proactive
Reactive
Project management
Prevention programs
Firefighters
Risk management
Project trouble-shooting
Table 1: Proactive and reactive management
8
Project Management Journal December 2004
In spite of the best-laid plans,
people make mistakes and com-
mit errors in their judgment.
Conflicting political and/or
business agendas often force
poor program decisions.
Updating a risk mitigation plan
in response to changing project
conditions is more difficult and
less effective than the original
pre-program risk plan. Options
are constrained; commitments
have been made; money is burn-
ing at exceptional rates: There
emerges an urgent need for reac-
tive solutions that are not part of
traditional risk management.
Dealing with these events under
real-time pressure only results in
reactive problem-solving.
Risk is a healthy and necessary
consequence of worthwhile develop-
ment projects. A high-risk project
means that managers are pushing-the-
envelope to achieve high-performance
and produce high-value systems. A
low-risk project that is well within the
state-of-the-art generally yields low-
performance, dumbed-down systems.
The project managers goal should not
focus on avoiding risk; the project
manager should strive to manage risk
to prevent risk from disrupting the
project. The aim is not simply risk mit-
igation and risk avoidance; the manag-
ers goal is the total management of
riskproactively and reactively.
Traditional risk management is
proactive and based on the view that it
is possible in principle to plan a per-
fect project. Project troubleshooting
adds the reactive component, based on
the view that disruptive events, partic-
ularly with large long-term projects,
will occur no matter how carefully the
project is planned. Traditional risk
management and project trou-
bleshooting complement each other.
Together, these are powerful tools for
the total management of risk.
Advanced Teamwork Tools
High performance problem-solving
teams effectively tap into creative tal-
ent, integrate outside expert opinion,
find practical creative solutions, pro-
vide authoritative advice, and motivate
the people who execute the project.
Creative problem-solving heuris-
tics work well with groups because the
presence of a group stimulates people
to think about things in a different
way. Stein (1974) points out as oth-
ers have also noted that individuals
can stimulate creativity. An idea
expressed by one person sparks a new
idea in the mind of a second person.
Neither individual would have devel-
oped the new idea in isolation: In this
case, creativity is a group process. If the
group is managed in a way that culti-
vates productive conflict, an open,
honest struggle to reconcile opposing
views emergesfrom this comes a
high-performance Tiger Team.
The analysis skills required for
problem-definition are different than
the creative skills required for solution-
finding. Indeed, few people are very
good at both. We all know creative
people who do not have the patience
and discipline to be good managers.
The opposite also has some truth. The
discipline, decisiveness, and attention
to detail that make a good manager
can inhibit the ability to think outside
the box. Case studies reveal the impact
of this conflict as a difficulty perceiving
options and opportunities. However,
assembling a project team offers the
project manager the opportunity to
employ skills that they do not normal-
ly use during day-to-day operations.
Tiger Teams
The purpose of a Tiger Team is to help
project teams problem-solve. Tiger
Teams are distinguished by both a high
level of coordination and a deep inter-
personal dialog among the members.
Productivity comes from uninhibited
constructive conflict. One example of a
Tiger Team is ExCom, a group of senior
advisors that the late Robert F.
Kennedy, during his tenure as the U.S.
attorney general, led during the Cuban
missile crisis. The Manhattan Project
the effort to develop the atomic
bomb is another example, as are the
management groups that lead many
start-up companies.
For project troubleshooting, the
goal is to build strength in order to
provide existing teams with trou-
bleshooting skills. Lencioni (2002),
who provides an excellent description
of a high-performance team (he talks
about how it works and what it takes
to set it up), states that an effective
troubleshooting team exhibits five
characteristics:
1. Trust and respect: The team
functions as a unit; members
feel free to say what they think
without the threat of reper-
cussions from organizational
politics.
2. Uninhibited constructive conflict:
Total focus on content and ideas.
3. Commitment: Every team mem-
ber participatesno observers
and no holding back.
4. Accountability: Members hold
each other accountable for
results; this promotes a slacker-
free environment.
5. Common goals: Members place
common goals above individual
needs.
Tiger Teams are not work groups.
The purpose of a work group is to
exchange information and coordinate
activities. Working in a traditional
hierarchal structure, work groups are
most effective when the task can be
divided into well-defined functional
components with clean interfaces. For
this situation, work groups are far
more time efficient. A traditional staff
meeting is an example of a work group
experience.
Optimum Tiger Team Size
There is an optimum size for Tiger
Teams: While large groups bring much
experience to the problem, which
makes large group preferable, the size
of the group, as it grows, impairs com-
munications among team members.
Not everyone is fully engaged. A large
group impedes the intense, intimate
level of communication that Tiger
Teams need. As a result, the group
fractures and form subgroups. My
view is that the optimum size of a
problem-solving group depends on
each individuals ability to process
information. Miller (1956) addressed
individual information processing
December 2004 Project Management Journal
9
Groupthink is a leadership failure. The
pressure to conform, to be part of the
team, and to not make waves inhibits
healthy disagreement and critical
thinking. The result is that the group
confuses consensus with a solution
and takes strong positions that are
inconsistent with the external environ-
ment. Groupthink exhibits a number
of classic symptoms that can be used
to test for dysfunction and provide a
basis for mitigation (Beebe &
Masterson, 2000):
Critical thinking is not encour-
aged or rewarded.
Members believe the group can
do no wrong.
Members are too concerned
about justifying their actions.
Members apply pressure to those
who do not support the group.
Members believe they have
reached a true consensus.
Members are too concerned about
reinforcing the leaders beliefs.
Problem-solving Tools
A problem is defined as an obstructed
goal. The project manager must con-
front disruptive events and problems
that demand resolution. Every problem
is defined by three characteristics: goal
state, present state, and obstructions.
These must align with the tasks
that project teams need to perform to
define the problem. In addition, the
hard-core problem-solving process
consists of two sequential stages: prob-
lem definition and solution-finding.
These stages must proceed in sequence.
It makes no sense to search for solu-
tions without first developing a clear
definition of the problem.
The first task is to define the prob-
lem. What this means is that teams
must explicitly state the problem. In
many cases, the project manager has a
pretty good idea of the problem cause
or the present state. In other situations,
the root-cause may not be as clear. In
either event, project managers must
verify the causal factors, the goals, and
the boundaries of the problem. In the
problem-solving community, this
problem definition task is often called
rational problem-solving. The processes
are similar to rational decision-making.
capability and found that people can
keep track of seven things. Fox (1989)
and Osborne (1963) have determined
that the optimum size of a facilitated
problem-solving group is between 7
and 10 active participants.
Participant Selection
Participant selection is important. The
task is to pack as much potential
power as possible into a limited group
size. All critical skill sets and problem
facets need to be represented. In addi-
tion, the Tiger Team needs to include
people responsible for executing the
results, thereby providing ownership
and motivation. Tiger Teams provide
project teams with the superb opportu-
nity to integrate the wisdom and expe-
rience of outside content experts.
Tiger Team Leadership
Effective leadership is a critical compo-
nent of an effective Tiger Team. There
are two basic forms, the traditional
group with a single leader and a group
with split leadership (client/referee).
The traditional group leader man-
ages both process and content. In
order for the team to be successful, it
requires a leader who is an exception-
ally talented individual. This type of
leader derives their authority from
their grasp of the project content. This
leader also possesses sufficient people
skills to motivate strong egos.
However, because traditional group
leaders are not trained in process, their
groups are susceptible to the classic
dysfunctions of small groups (domi-
nated by authority figures, minority
views ignored, premature solutions,
groupthink, focus drift, etc.). One of
the reasons Tiger Teams are so rare is
that this form of leadership is difficult
to effectively implement.
The client/referee form of project
leadership achieves higher project per-
formance by splitting the leadership
role into content and process man-
agers. Clients have primary responsi-
bility for the outcome: They participate
in content discussion, hold content
opinions, and manage content direc-
tion indirectly, through the referee. The
referee is a content-neutral facilitator
who is trained in small group process
and has a content-culture background.
This form has the distinct advantage of
enabling the client to manage outside
of his or her personal skill base. A ref-
eree can balance the clients skills.
Environment
Moving the group to an off-site work
location eliminates distractions,
enables the group to focus on the prob-
lem at hand, and reinforces the impor-
tance of their task. If the emphasis is on
solution finding, an informal living
room environment works better than a
traditional conference room. Passive
observers sap energy and should be
avoided. Suitable audio/visual equip-
ment and note-keeping services should
be provided.
Group Processes
There are a number of standard exercis-
es that facilitators employ to dismantle
interpersonal barriers and encourage
the group to function as an intellectual
unit (Scannell, 1991). Group building
makes a real difference even with scien-
tific and engineering groups. To func-
tion effectively as an integrated unit,
participants need to respect certain
ground rules. These rules of engage-
ment are taught during the kick-off ses-
sion. Here are some examples:
In-and-out listening
Speaking in-headlines
Questioning for
understanding only
Structure offers:
How to ...
I wish ...
Build on the ideas of wishes
Respect roles
Assume value
Listen for newness
No (fatal) flying missiles
Staying loose until rigorous
conditions count
The importance of clearly defined
goals cannot be overemphasized. The
commitment to achieving these goals
must override the need for personal
recognition.
Groupthink
Groupthink is a classic dysfunction
of cohesive groups (Janus, 1971).
10
Project Management Journal December 2004
on the materials at hand. The solution
may need to be both novel and practi-
cal. This is the definition of creativity.
With ill-defined problems, most
of the effort is directed towards defin-
ing the problem. Once the problem is
defined, the solution may be obvious
and require no additional effort. An
example mentioned earlier is a
mechanic confronted with an engine
that will not start. The mechanic con-
ducts a root-cause analysis and discov-
ers that the fuel pump is broken. Once
the problem has been defined, the
solution, replacing the fuel pump, is
obvious. Ill-defined problems can be a
complicated mess requiring consider-
able effort to sort out what the real
problem is.
Problems can also differ by the
number of acceptable solutions. Some
problems have no solutions; some,
only one correct solution; and some,
many acceptable solutions.
Some problems require pure
deductive reasoning: the process of
logically drawing conclusions. An
example of classic deduction is a syllo-
gism, such as all S are M; all M are P;
therefore all S are P. The counterpart to
deductive reasoning is inductive rea-
soning: the process of thinking as
hypothesis testing. An example of pure
inductive reasoning is to find the gen-
eral rule that would enable prediction
of additional numbers in the
sequence: 1, 1, 2, 3, 5, 8, 13, 21, etc....
Most practical problems require a
combination of inductive plus deduc-
tive reasoning. Consider a detective
attempting to solve a murder mystery
(Figure 6). Most of the detectives
time is spent acquiring information
and searching for clues (deductive).
Every so often, the detective must
hypothesize a theory of the crime,
then test the theory against available
facts (inductive).
We have become very good at
reductionist problem-solving strate-
gies: Divide the problem into function-
al components with clean interfaces,
solve the components, and then
reassemble the problem into a com-
plete system. Unfortunately, not all
problems yield to a reductionist attack.
With some problems, the components
Rational problem-solving is a reduction-
ist task that individuals can effectively
perform.
Once the problem is defined, the
second step is to find solutions: to dis-
cover or, if necessary, to invent ways to
overcome the problem obstructions.
The problem-solving community
refers to this task as creative problem-
solvinga disciplined search for solu-
tions. This process consists of two
subtasks: First, to identify all possible
options; then, to evaluate and select
the most appropriate option. Creative
problem-solving often involves induc-
tive reasoning skills and is best con-
ducted by small groups.
The two core problem-solving
tasks are conceptually very simple.
Projects are complicated by the wide
diversity of problems that project
must solve. With some problems,
project managers must direct the
teams effort towards defining the
problem. Once the problem is
defined, the solution is obvious. With
other problems, the definition is obvi-
ous and the project manager must
direct the teams effort towards finding
solutions.
Kinds of Problems
Problems can be classified as either
well-defined or ill-defined. With well-
defined problems, all the effort goes
into finding solutions. With ill-defined
problems, teams must direct consider-
able effort into defining the problem.
An example of a well-defined
problem is the Towers of Hanoi in
Figure 4. These towers are composed of
three same-sized pegs and six differing-
sized rings. The task is to move all six
rings from peg one to peg three as illus-
trated in the figure. The constraint is that
the rings must be moved one at a time,
and a large ring can never be placed on
top of a small ring. For the Towers of
Hanoi, the goal state, present state, and
obstruction are all obvious. All the effort
goes into finding the sequence.
Another example of a well-defined
problem is attempting to open a corked
wine bottle when there is no corkscrew,
as shown in Figure 5. The task is to
pour a glass of wine. The goal state,
present state, and obstruction are all
obvious. The whole challenge is getting
the wine out of the bottle. All of the
effort here is necessarily directed at
solution-finding, inventing some
method to get at the wine. For this
problem, the best solution may depend
Define the problem
A) Goal state
B) Present state
C) Obstruction
Problem solving tasks
1
Find the Solution
A) Develop all possible options
B) Select the most appropriate
2
Rational problem solving
Creative problem solving
Figure 3
Towers Of Hanoi
Initial state
Goal state
Figure 4
December 2004 Project Management Journal
11
are so strongly interrelated that there
is no reasonable way to decompose
the problem, and the whole problem
must be solved at once. These are
what Gestalt psychologists call insight
problems.
An example of an insight problem
is the nine-dot puzzle, as shown in
Figure 7. Given nine dots, the task is to
connect all nine dots with four straight
lines without taking the pencil off of
the paper. The obstruction here is the
imaginary box around the nine dots.
Once one realizes that this box is not a
real constraint and that it is okay to
draw the lines outside the box, the
solution becomes "ah-ha!" obvious.
Lastly, we have problems that are
unexpected surprises in the sense that
there is nothing in our background
that provides guidance as to how to
solve the problem. Unexpected prob-
lems often yield to analogic reasoning
(Holyoak & Thagard, 1999). With ana-
logical reasoning, we think of a source
analog, something that is similar to the
unexpected problem, then look for
similarities and distinctions.
An example of analogic reasoning
is a traveler in an unfamiliar environ-
ment: Thrust into an exotic culture,
unable to speak the language, the trav-
eler makes sense of the new culture by
comparing it with their familiar cul-
ture, looking for similarities and dis-
tinctions. The comparison, while
imprecise, provides useful guidance.
While the conceptual core of the
problem-solving process (problem
definition and solution- finding) is
conceptually very simple, the vast array
of different problem types complicates
the process. Heuristic tools provide
some useful structure.
Rational Problem-solving Tools
Rational problem-solving tools are
heuristic tools that help define the
problem: the goal state, the present
state, and the obstructions. As previ-
ously stated, problem definition is the
first stage of the two-stage problem-
solving sequence.
Rational problem-solving heuris-
tics include root-cause analysis (Gano,
1999), problem specification (Kepner &
Tregoe, 1997), fishbone diagrams, and
constraint analysis, among other factors
(Robson, 1995). A popular application
of rational problem-solving heuristics
involves repairing failed production
lines and resolving technical anomalies
in the nuclear power industry. We have
many poorly documented legacy sys-
tems in use and root-cause analysis is a
good method for figuring out why the
systems are not working.
Today, problem-solving is not a
complete theory. From a practical
point of view, this means that we must
rely on heuristics, better known as
rules-of-thumb. Root-cause analysis is
an example of a rational problem-solv-
ing heuristic. Heuristics are partially
based on research and partially based
on practical experience. Sometimes a
heuristic yields a solution, sometimes
it does not. There is an art to produc-
tively mapping the heuristic to the
problem. The person who can do this
needs to grasp both the strengths and
weaknesses of the heuristic plus the
content culture. Individuals skilled
with the heuristic, but lacking a sound
grasp of the culture, are often unsuc-
cessful. This is the reason problem-
solving heuristics are not more
commonly used with esoteric content.
A close corollary to rational prob-
lem-solving is decision-making, which
involves many of the same skills.
Applying rational decision-making
tools is not magical; rather, the diffi-
cult task is recognizing that a particular
decision is critical and warrants the
cost of a formal process.
Managers tend to be comfortable
with rational problem-solving because
the necessary skill sets discipline,
logic, patience, attention to detail
are consistent with the skills that make
them good managers. Creative prob-
lem-solving is a different story.
The Limits of Causal Analysis
Understanding the cause of a problem
is an important part of the rational
problem-solving process. Sometimes
understanding cause suggests an obvi-
ous solution; other times, it does not.
The fact that causal analysis fails does
not mean a solution does not exist.
Rather, a deliberate search for solu-
tions is necessary.
To illustrate the need for a delib-
erate search, consider the situation
Figure 6: Who-done-it
Nine-dot problem
Nine-dot problem
Successful solution
Figure 7
Wine bottle problem
Figure 5
12
Project Management Journal December 2004
of a drowning woman. To her, the
immediate need is a solution, rescue,
cure. The causal factors about how she
got into that situation are irrelevant. A
search for causal factors would delay
rescueshe should direct all of her
effort to finding a solution to the
problem at hand. From a big-picture
perspective, understanding cause and
introducing preventive measures
would reduce (but not eliminate) the
risk of drowning.
Creative Problem-solving Tools
Creative problem-solving tools are
heuristics directed at finding or inventing
solutions. Solution-finding or creative
problem-solving is the second stage of
the two-stage problem-solving sequence.
Brainstorming (Osborne, 1963),
invented by Alex Osborn in the 1950s,
is the best-known creative problem-
solving heuristic. While classic brain-
storming is appropriate for
lightweight, easily understood prob-
lems, it is based on a principle that has
withstood the test of time and now
forms the basis for many creative prob-
lem-solving heuristicsthe separation
of ideation from judgment. The basic
principle is that judging inhibits the
development of ideas.
Creativity is defined as the ability
to produce solutions that are both
novel and practical. But creativity is
more than the ability to develop ideas.
We all know free spirits who are a
fountain of ideas but who lack the
sense for determining the difference
between ideas that are meaningful and
ideas that are not. The challenge is to
find the one percent of ideas that one
can develop into a practical response
to a problem. Combine that font-of-
ideas person with someone possessing
good analytical skills and mutual
respect and a very productive creative
team would result. This two-person
creative team is consistent with
Osbornes separation of ideation from
judgment. Representative creative
problem-solving heuristics include
nominal groups (Rickards, 1988),
Synectics Excursions (Gordon, 1961),
and lateral thinking (DeBono, 1992).
In practice, creative problem-solv-
ing heuristics are most widely used to
develop ideas for new consumer prod-
ucts and advertising campaigns. These
are shallow problems; the given state is
obvious and there is usually more than
one acceptable solution. The basic
principles of creative problem-solving
have broader applicability: These prin-
ciples are appropriate for using to
solve intellectual problems, where no
one person understands the whole
problem and it is necessary to assem-
ble a group of compatible experts to
provide the necessary understanding
to realize a solution. Applying creative
problem-solving to project trou-
bleshooting represents enormous
untapped potential. To tap this poten-
tial, it is necessary to exploit problem-
solving teams.
Case Studies
Since case studies anchor theoretical
work to the real world, and provide us
with data to test hypotheses, these
studies can help project teams identify
dysfunctions that teams must over-
come. Case studies also provide project
managers with real-world recommen-
dations to consider when solving
problems and help teams define their
need and shape their requirements for
project troubleshooting tools.
A primary case study is TB-23B, a
US$35 million firm fixed-price full-
scale engineering development contract
won by Martin Marietta in 1988. The
contractor failed to meet the self-noise
specification (a limit on acoustic noise
generated by boundary layer turbu-
lences). As a result, the Navy terminat-
ed the contract for cause with triple
damages. On appeal, the termination
was reversed to for convenience with
no damages. I interviewed the people
involved and reconstructed events; I
found that there was more than one
opportunity for both parties to create a
win-win resolution to this dispute. The
parties involved in this case, however,
did not see their opportunities.
The lessons that I learned from the
TB-23B study were supported by my
study of other projects: the Navys A-12
Stealth Bomber Program, which was
cancelled by the Office of the Secretary
of Defense and claimed US$5 billion
in damages (Stevenson, 2001); the
Union Pacific merger with Southern
Pacific that produced a 1997 freight-
car gridlock in the Western U.S.;
Boeings loss of the A-22 Joint Tactical
Fighter; the Manhattan Project; the
Apollo 13 capsule recovery; the space
shuttle Challenger disaster; the space
shuttle Columbia disaster; the Big Dig
... plus many personal discussions with
experienced project managers.
The Project Troubleshooting
Hypothesis
A hypothesis is a speculation that can-
not be proven, only disproved by test-
ing it against data. My project
troubleshooting hypothesis is present-
ed from this perspective:
There is always something that can be
done to improve a disrupted program.
Case Study Lessons
The following general practical lessons
are more or less appropriate approach-
es for working on projects, depending
on the circumstances.
First priority is triage, to con-
tain the damage. Establish pri-
orities, find out what is bleeding
most and fix it.
Be aggressive. Stamp out prob-
lems early and thoroughly.
Beware of the danger of prob-
lems spiraling out of control.
Clearly establish ownership.
Know who has ultimate respon-
sibility for solving the problem.
Defer to expertise. Authority to
make decisions migrates to the
people with the most expertise,
regardless of rank (Weick &
Sutcliffe, 2001).
Deliberately search for early
warning signals. Look for bad
news. A strong devils advocate
participating in early project
reviews would likely have an
impact.
Search for the potential impact
of external events. While the fall
of the Berlin wall immediately
impacted many cold-war budg-
ets, projects often move too
slowly to appreciate impact.
An organization in crisis does
what it knows how to do, and
December 2004 Project Management Journal
13
it does it more intensely. If the
organization is good at disci-
pline, planning, and oversight,
that is what it will do when a
crisis occurs, as opposed to
focusing its efforts on trou-
bleshooting.
Trouble-shoot, dont micro-
manage. There is strong pres-
sure for upper management to
seize control and make deci-
sions that lower-level people are
more competent to make.
Instead, management should
provide the project team with
project troubleshooting tools
and make sure the team follows
the problem-solving basics:
define the goal state, present
state, and obstructions.
The real problem may not be
what it appears to be. The TB-
23B contractor, from the lowest
tech through the most senior
executive, was convinced that
they had a technical problem
and that they could solve it. In
fact, they had reached, if not
exceeded, state-of-the-art quality.
The more serious issue was cus-
tomer relations. This reinforces
the need to verify the goal state.
Test for Groupthink. Both the
TB-23B contractor and the cus-
tomer seemed to suffer here.
The contractor was obsessed
with engineering issues.
Management wanted to hear
"we got it under control." That
is what they heard, even though
it was clear to lower-level man-
agers that this was not true. On
the customer side, the govern-
ment seemed to have unrealis-
tic expectations about the
enforceability of a fixed-price
contract.
The most serious loss was
unforeseen opportunity. On
TB23B, the contractor never
thought to question the validity
of the specification. The con-
tractor never focused on
improving customer relations
and dialog. The contractor never
pressed for a side-by-side test
(new vs. old) that would have
been the best measure of per-
formance. A disciplined search
for solutions can create options
and opportunities.
Poor decisions hurt. There were a
number of decisions on TB-23B
that were made without a full
appreciation of the consequences.
While these decisions hurt the proj-
ect, none proved fatal. On other
projects and crises, poor decisions
can be fatal. Everyone on the team
knows when a decision is impor-
tant and the tools are well estab-
lished; it is a matter of their paying
attention and using the tools.
Outside expert opinion needs to
be integrated. On TB-23B, the
contractor had superb expertise
inside the corporate organization,
but not as part of the project
team. These experts, therefore,
had little impact on the crisis:
Their advice was rendered at too
high a level and was not integrat-
ed by the project team.
Summary
In spite of the best proactive planning,
large long-term projects are subject to
inevitable, unexpected disruptions.
Project troubleshooting mitigates
these disruptions by applying general
problem-solving tools to projects.
Since projects are multi-disciplinary
and have multiple stakeholder inter-
ests, project troubleshooting is most
effectively implemented by Tiger
Teams. Todays management profes-
sionals have no more powerful tool
than a committed team.
Tiger Teams are intensely man-
aged small groups of selected experts.
Their core performance comes from
open and honest dialog, productive
conflict, and the struggle to fit the
problem pieces together to produce a
unified whole.
The Tiger Team task is problem-
solving. Problem-solving consists of
two sequential stages. The first stage
is to define the problem: present
state, goal state, and obstruction. The
THE PROJECT TROUBLE-SHOOTING HYPOTHESIS:
There is always something that can be done to improve a disrupted program.
The challenge is to find it.
The first task is for the project manager to establish clear goals.
The goal provides the basis for selecting Tiger Team participants.
All problem facets and stakeholder interests must be represented.
Test for Groupthink and tunnel vision.
These results will guide you in setting up the Tiger Team.
Keep the Tiger Team size to 7-10.
Most problem-solving and decision groups are too big for effective discussion.
Sequester offsite to focus the group and avoid distractions.
The Tiger Team meeting is organized around the two problem-solving tasks:
First explicitly define the problem: present state goal state, obstructions.
Then conduct a disciplined search for solutions.
Search, explore and develop all potential solutions before judging and selecting.
Do not latch onto a solution without thoroughly exploring all options.
Manage an open, honest, high- intensity discussion - no politics.
Everybody participates - no slackers.
The goal is honest consensus. The whole group integrates and makes decisions.
The group should not be an extension of the leaders opinion.
Use problem-solving heuristics as appropriate.
Consider a content neutral referee/facilitator to manage process and map heuristics
to the problem.
Table 2: Project troubleshooting main elements
14
Project Management Journal December 2004
second stage is to find solutions: first
develop all possible options, then eval-
uate and select.
Individuals (project managers)
can serve as capable analysts, working
out the problem definition stage.
Sometimes defining the problem is all
that is necessary to solve the problem.
Solution-finding, however, is best con-
ducted by Tiger Teams. It is the creative
solution-finding stage of project trou-
bleshooting that managers should find
most useful.
Case studies anchor project trou-
bleshooting to the real world. The pri-
mary lesson is that the most serious
dysfunctional trait of project teams is
an inability to see options and oppor-
tunities. This observation supports the
claim that managers should find the
solution-finding stage of project trou-
bleshooting to have the most value.
Traditional risk management is
proactive and based on the view that it
is possible to anticipate and mitigate
disruptions through planning.
Advocates extend this view, suggesting
that it is possible in principle to plan a
perfect project. This may be true for
short-term and well-defined projects.
However, large, complex, and long-term
projects with many stakeholders entail
unforeseen risks and events that cannot,
in principle, be predicted. It is impracti-
cal to pre-plan every possible contin-
gency. As the project evolves, managers
must problem-solve. They must react to
inevitable disruptions, respond to unex-
pected events, update management
plans, and re-scope the project.
Project troubleshooting through
Tiger Teams adds a disciplined reactive
component, based on the view that
disruptive events, particularly with
large long-term projects, will occur, no
matter how carefully the project is
planned. Traditional risk management
and project troubleshooting comple-
ment each other. Together, these two
approaches provide project managers
with powerful tools for the total man-
agement of risk.
References
Beebe, S. A., & Masterson, J. T.
(2000). Communication in small groups:
Principles and practices (6th ed.). New
York: Addison Wesley.
DeBono, E. (1992). Serious cre-
ativity: Using the power of lateral
thinking to create new ideas. New
York: Harper Business.
Flyn, R. (1996). Sitting in the hot
seat: Leaders and teams for critical
incident management. Chichester,
UK: Wiley.
Flyvbjerg, B., Bruzilius, N., &
Rothengatter, W. (2003).
Megaprojects and risk. Cambridge,
UK: Cambridge Univ. Press.
Fox, W. M. (1989). The
improved nominal group technique
(INGT). Journal of Management
Development, 8(1), 20-26.
Gano, D. L. (1999). Apollo root-
cause analysis. Yakima, WA:
Apollonian Publications.
Gordon, W. J. J. (1961).
Synectics - The development of creative
capacity. New York: Harper.
Holyoak, K. J., & Thagard, P.
(1999). Mental leaps: Analogy in cre-
ative thought. Cambridge, MA: MIT
Press.
Janis, I. L. (1971, November).
Groupthink. Psychology Today, 5,
43-46, 74-76.
Kepner, C. H., & Tregoe, B. B.
(1997). The new rational manager.
Princeton, NJ: Princeton.
Klein, G. (1996) The recogni-
tion primed decision (RPD)
model: Looking back, looking for-
ward. In C. Zsambok (Ed.),
Naturalistic decision making (pp.
285-292). Mahwah, NJ: Erlbaum.
Lencioni, P. (2002). The five
dysfunctions of a team. San
Francisco: Wiley.
Lovallo, D., & Kahneman, D.
(2003, July). Delusions of success:
How optimism undermines execu-
tives' decisions. Harvard Business
Review, 81, 60-71.
Miller, George A. (1956). The
magical number seven. Plus or
minus two: Some limits on our
capacity to process information. The
Physical Review, 63, 81-94.
Osborne, A. F. (1963). Applied
imagination. New York, NY: Scribner.
Rickards, T. (1988). Creativity
and problem solving at work.
Brookfield, VT: Gower.
Robson, M. (1995). Problem
solving in groups. Brookfield, VT:
Gower.
Scannell, E. E. (1991). Still more
games trainers play. New York:
McGraw-Hill.
The Standish Group. (2002).
Chaos report. West Yarmouth, MA:
The Standish Group International.
Stein, M. I. (1974). Stimulating
creativity, v2 group procedures. New
York: Academic.
Stevenson, J. P. (2001). The $5
billion misunderstanding: The collapse
of the Navy's A-12 Stealth Bomber pro-
gram. Annapolis, MD: Naval
Institute Press.
Weick, K. E., & Sutcliffe, K. M.
(2001). Managing the unexpected:
Assuring high performance in an age of
complexity. San Francisco: Jossey-Bass.
ALEX PAVLAK offers project troubleshooting training workshops, short-term consulting to disrupted
projects, and speaker services on the topics of project troubleshooting, problem-solving, teamwork, and
system synthesis. For the past 10 years, he has been investigating the origins and stimulation of high-
performance problem-solving teams. Under grants from National Science Foundation and the National
Institute of Mental Health, Dr. Pavlak has provided problem-solving support to scientific teams addressing
fundamental problems in basic science. Prior to 1992, Dr. Pavlak spent 25 years managing a wide variety
of research and development (R&D) projects. In response to the 1985 quiet Soviet submarine threat, Dr.
Pavlak led a team of scientists & engineers in developing a novel sonar system concept known as TAVA. A
variant of this concept is being built and sold today.