New rules for problem solving on projects

Abstract

Introduction

To solve seemingly impossible problems, you can't always make a “best guess” and hope for the best. The tendency to jump to conclusions results in costly mistakes. Hunches, instinct and pure intuition may be inspiring, but they can lead to unforeseen problems and erroneous decisions that can lead to the project's death. Problem solving today is a totally different animal.

Introduction

Problem Solving in Projects – Appraisal of the Situation. Consider the following three factors:

• Equipment, components and machinery can no longer be examined in isolation. Everything is linked inextricably with everything else. Everything is part of a more sophisticated system. Gone are the days when problem solvers examined the poor performance of a lonely die press and found a misalignment. Today, poor performance is more likely to be caused by a system software glitch than a mechanical defect.
• The fascination with total quality control did much to produce better products but also contributed to the deforestation of North America. The mantra of this movement is “data”. The effect of this data on problem solving within projects is significant. No longer is the challenge to seek out missing information. Now the project manager is awash in data on any problem issue and the challenge is to find the relatively small portion that can be converted into useful problem solving information.
• Organizations demand and reward immediate action. The bias for immediate action is so great that thought before action is sometimes overtly discouraged. Just do it, but do it right now.

The apparent erosion of problem solving capability is less a cause for despair than a call to reexamine the essence of one of project management's “foundation skills”. To make a foundation skill like problem solving a core competency for project managers, it requires a redeployment of these skills and processes throughout the organization. This type of effort can be characterized by a series of “new rules”.

Rule 1: The initial objective of problem solving within projects is not to solve the problem, but to keep from doing something stupid.

The urgency in problem solving today leads to a keen desire for quick, often erroneous fixes. In an increasingly pressure-packed world, there is little time to find the true cause of many problems. Yet, acting on the wrong cause can often have more devastating results than the problem itself.

Project managers must look at problem solving with the first objective being the quick elimination of possible causes, rather than the discovery of the true cause. This objective would seem to be counterintuitive, yet in practice this approach is the one factor that makes the difference between a project back on track in no time and an evil of even greater proportions. This rule will allow project managers to work without the distraction of favored suspects. It will allow for immediate project progress in what may have otherwise proven to be a more drawn out problem solving exercise.

Rule 2: Don't gather data, Throw it out

If quick action taken against the wrong cause can be damaging, delays that result from interminable information assembly can be devastating. People tend to become entrapped in their own search for data, specifically when an entire sub project or a major deliverable is at stake.

First before any data gathering is done, there must be a uniform agreement about just what the problem is. Second, the problem solvers must agree upon the set of questions that will guide their information-gathering process. Third, a referee must be appointed to separate the information that is factual from that which is hypothetical.

Rule 3: Take on the problem as a team.

Gone are the days when a lone project manager or problem solver can, after careful analysis, confidently declare that the cause has been found. Because problems can rarely be neatly delineated by single functions or operations, it is equally rare that they can be solved by individuals, or even functional teams. First it is essential that the same methodology be used throughout the organization. When a team is assembled from many parts of the organization, each with different methodologies, the process often comes to a standstill. Their deliberations become more about agreeing on the approach.

A second step is to create a cross-function problem response mechanism within the organization. While the effects of a problem may have been seen in on deliverable of the project, the cause may actually be located in another. Invariably, we have found, problems are “owned” by the area/team in which the effects are observed – a double whammy if that area/team doesn't own the cause.

The Process

We will use the term process in our discussion today to define the Problem Analysis Method (PAM).

If we think of paper making in terms of the classic process model –Input-Process-Output or Result- we know that in order to produce a quality sheet of paper we need quality inputs – fiber, energy, water, chemicals, labor, etc. To convert those inputs into a quality sheet of paper requires quality processes – chipping, pulping, forming, drying, etc. If any one of these elements in the process model is not functioning well, the results are predictable.

So too it is with a rational thinking process. Here our output or result is a problem solved. The inputs are the information, knowledge, judgment, experience that you and your colleagues bring to situation. We take those inputs and run them through a set of processes that help us to gather, sort, organize, analyze, and confirm the inputs through effective questioning. And effective questioning is the key to good problem solving.

The same quality requirements are true for the Problem Solving model - quality inputs plus a quality process equals quality results. We'll now examine how a systematic questioning process embodied in Problem Analysis Method (PAM) can be used on a real problem, the case of the “Chemical in the River.”

The story goes like this…

In Mid-May, while the Plant Manager was out of town at a meeting, the General Superintendent received a call from the State Department of Natural Resources (the DNR). The DNR administrator said:

“We have water quality monitoring stations above and below your plant in the River (Exhibit 1). The station below your plant detected Chemical in the water, and inspections revealed that the Chemical is killing fish. We have traced the Chemical to your facility. You need to clean up the source of this Chemical immediately.”

