Reengineering the Problem-Solving Process

Finding Better Solutions Faster

© Fred Nickols 2012

This paper originally appeared in Performance Improvement Quarterly.  Although reengineering has fallen into disfavor (because it was frequently used as an excuse or pretext for downsizing or getting rid of people), the basic idea of rethinking and redesigning the way we do things is still one of the best performance and productivity improvement options available to those with an interest in such matters.

The Rise (and Fall) of Reengineering

The pressures to lower costs, reduce cycle times, raise quality and, in general, make workplace processes more productive have been intense for several years now.  As a result, reengineering, which "burst upon the management scene in 1990" was much in vogue (Davenport, 1993a).  However, owing to its inappropriate use and just plain poor execution, it has long since fallen into disfavor.  Yet, the idea of reengineering still has merit. 

To reengineer is to rethink, to redefine, to redesign, to radically change the way work gets done (Davenport & Short, 1990; Davenport, 1993b; Hammer, 1990; Hammer & Champy, 1993). Often, this means adopting a clean slate, starting "from scratch," as the saying goes. It also means challenging and perhaps throwing out many cherished notions and assumptions.

Although reengineering efforts were typically focused on large-scale business processes such as purchasing, business acquisition, and product development, sooner or later attention was bound to turn to some of the more fundamental or "deep structure" workplace processes. One of these is problem solving.

Problem Solving: The Core Competency, the Core Process

Owing in large part to the shift to knowledge work, the nature of the "contract" between the individual and the organization has shifted from one of security in exchange for compliance to one of compensation in return for contribution (Drucker, 1968; 1973; 1992; 1993). Instead of carrying out simple, highly specialized and repetitive routines that have been prefigured (i.e., figured out for them by others), the work of many people now requires of them that they figure out what to do. Their working activities consist of configured responses to the circumstances at hand, not prefigured routines to be carried out under standardized conditions. "Figuring out what to do," by its rightful name, is known as problem solving. The problem-solving process underlies all deliberate, goal-oriented behavior. It is the core competency for all human beings, and it is the core process for all organizations.

The Case for Reengineering the Problem Solving Process

Many commonly accepted notions about the proper way to solve problems are of questionable value in today's world.

Instead of focusing on defining and analyzing the problem, the problem solving process should focus on specifying the solved state and finding ways of achieving it.

The assumption that problems have causes, "root" or otherwise, is clearly open to question. Ordinary experience informs us that the search is always for a solution to a problem and only sometimes for its cause.

Rather than follow a narrowly-defined, sequential procedure, the search for solutions should proceed along many fronts at once, taking advantage of the available information and working on what can be worked on at the time.  To do otherwise is to unnecessarily delay progress.

As often as not, problem solving is seen as an attempt to fix what has gone wrong. Fixing what has gone wrong is only one approach to problem solving, of value primarily in a world where things can be put back the way they were. In a fast-paced, rapidly changing world, attempts to restore what was are often futile and frustrating. The ability to quickly engineer new solutions is of much greater value.

Of special significance to problem solving efforts in an organizational setting is the recent shift in the locus of work and working from the managed individual to self-managed teams. This shift has been taking place in business and industry for several years as part of a general trend toward downsizing and flattening hierarchical structures.

Other factors related to problem solving are driving this same shift to teams. Many problems, for example, span functional and divisional boundaries, making the use of problem solving teams a practical as well as a political necessity. Complex problems call for complex solutions, and complex solutions generally require a multidisciplinary approach (Ruesch, 1975). Rarely does a single domain of knowledge hold all the answers. This, too, necessitates working in teams.

As a result of this ever-increasing complexity, the practice of defining a problem at the top of the organization, handing it off to middle management to figure out what to do about it at, and then giving line management the task of implementing the solution is rapidly disappearing.

That the locus of organizational problem-solving efforts has shifted to cross-functional teams adds fuel to the reengineering fire, however, the implication is not that we should have one problem solving process for use by individuals and another for use by teams. Instead, the members of a problem-solving team should be using the same or a similar approach, and one suited for the task at hand.

The shift in the locus of organizational problem-solving efforts also suggests a future where team training in problem-solving methods is coupled with training in the dynamics of small work groups, much like is currently found in the start-up stages of a Total Quality Management (TQM) program.

There are two very good business reasons for reengineering the problem-solving process.

• The most obvious of these is to make the process more efficient and more productive, so that more problems can be better solved for the same expenditure of time and energy.

• Reengineering also yields speed. The more quickly a viable solution is found and put into effect, the more quickly the problem is solved. This reduces the costs of the problem as well as the time and costs of solving it.

