The critical question project managers should ask themselves is not “Should I be doing some risk analysis?” Or,“How much risk analysis should I be doing?” but “How Good is our Problem Solving Approach?” This session will improve your problem solving effectiveness … Guaranteed! Success in the area is essential for project-based organizations. We will review a research based but practical methodology to improve Project Manager’s problem solving effectiveness.
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.
Yesterday
For decades, Problem Solving has been typified by several enduring features:
Problem Were About Things
Problems have traditionally been associated with defective material, poorly performing machines, broken parts, non-performing equipment and malfunctioning components. The best problem solver was the mechanic who had the ability to look under a car’s hood to locate a bare wiring.
Solving Problems Had a Lot to Do With Past Changes
Having a clear recollection of the past was critical to solving problems. Everything was fine, and then, suddenly, something failed. Examining the past to discover the change responsible for the failure was key to solving the problem. Gathering historical information was relatively easy, as the equipment or part had been in use for several years.
Not a Lot of Data to Remember
There were few data points. Usually the most critical historical information was lodged in the head of the employees (project resources and others). The gathering of good and accurate data was a challenge. Often, you had to wait several weeks before solving the problem because of uncertain data.
A Band-Aid Was Always an Option
Most businesses became adept at interim actions, which allowed them to circumvent, patch, or temporarily mitigate the problem. When time and data became available, you could then address the task of finding the root cause and implementing a permanent corrective solution.
These four factors have existed for most of this century. Recently, the nature of the business world, and thus the nature of problems has changed profoundly.
Problem Solving in Projects—Appraisal of the Situation
Information Technology has had a tremendous impact, not only on the business world, but also on how we go about solving problems.
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.
Even if your project is in the automotive industry, solving the problem will more likely require someone in a white lab coat, resembling a neurosurgeon, than someone in a blue greasy coat. Why? Because faulty computer systems produce a lot less grease and oil than leaking pumps.
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.” Information technology made it so much easier to compile, store and report data. Databases, spreadsheets, project management software coupled with ever expanding computer storage capability creative an incentive to accumulate 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
New systems, increasingly sophisticated equipment and the pressure of time combined create a sense of urgency. A broken part can create an escalation of the problem and the shut down of an entire system. 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.
Rule 2: Don’t gather data, Throw it out.
Rule 3: Take on the problem as a team.
Today’s 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 root 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 prove to be a more drawn out problem solving exercise.
Today’s 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
Asking the following question to your project resources will lead you to a useful description of the problem: How can you state, as specifically as possible, what should be happening and what is happening?
However simple or complex a problem may seem at the outset, it is always worth a minute or two to ask: “Can the effect of this problem as we have described it be explained now?” Or, generalized problem statements that begin with such phrases as “Low productivity on …” or “Sub-standard performance by …” or “Burnt out resources on deliverables …” must be reworked into specific problem statement. We must describe what we see, feel, hear, smell or taste that tells us there is a deviation from what should be happening to what is happening.
It is tempting to combine two or more deviations in a single problem-solving effort or try to group related problem into one overall problem. Nearly everyone has attended meetings during which two or more distinct problems were tied ankle to ankle in a kind of problem-solving race. This procedure is almost always inefficient and unproductive.
Second, the Problem Solvers Must Agree Upon the Set of Questions That Will Guide Their Information- Gathering Process
1. In order to further describe the problem, we need to ask questions about its nature, location, timing and magnitude.
• What exactly is wrong? What else could be wrong but isn’t?
• Where is the problem occurring? Where is it not occurring?
• When have you had the problem? When has it been absent?
• How large or widespread is the problem? How large could it be?
Such questioning channels data and begins to sketch the anatomy of the problem.
2. Information will fall within one of these four dimensions.
Within each we ask specifying questions that will flesh out our description of how the deviation presents itself to our senses. Information that does not answer the questions in this section should be thrown out or at best capture on a separate document for potential future consideration.
Any problem can be described by answering the specifying questions—whether the problem concerns a unit, system, part or all of a function or human performance. When we are dealing with a human performance problem, however, we must alter the questions to reflect the fact that we are observing people and behavior, not units.
3. Describing the problem in the four dimensions is the first half of what we want. To conduct a comparison and isolate the problem, we need to identify COULD BE but IS NOT data.
Suppose for a moment that you have two identical potted plants growing in your office. One thrives but the other does not. If you take the wilting plant out of the office and ask someone about the problem cause for its sorry appearance, you will get any number of educated guesses. But if the same person observes that the two plants have not been receiving identical treatment (the thriving plant is on a sunny window; the wilting one, in a dim corner), speculation as to the cause will be immediate and more accurate than it could have been without a basis for comparison. Regardless of the context of a problem, nothing is more conductive to sound analysis than some relevant basis of comparison.
The 11 pairs of questions below will help you decide what information to keep and what data to throw out.
Exhibit 1. Is—Is Not Problem Solving Questions
Third, a Referee Must Be Appointed to Separate the Information That is Factual From That Which is Hypothetical
1. Testing the possible causes.
Possible causes will be considered at this time. By developing all the possible causes, we lose nothing, maintain our objectivity, and reduce the incidence of conflict and disagreement in the explanation of a problem. In the testing step of Problem Analysis, we let the facts in the specification perform the function of judging the relative likelihood of possible causes.
We ask of each possible cause, “If this is the true cause of the problem, then how does it explain each dimension of the specification?” The true cause must explain each and every aspect of the deviation, since the true cause created the exact effect we have specified. Effects are specific, not general. Testing for cause is a process of matching the details of a postulated cause with the details of an observed effect to see whether that cause could have produced that effect. Some possible causes will require rather broad assumptions to pass the test, others won’t pass the test at all and the actual cause will fit all the details of the effect as specified usually without any assumption or with one or two reasonable ones. It fits as hand does to glove, as cause and effect must fit. There is less likelihood of the other possible causes being true. By now in our analysis, we will have identified the most likely possible cause that explains the deviation better than any of the other possible causes. But this most likely cause seldom proves to be, beyond the shadow of a doubt, the true cause. Often several possible causes, including the true cause, carry assumptions that must be true if the cause if to be true. We compare assumptions by asking, “Which cause has the fewest assumptions? Which cause has the most reasonable assumptions? Which cause has the simplest assumptions?” Our selection of the most probable cause may depend as much on the quality of the assumptions as on the quantity.
2. Confirmation is an independent step taken to prove a cause and effect relationship.
To confirm a likely cause is to prove that it did produce the observed effect. Confirmation is possible in most problem situations. What it consists of will depend on the circumstances. Many problems are confirmed by reversing a change to see whether the problem stops. In that case, confirmation provides corrective action.
3. Of course,we may fail. There are two major reasons for failing to solve a problem despite using Problem Analysis.
• Using inaccurate or vague information to describe the problem
• Allowing assumptions to distort judgment during the testing step. The greater the number of assumptions we tack onto a possible cause in order to label it “most probable,” the less chance there is that it will survive confirmation. There is nothing wrong with making assumptions as long as we regard them as such and do not prematurely grant them the status of fact.
Today’s 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. The best organizations institutionalize a common language across offices and countries. They supplement this by helping suppliers adopt the approach, and sometimes they even transfer the approach to their customers. The methodology selected in this context is often less important than its broad distribution and understanding.
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 one 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 Third Step Is to Provide an Environment That, Through Electronic Performance Support Systems, Supports the Use of the Common Methodology Because Often the Project Team Will Be Located in Different Buildings,Cities and Countries
Such an environment will have three distinguishing capabilities:
• An enterprise system that enables everyone to access information and the organization’s very best thinking and experience for solving problems and resolving business issues.
• A shared thinking process (such as the one detailed in Rule 2) that is in the head and hands of every employee, driving the speed and proficiency with which issues are analyzed and resolved.
• A performance system that is aligned with information systems, so that everyone can use those systems to manage and exploit organizational knowledge
The goal of performance support is to achieve immediate results by enabling day-one proficiency.
The problem solving electronic systems used on your projects should have the following features:
• A process coach® = the system expert for making first time use easy and real-time, learning-by-doing possible for immediate results
• A worksheet mode for rapidly entering and viewing data. It supports more experienced users.
• An interview mode guiding the user through each step of the process, emphasizing important practices.
• A process checker® to keep users on track. It can alert users to common mistakes and give advice on how to avoid making them. It can help users make their data as specific and complete as possible. It can also pop onto the screen messages to warn users that they have failed to enter information of that the information they have entered may be incorrect.
• Examples who make it easier for both the first-time and experienced user to learn while doing.
• Online reference = a collection of tips that include more detailed instruction on how to complete the toughest steps of the process.
• Procedural demos offering advice on how to use the software and the problem-solving process in real-time situations.
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 problemsolving 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.