Exhibit 1 – Biopharma Incorporated Facility

Let's now look at the Problem Analysis process and demonstrate its use with the Chemical in the River Case.

Problem Analysis Method is a tool to help us discover the evidence we need to find the root cause of a deviation, negative or positive, and help us avoid making false conclusions because that cause seems to make sense; or because; it's got to be the same situation as the last time we had this problem; or because some expert cries “Eureka, I have it!”

We use the term deviation to describe a problem. A deviation is any difference from expected performance or standard. This expected performance could represent the performance of a machine, a piece of equipment, a system, a process, or even of an individual or group of individuals.

When the observed, recorded, or reported performance falls off from the expected performance we have a deviation.

While we tend to think of deviations mostly in negative terms, they can be positive as well and we can use PAM to find the cause of a positive deviation to determine if we want to replicate the actual performance.

Let's now take a more detailed look at the PAM process.

PAM starts with a good, clear definition of what we are dealing with. We call it a deviation or Problem Title. The deviation statement contains an object or group of objects – what thing has the problem – and the deviation – what is not performing to standard, is broken, is under-performing or does not work.

It's here where the operator or maintenance tech or the individual who is closest to the action is of major help in developing the deviation statement. Who knows better how a machine or piece of equipment or process is supposed to run. Is it supposed to run hot or cold; is it supposed to vibrate or not; should it be making this sound or not?

And we want to isolate the deviation statement to one thing, one deviation. If there are multiple problems, separate them out and prioritize, but work on one object, one deviation at a time. You will be much more effective this way than trying to solve multiple problems at once.

From the Chemical in the River Case, here is our Problem Title, “The River has Chemical in it.” Simple, yet it provides us focus on the problem at hand. There is a lot of information we don't have – such as what kind or Chemical, or how much Chemical – for example, but we will see in the next step, Specify the Problem, we will ask questions to gather that and other key problem facts.

Problems have causes, problems have effects. When a problem occurs we see, hear, feel, taste the effects of the problem. We use unique and very specific questions to collect a list of the relevant data and facts about the problem. These structured questions help us understand where the problem is occurring, or its location, when it has or is occurring or its timing and how big it is or its magnitude (Exhibit 2).

Let's review. The Problem Title provides us focus and direction for our problem solving effort. Then we gather a list of the problem facts, or the effects of the problem that describe what the specifics of the problem, the location of the problem, the timing of the problem, and the magnitude of the problem. We collect this data from discussions with others, from manual or electronic data files, from customer complaints.

Using this data, along with our knowledge and experience, the knowledge and experience of others, we formulate possible root cause statements that we believe explain the facts of the problem. In our next step we will test the possible causes against the problem facts to see if they can explain the deviation.

Exhibit 2 – Facts gathered about the problem

Rather than just guess at the possible root cause, we suggest a much more analytic process. We call it “destructive testing.” We take the possible cause statements and test them against the problem facts to see if the possible root cause explains the facts.

We test against the problem facts until we get a no answer, that is, until the cause does not explain a pair of data. Again, this is destructive testing. We want to eliminate causes that don't make sense, not find reasons to support them. In our fast-paced business environment we have neither the time, resources nor should we have the inclination to support causes which just don't make sense.

Sometimes we have to make assumptions for a cause to be the root cause, but those assumptions should be as few and as reasonable as possible.

Ideally, the Analysis step (Exhibit 3) in the PAM process will eliminate all the possible causes which do not explain the facts, leaving you with one possible root cause to verify. But in reality, there may be several possible root causes that pass through the test with or without assumptions made.

Exhibit 3 – Analysis Step, Testing the root causes

The final root cause is the one that has no or the fewest number of assumptions, has the simplest assumptions, has the most reasonable assumptions or has assumptions that make the most sense.

While this seems like a plausible explanation of how the unprocessed chemical got in the river, before we make that phone call to the Chemical supplier and take corrective action, we ought to confirm that we have in fact discovered the Root Cause.

This confirmation step is needed to avoid wasting valuable and resources and chasing down blind alleys. We want to confirm we have the Root Cause in the surest way by verifying any assumptions we've made that impact our Root Cause, or by going out and observing the cause at work if we can, or by conducting some kind of experiment to demonstrate the cause-and-effect relationship we believe is occurring.

One thing we have found over the years is that skills alone are not enough to “win the day.” What is required is a combination of the right people with the right skills, the commitment to employ these skills throughout the organization to establish a common approach and a common language and a determination to act.

Conclusion

The challenge is not so much to prove Murphy wrong (“Anything that can go wrong will go wrong”). The challenge is to be less intimidated by the inevitability of a problem. Building Problem Solving skills as a core competency for project managers will allow organizations to approach problems with confidence in their abilities to resolve them quickly and effectively.