Choosing the Right Problem Solving Approach

Some people view problem solving training as a commodity. They believe it doesn’t make much difference which problem solving approach people are trained to use as long as it is systematic. This writer disagrees. The problem solving approach used, as is the case with any other tool, ought to be selected to match the requirements of the task at hand. This paper identifies three different problem solving tasks—repair, improve, and engineer—and presents examples of each to illustrate their differences . No matter the approach, success hinges on examining the structure of the situation in which the problem is embedded. The article concludes that it does indeed make a difference which problem solving approach people are trained to use.

Does it make any difference?

Does it make any difference which problem-solving method people are trained to use as part of efforts to improve quality and process performance? A recent discussion on the quality list on the Internet culminated in two general conclusions: Any systematic approach is better than none, and as long as people are trained to use one that is systematic, it really doesn’t make much difference which one it is. These conclusions remain undisputed for some time. Finally, I posted a message asserting that the second conclusion was not true. I claimed that it does make a difference which problem solving approach people are trained to use.

[ The quality discussion list on the Internet was mentioned in the January 1995 issue of Quality Progress (Jim Clauson, "Cyberquality: Quality Resources on the Internet," p.46). Anyone who has e-mail who is interested in serious discussions of issues pertaining to quality and process performance improvement would be well served by subscribing to that list. The full name of the list is Quality: Total Quality Management (TQM) in Manufacturing and Service Industries. With e-mail access to the Internet, you can subscribe to the list by sending the message "subscribe quality" followed by your first name and last name to the address listserv@pucc.princeton.edu.]

Specific tools for problem-solving tasks

Tasks are best performed using the proper tool. Tools form the bridge between work and working; they link the performer to the task. (Drucker, 1973). In many cases, tools shape and define the task itself. A hammer, for instance, shapes the task of hammering just as a saw (especially the type of saw) shapes the task of sawing. If problem-solving tasks differ, then for optimum performance, the tool or method must differ as well. The choice of a problem-solving method should be based on the same principle that underlies the selection of any tool: choose one appropriate for the task at hand. To use the wrong tool is to shape task performance in an unproductive fashion. Examples of the main types of problem-solving tasks, followed by each task’s proper problem-solving method, are described below.

Example 1: Repairing a malfunctioning air conditioning system

Matt returned home from work one hot summer day to discover that his air conditioning system was not working. He also discovered water-soaked carpeting in the basement, so he called an air conditioning repair service and cleaned up the water while waiting for the repairman to arrive.

The repairman informed Matt that the housing for the fan that forces cool air through the vents had become filled with water, which prevented the fan blades from turning and caused the motor to burn out. The motor would have to be replaced. When Matt asked how water got into the fan housing, the repairman told him that the system was low on Freon, which caused excessive evaporation and water spillage.

The repairman completed his work and turned on the system. It appeared to work properly. Matt paid him and the repairman left. A couple of hours later, Matt discovered that water was once again leaking from the air conditioning system. He resolved to tackle the problem himself.

First, he drew a simple diagram of the air conditioning system, much like that shown in Figure 1. Then he asked himself, "What should be happening here?" He was not an expert on air conditioning systems, but he knew enough to realize that condensate from the evaporator was supposed to run down into the drip tray, out the elbow joint, and down the drain hose to the sump. Removing the cover plate from the top of the air conditioning system casing, Matt peered inside and saw that the drip tray was filled to the brim, and water was dripping down inside the casing. He pulled the drain hose off the elbow joint. Nothing was coming out. Using a screwdriver, he poked around inside the elbow joint, dislodging a large glob of rusty, flaky material. When it came out, a sudden rush of water poured out as the drip tray emptied. After thoroughly cleaning the drip tray, Matt put the hose back on the elbow joint and closed the air conditioner casing. No further water leakage occurred during the next several days. The problem was solved.

Repair tool: Technical troubleshooting

As this air conditioning case illustrates, the repair approach is appropriate when things go wrong. Typically, this approach is needed when some unwanted change, event, or circumstance accounts for what is usually a sudden deterioration in results or performance. A part fails, an unforeseen circumstance crops up, or a procedure isn’t followed. In Matt’s case, it was the accumulation of rusty residue that led to a plugged elbow pipe. The objective in such cases is to put things back the way they were.

The appropriate problem-solving tools for a repair job consist primarily of fault isolation techniques. Identify the conditions that should or should not exist and then narrow the search for the fault or malfunction by focusing on where and when the problem appears or doesn’t appear. The failed component can be corrected or compensated for. This type of problem often appears suddenly, and the fact that it generally is due to an unwanted change helps in finding and fixing its cause. A simple visual inspection in physical systems often reveals the cause of this kind of problem.