There also are good personal reasons for reengineering the problem-solving process.

• Finding good solutions fast frees up time to tend to other matters.

• Proficient and efficient problem-solving efforts help establish your credibility with your colleagues. Perhaps you're a relative newcomer to the world of work and working, and you're trying to make your mark in an increasingly competitive and uncertain workplace. Finding good solutions fast is a time-honored way of establishing a reputation for general competence.

•  If there is any job security left in the workplace at all, it is probably tied to your ability to quickly, effectively, and efficiently solve problems.

• Finally, problem solving can be just plain fun, especially if you're good at it and getting better.

Problem Solving is a Search Activity

Problem solving is an information-based search activity. It is concerned with finding ways of getting from where you are to where you want to be. Technically speaking, "where you are" is known as the problem state, commonly referred to as what is. "Where you want to be" is known as the solved state, also known as what should be. The path that leads from here to there, from the problem state to the solved state, is known as the solution path. The term "solution path" is also used at times to refer to the sequence of events whereby a solution is arrived at (Newell & Simon, 1972).

Problem solving viewed as a search activity suggests at least two questions: Search where? Search for what? Where you search is always the same: In the structure of the problem, in a conceptual area known as the search space which is in turn a subset of a larger conceptual area known as the problem space (Newell & Simon, 1972). These "spaces" are not spaces at all in the physical sense; instead, they are mental representations of reality, models of the way things work. What you search for depends on the problem at hand. Sometimes, you search for the cause of the problem, sometimes not. In all cases, you search for a solution.

The first factor to consider in reengineering the problem-solving process is that the process should be solution-centered, not problem-centered. The goal in solving a problem is the solved state and the search is for a solution, a course of action that leads to the solved state. In reengineering parlance, this re-centering of the problem-solving process on the solved state and the course of action that will get you there falls under the heading of "organizing around outcomes."

You can search for the solution path for a given problem in one of three ways: you can work forward from the problem state, you can work backward from the solved state, or you can hope for a blinding flash of insight. Insight is wonderful when it happens but it is notoriously unreliable. Therefore, for the most part, problem solving in an organizational setting is best approached as a rational, purposeful, structured, and systematic information-based search activity.

Covering the Bases

Because the search for a solution or a solution path is information-based, the search process greatly resembles detective or intelligence work, that is, it goes wherever the information leads. Consequently, problem-solving efforts often give the appearance of bouncing around, of moving from problem to solution to cause and then back again, in no particular order. The typical - and wrong-headed - response to what appears to be aimless meandering is to impose a sequential procedure.

Solving problems is more akin to mosaic building than it is to brick laying. It is a form of intelligence work. What appears to be aimless meandering is often an intelligent attempt to piece together a complex puzzle. For this reason, the problem solving process is best viewed as an exercise in "covering the bases" instead of a predefined, step-by-step procedure.

The "bases" to be covered in the course of solving a problem are shown in Figure 1. A set of key questions for use in covering these "bases" is provided in Appendix A. The key to an effective, efficient search for the solution path for a given problem lies in knowing when to emphasize which of the bases shown in Figure 1.

Some decisions that are helpful in deciding when to focus on which base or set of bases are shown in algorithmic or flowchart form in Figure 2 on the next page. The balance of this article is devoted to explaining how to use the logic shown in Figure 2 to decide which of the bases shown in Figure 1 to emphasize when searching for a solution. The object is to streamline these searches so as to find better solutions faster.

You Have a Problem

Let's begin with a simple premise: You've got a problem. We'll revisit the definition of problem and the factors entering into this decision point later on. But, for now, let's assume that your answer to Question 1 in Figure 2 is "Yes," you've got a problem.

You Have a Problem and You Know What to Do About It

If your answers to Questions 2 through 4 are all "Yes," then you know what to do, you know how to do it, you've got a plan, and you have backing and support for what you intend doing. Your emphasis should be on carrying out the action you've planned, assessing its effects and consequences, and making whatever adjustments prove necessary.  In terms of the bases shown in Figure 1, you should concentrate on covering Bases 10, 11 and 12. As the flowchart in Figure 2 indicates, once you intervene, you go all the way back to the beginning, to Question 1. There, you check to see if you've still got the problem you set out to solve. You also make sure that you haven't created any new ones, perhaps making matters worse.

You Have a Problem and You Don't Know What to Do About It

Generally speaking, one reason a problem is a problem because there is uncertainty regarding the action to take. In a very real sense, problem solving is a search for information that reduces uncertainty regarding action. Uncertainty might exist regarding what should be changed and in what ways, or with respect to how such changes might be made. Even if the what and how are known, there remain the matters of consensus, support, and planning. So, let's suppose the answers to Questions 2 through 4 are "No." And let's work backward from the end of the flowchart in Figure 2, starting with a "No" answer to Question 4.

 Figure 2 - The Logic for Covering the Bases