[ See Charles Kepner and Benjamin Tregoe’s, The Rational Manager for what is undoubtedly the best-known of the troubleshooting approaches applied to solving business problems. Millions of managers around the world have been trained in this rational, analytical approach.]

Example 2: Improving an unacceptably high reject rate

Kari, the new supervisor of an applications processing operation, was concerned about the operation’s performance. Her company administered applications for a national medical aide certification program. When the completed application forms were received, they were batched, scanned, and edited. On average, from 60% to 70% of these forms were failing one or more edits. To use her boss’s words, "The reject rate is unacceptably high." Making matters worse, this reject rate led to delays in processing and subsequent complaints from applicants and the state agencies sponsoring the program.

Kari visualized the operation as looking similar to the diagram shown in Figure 2. After an initial investigation, she realized the operation itself was functioning correctly because the reject rate in editing was traceable to errors on the forms themselves, not to mishaps in batching, scanning, or editing.

Figure 2 - Kari’s Visualization of the Reject Rate Problem

The errors on the forms fell into two general categories: incorrect codes, and gridding errors. Gridding errors occurred when applicants filled in the wrong "bubbles" on the scannable form. Her analysis of these gridding errors revealed no discernible pattern, so Kari attributed them to carelessness. The coding errors, however, were a different matter. Although these, too, showed no particular pattern, Kari knew the applicants were provided with rosters listing medical care and medical care training facilities. The rosters provided codes that applicants were supposed to use on their application forms. One code indicated the applicant’s current place of employment, and one indicated the place where he or she had received training. In the edit phase of Kari’s operation, these codes were checked to ensure they were valid. One-third were not.

Kari decided to review the instructions provided to the applicants. She found they were incomplete, poorly written, and not keyed to the items on the form.

Next, Kari obtained a copy of the code list used by the applicants. To her dismay, it turned out to be a copy of the one used by her staff. The staff occasionally looked up code numbers to see which facility was indicated, so the code list was in numerical order. The applicants, however, started with the name of a facility when looking up the code number. A list for the applicants’ use should be in alphabetical order.

Kari’s solution to the reject rate problem consisted of a two-pronged course of action. First, the instructions were completely rewritten. The new instructions were keyed to the items on the form and included examples showing the proper and improper completion of each item. Also, a section explaining the consequences of mistakes by the applicants was added (delays in processing, delays in obtaining a license, delays in obtaining employment).

Second, an alphabetically organized code list was developed. The new instructions and code list were distributed to each medical care and training facility supported by the program. Two months after Kari’s solution had been implemented, the reject rate stood at less than 9%.

Improvement tools: Kaizen, continuous improvement, TQM, and reengineering

The improvement approach illustrated in the previous section is used when the objective is to improve current levels of performance. The improvement sought might be incremental and continuous, or radical and discontinuous. Several characteristics distinguish this approach from the repair approach.

First, when improvement is the goal, the causes that are sought are those factors that account for current performance levels. Generally these are the same factors that, if changed, would lead to improved performance. The objective is to unearth the root or underlying causes of current performance. The root causes of the high reject rate were poorly written instructions and an improperly organized code list.

Improvement hinges on reliably and correctly explaining and accounting for performance in complex systems. Simple visual inspections are not adequate. Frequent, thorough, painstaking, disciplined, and scientific work is required. Control charts, scatter plots, cause-and-effect diagrams, and other tools and techniques commonly associated with total quality management (TQM) and continuous improvement can be used. Solutions are data driven.

Reengineering efforts frequently lead to radically different systems and processes. Existing systems and processes aren’t really reengineered; they are replaced. New systems and processes are designed and built from scratch. The causes of performance problems in the old systems and processes are of interest only to ensure that the same problem factors aren’t included in the new systems and processes.

[The past several years have seen a spate of books on reengineering, however, the first two are perhaps the definitive statements. Michael Hammer and James Champy, Reengineering the Corporation (New York, NY: HarperBusiness, 1993), and Thomas Davenport, Process Innovation (Cambridge, MA: Harvard University Press, 1993).]

Example 3: Engineering a method for cleaning up databases

A $350 million service bureau business needed to improve its performance because of its competitors’ success and insistent customer demands for improved service at lower costs. As part of the company’s effort to improve its performance, one of the computer-based product support systems it operated and maintained for a client was being moved from a minicomputer to a local area network. This required moving approximately one million records from a flat-file arrangement to a relational data base architecture. Additional moves would occur in the future. In the existing flat-file structure, each record contained customer and transaction data.