Building Support and Putting Together a Plan

Just because you know what to change and how to change it, or think you do, doesn't mean you have solved the problem. Nor does it mean that the course of action on which you have settled will be implemented.  Organizations are complex entities, push them here and they bulge over there. Power, politics, performance, and people are intertwined. Businesses must be managed, organizations must be governed. Unintended consequences abound. Opposition springs from wholly unexpected sources. Change is indirect. Effects are often far removed in space and time from the actions that give rise to them. Patience is a virtue. Once you find a solution path, you must convince others to walk it with you. They must concur in your view of the problem state, the solved state, the solution path, and the solution. You must be prepared to show how the resources consumed in solving the problem are better spent there than elsewhere. Building consensus and support might require you to reconcile conflicts between the things you want to do (the solution), the things you must do (constraints), and things you can't do or can't afford to do (restraints). Finally, you'd better have plans and schedules spelling out who does what when. If your answer to Question 4 is "No," you are well served by concentrating on Bases 3 and 9, and perhaps Base 8 as well. Let's back up now to Question 3.

Figuring Out How to Make the Required Changes

Question 3 asks, "Know how to change it?" If the answer to this question is "No," the emphasis should be on Bases 6, 7 and 8. The assumption at this point is that you know what to change and in what ways. Your search, therefore, is for the specific means of making the required changes. Here is where domain-specific knowledge and specialized expertise make their greatest contribution.

There is more to covering this base than identifying methods and techniques. You also must settle on a particular course of action, which might require reconciling restraints and constraints, and you must lay out a plan. An old saying has it that there is more than one way to skin a cat. When solving problems in organizations, there is generally more than one cat to be skinned. A solution is typically a complex course of action, not a simple act. There are many changes to be made, not just one, and several means to consider. This implies choices to be made, criteria to govern the making of them, and care to be exercised in altering key relationships. As one wag put it, "Everything relates to everything else." All these factors come into play in configuring the course of action you believe will lead to the solved state.

Keep in mind, however, that what you have at this point is an envisioned or a proposed solution. It won't be a proven solution until it's implemented and results establish that it worked. Let's back up one more step, to Question 2.

Figuring Out What to Change - Identifying Change Targets and Change Goals

Before you worry about how to change things, you must first identify what is to be changed, and the nature of the changes to be made. Question 2 asks, "Know what to change? If the answer is "No," you must set your sights on some change targets and specify some change goals. Depending on how the problem came about, there are two very different ways of identifying these change targets and change goals. We will call one of these "Troubleshooting" and the other "Solution Engineering." Troubleshooting is concerned with figuring out what has gone wrong in an existing system. Troubleshooting, as indicated earlier, typically applies when something changes, causing previously acceptable results or conditions to become unacceptable.  "Solution Engineering" centers on figuring out how to achieve a specified result, whether or not an existing system is in place. This choice point in problem solving approaches is reflected in Question 5: "Were things okay before?" Let's assume a "Yes" answer to this question.

Something Has Gone Wrong

If things were okay before and they're not now, then something has gone wrong. Chances are, something in the situation changed. This unwanted or unanticipated change may be thought of as the cause of the problem (Kepner & Tregoe, 1965). The obvious thing to do is find it and fix it. In such cases, the change targets and goals have been set for you. You're looking for the cause of the problem and your aim is to fix it. To accomplish this, you emphasize Bases 1 and 4. Identifying the unwanted change isn't always an easy matter. Techniques of troubleshooting, especially those known as "fault isolation," must be brought into play. Distinctions and discriminations become important. Narrowing the search, formulating and then testing hypotheses is standard fare. Even so, you might not be successful. Even if you find the cause, you might find something that can't be fixed. Not everything can be put back the way it was. The search for a cause doesn't always lead to a solution.

Designing a Solution

As just stated, not all causes can be found and not all causes that are found can be corrected. If you're among the fortunate, your answer to Question 6 will be "Yes." You will have found the cause and it can be fixed. This means you can move to Question 4 and start laying your plans and thinking about garnering support for them. If you're not so fortunate, the answer to Question 6 will be "No" and that choice, if you follow the "E" connectors, will take you to "Design A Solution." The emphasis here is on covering Bases 2 and 5. These are the same bases a "No" answer to Question 5 would lead you to emphasize. Designing or engineering a solution is a difficult but doable task. Basically, it's a matter of mapping the means-end relationships that define the structure of the situation in which the problem is embedded. Means-end maps enable precise, reliable identification of the three essential components of any solution:

 1.       the elements to be changed, that is, the change targets,

2.       the ways in which they must be changed, and

3.       the specific means to be used in changing them.

For an operational or production problem, a means-end map might take the form of a rather conventional flow-chart or process diagram. For a financial problem, a means-end map might begin with a tree-chart view of a financial measure such as Return-on-Equity (see Figure 3). In turn, this could be linked to non-financial measures and from there tied to specific processes, functions, and operations. In this way, the organization's activities are connected to its bottom line (Nickols, 1979). Working backward from the solved state is the preferred mode of operation for this approach.

Figure 3 - The Structure of ROE

Once you specify the solved state and identify your change targets and change goals, you can move on to considerations of the means of making these changes, building support, planning, scheduling, and all the other intervention-related matters.  Successfully linking design with intervention amounts to engineering a solution.

Got a Problem?

Having worked our way backward through Questions 4, 3 and 2, let's back up that final step to Question 1: "Got a problem?" We started out with a "Yes" answer here. Let's revisit this choice point now and see just what it takes to constitute a problem.

A problem exists when there is a discrepancy or gap between required and actual results, that gap has been targeted for closure, and there is uncertainty regarding how to close it; hence, the search for a solution and a solution path, a way of getting from here to there.

Discrepancies in results come about in several ways.  First, is the ever-present possibility that things are going along just fine and then something goes wrong. In this case, the appropriate response is to find and fix the cause of the problem. This is the kind of problem for which the basic troubleshooting approach described by Kepner & Tregoe (1965) is so useful.

Expectations can be raised and requirements can be tightened. This, too, can create a discrepancy in results, a gap between what is and what should be. However, in this case, a search for cause is pointless. What is required here is the engineering of a solution, the arrangement or rearrangement of elements in the structure of the situation in ways that will lead to the required results, to what is known as "the solved state."

Lastly, there is the situation characterized as "a clean slate." No prior constraints exist. There are two variations on this theme. One is the situation in which results are being specified for the very first time. The other occurs when existing systems are to be discarded in favor of radically different ones that have yet to be developed. In both cases, the only choice is to engineer a solution, to create a system or structure that will produce the desired results.

It is now time to say something of the goal of reengineering the problem-solving process, an objective indicated by the subtitle of this article.

The Goal: Finding Better Solutions Faster

"Finding better solutions faster" factors into improvements in the quality of the solutions found and the speed with which they are found. 

The first measure of a good solution is that it gets implemented. No solution is ever really a solution until put to the test. Under normal circumstances, this criterion implies a fit with the constraints of the situation, plus buy-in, commitment, and support from those affected. On occasion, the requirements for buy-in and commitment can be ignored in favor of a top-down, mandated approach, one that can, if necessary, ride roughshod over restraints and constraints.

Once implemented, the chief measures of a good solution are whether or not it produces the desired effects, and the extent to which these are offset by any side effects. The first of these measures may be thought of as solution effectiveness. The second measure, the extent to which the solution has offsetting side effects, may be thought of as solution efficiency (Barnard, 1947).

"Finding better solutions faster" also implies the ability to get quickly to the heart of a matter; in other words, a highly effective and efficient search process.

As stated above, a good solution is a course of action that, once implemented, produces the desired results, a goal known as "the solved state." To achieve these results requires intervention. Something in the structure of the situation in which the problem manifests itself must be changed, and changed in such a way as to produce the desired results. This implies knowledge of the structure of the situation. This is knowledge that enables one to say, for a given action, what effects will be produced, or, for a given effect, what actions will produce it.

To restate this very important point, the requirement for an effective, efficient search process implies some means of charting and representing the means-end relationships that define the structure of the situation in which the problem is embedded; in other words, some way of mapping or diagramming the problem space and its subset, the search space. Without a map of these relationships, a problem-solving effort is analogous to a technician troubleshooting an unfamiliar piece of equipment without the aid of a schematic.

An efficient search process also implies the minimum amount of effort required to solve the problem and that in turn implies a minimum amount of wasted effort. This entails doing those things that should be done, doing them properly, and not doing things that add no value. It is pointless and wasteful, for example, to search for the cause of a problem, "root" or otherwise, when the problem to be solved is how to produce a given result for the first time. It is not necessary to wait until a solution has been completely fleshed out to begin involving those who must support it, or to begin planning its implementation. Granted, there are serial dependencies among tasks, which means that some tasks cannot begin until others are underway, and that some tasks cannot be completed until preceding ones are complete, but most tasks can run in parallel to some extent. Work can proceed on defining the problem and specifying the solved state at the same time. An examination of causal factors and the modeling of means-end relationships can occur simultaneously.