Customer data often varied from record to record in the flat file. Joan Barnes, for instance, might be listed as J. Barnes, Joan C. Barnes, or, in the case of data entry or gridding errors, as Joan Batnes or Joan Baqnes. The idea behind the new relational data base was to enter customer data only once, while the transaction data base could have many records for a single customer. Until the customer data were made consistent, many customers would be treated as different people in the new data base and service would suffer.

To make the customer data uniform, a task force proposed that a hard copy printout of the entire data base be subjected to clerical review. Corrections would be noted on the hard copy and, later, keyed into the existing system via its update function.

The proposed approach was unacceptable to the product manager. It would take too long (at least six months), cost too much ($360,000), and it wouldn’t yield a new data base of sufficient quality. This last shortcoming arose from the nature of the key, or indexing scheme, used in the flat file. The key consisted of the customer’s last name, first initial, and date of birth. Coupled with the data variations mentioned earlier, the use of this key meant that many records for the same customer would be so far apart in a printout that reviewers would fail to recognize they were dealing with the same customer.

Stymied, the data base conversion team, including operations managers and systems staff, sought advice from Bill, the general manager of the customer service division. After being briefed, he immediately spotted two shortcomings of the proposed method. First, it would lead to duplicate effort because the corrections would be noted on hard copy and then keyed. Second, relying on a single printout meant that the data base would be indexed one way and one way only. This precluded the possibility of examining the records from other angles. Bill asked for a sizable sample of the database so he could see firsthand what the cleanup might involve.

After studying this sample for several hours, Bill went back to the database conversion team and asked, "Why don’t we download the records to PCs and do the clerical review on-line? That eliminates the duplicate effort of first writing the corrections on the hard copy and then keying them into the computer. We can also easily reindex the file and thus examine the data from several angles, which should greatly increase the number of records we can safely clean up." When asked what it would cost, Bill said, "Oh, about $80,000.00.

The product manager accepted Bill’s recommendation and authorized him to proceed. The job was outsourced on a fixed-price basis to a nearby data entry vendor. The data base was downloaded to 122 floppy disks, and each disk was assigned to an operator. Operators made three correction passes through each disk. The first pass, indexed on the flat-file key, enabled the operators to add missing social security numbers and to achieve some improved consistency in customer names. A second pass, with the file indexed by social security number and name, facilitated additional corrections. A third pass, with the file indexed by last name and street address, permitted even more corrections.

After the vendor returned the disks, they were passed through a final PC-based "scrubbing" process that eliminated stray characters, such as asterisks and slash marks. The entire process was completed in six weeks, in plenty of time for the planned conversion. The total cost of cleaning up the database was $32,000, less than one-tenth the original estimate, and less than half of Bill’s estimate.

Engineering tool: Design (a.k.a. "Solution Engineering")

The notion of replacing existing systems and processes with newly engineered ones gives rise to a third problem-solving approach, one that centers on design or "solution engineering." To engineer means to plan, construct, or manage in the manner of an engineer. But there is another, more pervasive meaning of engineer: to arrange or bring about through skillful, artful contrivance, as in, "She engineered a remarkable turnaround in the performance of her company." Not all of us are or can be licensed mechanical, electrical, or civil engineers, but as skilled managers, we are indeed expected to engineer solutions to the problems we encounter.

[ Not a great deal has been written about the solution engineering approach. For one of the first treatments of a solution engineering approach to solving business problems, see my article, "Reengineering the Problem Solving Process," Performance Improvement Quarterly, Vol. 7, No. 4, 1994.]

Engineering a solution was precisely the task facing Bill when he crafted a method for cleaning up the data bases. As this case illustrates, not all problems are tied to existing systems and processes. The goal is often to attain a result never before achieved—or to achieve it in a brand new way. There is no cause that can be found or fixed, no cause to unearth or root out, no existing system or process to redesign or reengineer. There is only a goal and the means of its attainment to be considered. In these cases, solutions must be engineered.

The preceding case studies illustrate three basis problem solving approaches: repair, improve, and engineer. These are briefly summarized in the attached sidebar.

In addition to understanding problem-solving tasks, it is important to understand what makes a problem a problem; the nature of solutions; and the importance of structure.

What makes a problem a problem?

The dictionary states simply that a problem is a difficult, perplexing situation. Allen Newell and Herbert Simon (1972), two of the more notable experts in human problem solving, wrote, "A person is confronted with a problem when he wants something and does not know immediately what series of actions he can perform to get it." In brief, what makes a problem a problem is uncertainty regarding action; having a goal and not knowing how to achieve it.