The important thing is to cover all these bases, not trot around them one, two, three. Speeding up the problem-solving process means abandoning rigid, confining procedures that assume a stable environment in favor of a process that facilitates fluid, flexible responses to situations that are themselves in a state of flux.

Finally, it helps to keep in mind that solving problems in today's world is often more a matter of staying on top of things than it is one of finding permanent or lasting solutions.

Concluding Remarks

If you're going to do something about a problem, no matter the kind of problem or how it came about, eventually you have to take action, you have to change something. The solution path must be walked as well as talked. The prospect of changing things focuses attention on some very practical matters.

• What are the elements to be changed?

• What is the nature of the changes to be made to these targets of change? Couched in slightly different terms, how are the change targets to be different once the changes have been made? These differences are the change goals.

• Through what means might the required changes to the change targets actually be made?

Change targets, change goals, and the means of making the specified changes, these are the key factors in figuring out what to do about a problem.

In an organizational setting, the prospect of changing things also focuses attention on other people. Taking action in an organizational setting can be a very complex undertaking. It can require the efforts of more than one person, sometimes small teams, sometimes dozens or even hundreds of people. Moreover, for numerous reasons, taking action often requires consensus, support, and careful planning. There are restraints, things you can't do, and constraints, things you must do. Resources must be allocated, approvals obtained, schedules established, tasks assigned, commitments made, and assessments of results conducted. Considerable political skill is required.

So, when you have a problem, if you know what to change and how to change it, and if you have a sound plan and the necessary support, then, in effect, you really don't have a problem; all you have is a requirement for action. In such circumstances, what you do is take action, assess its effects, and make whatever adjustments are required. In Figure 2, this path is signified by "Yes" answers to Questions 1, 2, 3 and 4. If you get a "No" answer at any of these points, then you're engaged in a search for a solution. The logic diagram in Figure 2 coupled with the problem solving bases shown in Figure 1 and the prompts provided in Appendix A will provide some guidance regarding where to look and for what.

Good luck with your search for solutions.

References

1. Barnard, C. (1947). The Functions of the Executive. Harvard University Press: Cambridge.
2. Davenport, T. & Short, J. (Summer 1990). "The New Industrial Engineering: Information Technology and Business Process Redesign." Sloan Management Review. Massachusetts Institute of Technology: Cambridge.
3. Davenport, T. (Fall 1993a). "Book Review: Reengineering the Corporation." Sloan Management Review. Massachusetts Institute of Technology: Cambridge.
4. Davenport, T. (1993b). Process Innovation: Reengineering Work through Information Technology. Harvard Business School Press: Boston.
5. Drucker, P. (1968). The Age of Discontinuity. Harper & Row: New York.
6. Drucker, P. (1973). Management. Harper & Row: New York.
7. Drucker, P. (1992). Managing for the Future. Truman Talley Books/Dutton: New York.
8. Drucker, P. (1993). Post-Capitalist Society. HarperBusiness: New York.
9. Hammer, M. (July-August 1990). "Reengineering Work: Don't Automate, Obliterate." Harvard Business Review. Harvard University: Boston.
10. Hammer, M. & Champy, J. (1993). Reengineering the Corporation: A Manifesto for Business Revolution. HarperCollins: New York.
11. Kepner, C. & Tregoe, B. (1965). The Rational Manager. McGraw-Hill: New York.
12. Newell, A. & Simon, H. (1972). Human Problem Solving. Prentice-Hall: Englewood.
13. Nickols, F. (December, 1979). "Finding the Bottom-Line Payoff for Training." Training and Development. ASTD: Alexandria.
14. Ruesch, J. (1975). Knowledge in Action. Jason Aronson: New York.

More Recommended Reading

In addition to the books and articles listed above, I encourage you to read some of the other articles I have published over the years.  All are available on my articles web site at the link below and under the heading of Solution Engineering.  The following are the most relevant:

1. Yes, It Makes A Difference: Choosing the Right Tool for Problem Solving Tasks

2. Ten Tips for Beefing Up Your Problem Solving Tool Box

3. Three Cases in Figuring Out What to Do

4. Why Those Darn Training Problems Won't Go Away

For More Information

Contact Fred Nickols by e-mail and visit the Solution Engineering section of his web site.  There, you will find more about business problem solving and Solution Engineering.

Appendix A:

Questions for Use in Covering the Bases

Contact                                   Questions

This page last updated on August 2, 2019