This means that a key area of focus is the goal or solved state. For Matt, this entailed specifying where the condensate should have been going. For Kari, it required specifying the conditions necessary to support error-free performance on the part of the applicants when filling out the forms they later submitted. For Bill, it was a matter of specifying a process that was more efficient, more effective, and less costly than the one that had been proposed. In all three cases, it was attention to the solved state and to the structure of the situation in which the problem was embedded that led to a solution.

The nature of solutions and the importance of structure

A solution isn’t a thing, it is a course of action that leads to a goal or solved state. An effective solution changes things in ways that produce the desired result. An efficient solution is one that produces no offsetting side effects (Barnard, 1938). Anyone wishing to understand and appreciate problem solving in an organizational and business context is advised to read Chester Barnard’s classic. The Functions of The Executive. It was Barnard who drew the distinctions between effective and efficient solutions just cited.

When a solution is carried out, it changes things, even if only slightly. Matt unplugged a blocked drainpipe, Kari rewrote some instructions and reorganized a code list, and Bill crafted a whole new approach for cleaning up databases. If solving a problem is a matter of changing things, then problem solving is a process of searching for those things to be changed, the ways in which they should be changed, and the means of changing them. In other words, no matter which of the three approaches is used, problem solving is a way of reducing uncertainty about action.

Action is always taken in some context (Suchman, 1987). Solutions, then, are interventions in the structure of this larger situation, and in all situations there is some underlying structure or arrangement of elements, connections, and relationships. For Matt, this was the physical structure of the air conditioning system (see Figure 1). For Kari, it was the structure of the process through which the applications flowed, first as physical objects, then as data sets (see Figure 2). For Bill, the relevant structure was the abstract architecture of a process that at first existed only in his imagination.

The search for a solution, then, is a search through the structure of a situation for those elements, connections, and relationships that, if changed in certain ways, will produce the required results. In Matt’s case, this was a glob of residue in the elbow pipe. In Kari’s case, these were the instructions and the code lists. In Bill’s case, it was the method to be used in cleaning up the database.

The search for a solution is enabled by knowledge of the results sought, knowledge of the structure of the situation, and knowledge of the linkages between the two. Knowing these linkages means that for a given result, one can state the actions that will lead to it and, for a given action, one can state the results it will produce. As part of any problem solving effort, it is essential to depict the structure of the situation and to tie the desired results to this structure. The purpose of the technician’s schematic, as well as cause-and-effect diagrams and flowcharts of work flows and processes, is to make visible the ends-means structure underlying the system or process where improvement is sought, and thereby make it amenable to analyses, hypotheses, and modeling in light of the results sought.

Does it make a difference?

Problem-solving efforts in business organizations typically have one of three aims: to restore previous conditions, to improve upon current levels of performance (incrementally or radically), or to create conditions never before realized. Each of these aims calls for a different problem solving approach (see Sidebar).

In the first case, a repair-oriented or technical troubleshooting approach is appropriate. Problems are often defined as deviations from previously attained standards of performance and causes are defined as unwanted changes or events. The goal is put things back the way they were. In the second case, nothing has gone wrong, but expectations have been raised or requirements have been tightened. In such cases, the causes of the problem are the root or underlying factors that account for current levels of performance, and they must be changed to realize higher levels of performance. In these circumstances, a diagnostic-analytical improvement approach is appropriate. In the third case, when results are to be obtained from new systems and arrangements, the search for causes is irrelevant to the task at hand. A solution must be engineered. Each approach has its merits and each is at times preferable to the others. In all three cases, the objective is to reduce uncertainty regarding action and, through action, realize the desired results. In all three cases, uncertainty is reduced as a result of searching through the structure of the situation in which the problem may be said to be embedded.

So, in response to the question that prompted all this, "Does it make any difference which problem-solving method people are trained to use?" the only sensible, defensible answer must be, "Yes, it makes a difference!"

A Comparison of the Three Problem-Solving Approaches

	Problem Solving Approaches
Aspects	Repair	Improve	Engineer
Objective	Put things back the way they were	Improve upon existing arrangements	Create new, far superior arrangements
Starting Points	Presenting symptoms	Existing systems and arrangements	The required results
Focal Points	Causes and corrective measures	Constraints and modifications	The required structure
Core Process	Fault isolation	Structural analysis	Structural design
Orientation	The past (restoring what was)	The present (improving upon what is)	The future (creating what should be)
Politics	Blame	Change	Innovation