Improving the Performance of People, Processes and Organizations
Articles Columns Projects Resume Services Tool Room
A Really Good Example
© Fred Nickols 2012
A much longer version of this paper was first written
several years ago. The
editor of Sloan Management Review expressed an interest at one point but that
didn't work out and I never again tried to publish it. I've dusted it off, so to
speak, greatly shortened it and included it here because it was one of my first attempts
to articulate the Solution Engineering approach and because it contains a really good
example of Solution Engineering in action.|
Solutions Can Be Engineered
There are many different approaches to the task of figuring out what to do about a
problem. Most approaches are problem centered. This article presents a solution-centered,
engineering approach called "Solution Engineering." Its basic premise is that solutions
can be engineered.
The engineering approach is characterized by the specification and then the systematic and reliable attainment of some predetermined set of conditions. The essence of the engineering approach is captured in the phrase, "built to specification."
The predetermined set of conditions to be specified and then achieved when solving a problem is known as the solved state. The course of action that leads to the solved state is known as a solution. This course of action must usually satisfy other conditions as well (e.g., temporal, financial, and political constraints).
The process of engineering a solution is a process of specifying the solved state and any other conditions or constraints the solution must satisfy (i.e., spelling out the solution requirements), systematically identifying change targets and change goals, settling on the means to be used in creating the solved state while satisfying the solution requirements and constraints, configuring these means into a course of action, and then carrying it out. In this regard, Solution Engineering is consistent with one of the more basic definitions of engineer as a verb: "to arrange, manage, or carry through by skillful or artful contrivance."
Why An Engineering Approach?
Simply put, an engineering approach yields consistently better results.
Solution Engineering differs from more conventional, problem-centered approaches in several important ways. Chief among these differences is an unrelenting focus on the solved or goal state. This emphasis on the solved state increases the effectiveness and efficiency of solutions and of the problem solving process. In short, it gets you where you're going, it avoids wasteful searches (especially for non-existent causes and "real" problems), and it provides a non-punitive, non-threatening method of attacking problems. It also dispenses with the contrived and artificial distinctions that are so often drawn between problem and opportunity, and between problem and symptom.
Why Such An Emphasis On The Solved State?
The short answer is that knowing where you're going helps you map (or choose) a route. But the deeper, more fundamental reason is that focusing on the problem state can be and often is counter-productive.
For one thing, focusing on the problem state can lead you to concentrate on doing something about the problem instead of concentrating on defining and achieving the solved state. Your attention is misdirected. Solutions developed under this mindset frequently are not solutions at all, but simply knee-jerk responses that substitute one or more new problems for the old one.
Focusing on the problem state can also lead you to settle for less than can be achieved. Worse, it can cause you to inadvertently lock yourself in to doing little more than trying to maintain the status quo. These unfortunate outcomes occur when a problem is defined as a deviation from some previously attained standard (Kepner and Tregoe, 1965). Under this scenario, people typically view a problem as a bad situation, one in which things were okay and then something happened to make them go wrong. This view of a problem can lead to avoidance and cover-ups, a search for the guilty instead of for solutions, word games having to do with opportunities and symptoms, futile searches for non-existent causes, the acceptance of unacceptable results when perceived causes are seen as intractable, and endless bickering about the "real" problem. At best, people are engaged in little more than trying to put things back the way they were.
There are more productive ways of viewing a problem.
A problem exists in a situation when action is required but the appropriate action is not immediately apparent. In short, one must figure out what to do.
Action might be required because the situation has suddenly deteriorated, because opportunity presents itself, because new or higher standards or goals have been set, because resources are newly available to address long-standing concerns, or simply because people have become aware of a situation that has in fact existed for some time.
No matter the occasion, problem situations are typically characterized by perplexity regarding the situation itself, uncertainty regarding the action to take, difficulty in determining the consequences of contemplated actions, and perhaps tension or concern (Dewey, 1910). In short, the problem solvers don't know what to do. We might say they are stuck or stymied.
In any event, the current situation is no longer acceptable. More important, some new state of affairs is targeted for attainment.
Some Key Distinctions
Problem solving is concerned with figuring out what to do in situations where what to do is not immediately apparent. Its chief purpose is to reduce uncertainty regarding action. The core process is investigation. Solving problems requires action; something must be changed. The aim or purpose is to get what is wanted, to obtain the solved state. The core process is intervention.
Put another way, actually solving a problem requires you to act, to change something. All approaches to problem solving, including Solution Engineering, have as their object arriving at a course of action intended to alter some situation. The prospect of changing things raises a host of questions. Change what? How? Why? In what ways? To what effect? Are there things we wish to preserve? Avoid? What pressures are we under? What constraints do we face? Who might support the change? Who might oppose it? How will we know the problem has been solved? How will we know we haven't created any new and perhaps more troublesome problems? Who does what when? Problem solving is the process of finding answers to these questions.
When problem solving is studied, it is typically defined as a cognitive process, as an information-based search activity carried out by a single individual. Because the process centers in a single individual, the dominant discipline is psychology. When viewed as a goal-oriented, purposive effort aimed at reliably and systematically creating certain effects in an organizational setting, solving problems may be defined as an engineering activity. This process no longer centers in a single person and the relevant disciplines include sociology, political science, organizational behavior, economics, management, and engineering, to name a few. Oh yes, the discipline of business comes into play too.
Solving Problems: A Conceptual View
Conceptually, solving a problem is a matter of transforming the problem state into the solved state. Transforming the one into the other is typically accomplished as a result of setting up and achieving three types of goals: transform, reduce, and apply (Newell & Simon, 1972).
Three Categories of Useful Information
In keeping with the three types of goals outlined above, three categories of knowledge and information are especially useful to a problem solver:
Problems Are Embedded in Larger Structures
Solution Engineering is a disciplined, systematic way of getting at all three categories of knowledge required to solve a problem. It is especially useful in getting at knowledge of the structures in which problems are typically embedded (Senge, 1990).
To say that a problem is "embedded" in a structure is to say simply that the problem is part of some larger context. All problems are manifestations of the current arrangement of elements and relationships making up the larger structure of which the problem is a part. Alter this structure in a certain way and the problem state disappears. Alter it in another way and the solved state appears. To solve a problem, then, you alter or change the structure or system in which the problem is embedded.
The key to Solution Engineering--and to engineering a solution--lies in having an adequate model of the structure of the larger situation in which the problem at hand is embedded. Knowledge of this structure makes it possible to engineer a solution--to reliably and systematically determine which elements in a given situation should and can be changed so as to produce the desired effects. Such knowledge is also useful in determining what is producing the current effects, that is, as a way of identifying what many would call the "cause" of the problem.
A Case in Point
By way of illustration, allow me to recount a problem solving that took place at my company, Educational Testing Service (ETS), one that resulted in a very real, recurring annual savings of $225,000 in charges to projects at a one-time cost of $16,000.
When I assumed responsibility for ETS's Custom Operations Division in early 1991, it was apparent that the division could benefit from additional work. As a result of the sale of a line business, there was some excess capacity in the form of people who, lacking sufficient paid project work, had to charge part of their time to overhead accounts. This increased the "load" or indirect expenses for the division and, at the same time, reduced the base of hours directly chargeable to programs. Moreover, the division was only two months away from a scheduled move to more expensive space as part of a larger corporate relocation to a premium site. This "double whammy" meant that more expenses had to be recovered from fewer direct hours, thus driving up the rates the division charged for the work it performed, increasing the charges to the programs.
Being new at the time, I simply went to my colleagues, the other division managers within Operations, explained the problem (which they understood better than I) and asked if they had any work they would be willing to transfer to my division. Two of them graciously consented to reassign work to my division and the rates were held in check--for a while.
Work comes and work goes. Things change. A year later, in early 1992, I was faced with the rates problem again. This time the culprit was neither excess capacity nor a move to more expensive space. At work this time was the bane of a cost center manager's existence: Indirect Expenses.
When we moved into our new space, the additional work assigned to our division had given it a broader base of hours and thus softened the impact of the increase in space costs. However, during the year, the division had again lost some work. Further, as a result of internal transfers, retirements, resignations--and a firm refusal to fill open positions--the division staff had been reduced by almost 20 percent. Owing to the loss of work, the reduction in staff, and increased productivity, the base of productive or chargeable hours had again grown smaller--with no corresponding decrease in indirect expenses; chiefly, space. The division's clients were again concerned about the division's rates.
Interestingly, although being overstaffed clearly wasn't the source of the division's difficulty this time, some people advised me that I should reduce staff--a move that could have resulted in not being able to do the work at all. This time, there was no work that could be transferred to my division. In order to keep the rates in check, it was necessary to reduce indirect expenses. The targeted amount was $250,000.
At the time of this second "rate problem," as some called it, the larger portion of the division occupied 16,000 square feet at the new site. One of the two additional units reassigned to my division at the time of the move was included in this main area. The other unit assigned to my division at the time of the move occupied 5,000 square feet in an adjacent building. The annual cost of this 5,000 square feet was $225,000, roughly half of which was for the space itself, the other half consisting of allocations for common or shared space, facilities staff, security systems, and so on.
Given the loss of work since the merger of the units--and the reduction in staff through attrition--consolidating the two operational areas in a single, smaller space was an obvious and appealing option. The difficulty was that the primary work area of 16,000 square feet simply couldn't accommodate the 5,000 square feet required by the smaller shop. There was some extra space in the larger shop but not that much.
My task--the preliminary problem to be solved if you will--was one of figuring out how to make do with less space; more specifically, I had to fit the 5,000 square feet occupied in the adjacent building into the 3,000 square feet I had available in the main work area. This entailed effecting a 40 percent reduction in the space required by the smaller shop.
My managers and the supervisor of the smaller shop chuckled when I told them of my aim. They informed me that people had been trying to do that for years--and no one had yet succeeded.
What made the space problem so intractable was the nature of the work performed in the smaller shop.
Each year, thousands of candidates for scholarship programs submit applications and related materials such as references and transcripts. In many cases, these materials "trickle in" over time. We assemble these materials into candidate portfolios for review by selection committees. The portfolios are (or were) kept in open boxes on tabletops where they are easily accessed and readily available for transport to and from the sites nearby where the selection committees meet. Filing cabinets simply would not do.
So, I waited until the peak processing period arrived and then went to survey the scene.
What I saw was 3,000 square feet of space, occupied by 40-50 tables, all of which were covered with boxes of files.
The first thing that struck me was that the portfolio files were in a single, horizontal plane--spread out on tabletops. If some way could be found of stacking them, of moving them into the vertical plane, they would require much less space. Stacked four-high, they would require one-quarter the floor space they presently occupied.
"Why not," I asked, "move to a vertical filing system?"
The answer was that this had been thought of before, in the form of placing the boxes on shelves or using drum files. But, the use of shelves prevented ready access to the boxed files and, owing to the weight of the boxes, increased the risk of "spills." Drum files were viewed as much too heavy for the floor load limits of the building we occupied.
Nevertheless, I requested one of my staff associates to contact office equipment and supply firms to see what might exist. She resorted to the Yellow Pages. Two of the firms she contacted claimed to have the solution to our problem: vertical filing systems, with end tabs for easy recognition, and small removable containers to facilitate access and reduce the risk of spills. Moreover, being lightweight, they would not exceed our floor load limits. Site visits were arranged, studies conducted, presentations made, and a deal struck. The times were hard. The vendors wanted $25,000 for their systems; we agreed to pay $16,000.
At this point, several others became engaged in the problem solving effort.
The $16,000 represented an unplanned, unbudgeted capital expense. This required the approval of my boss, the vice president of Operations. His concern--and mine--was that we were going to spend $16,000 to make use of less space but that the costs of the space we were vacating weren't going away. These costs would instead simply move into the corporate pool of unoccupied space (which is allocated to cost centers based on the amount of space they occupy). This meant that the $16,000 expenditure constituted an additional cost, not a cost savings. To make a long story much shorter, the $16,000 expenditure had to be justified on the basis of its future value in making better use of space throughout the corporation and not simply its current value to my cost center in "shedding" 5,000 square feet of space.
The larger of the two areas my division occupied didn't have 3,000 square feet sitting vacant and ready to be occupied. The larger space had to be rearranged in order to accommodate the work unit from the adjacent building. Moreover, the people in the work unit that would be moved had to be convinced that the new vertical filing system would in fact serve their needs. The vendor installed one system which was used on a prototyping basis for a period of two months while the larger space was being redesigned.
The facilities staff had to be persuaded to rearrange their schedules and priorities to accommodate the timing of our move. Telephone hook-ups, data links, terminal and local area network (LAN) connections also had to be established.
A solution that looked simple enough in conception proved quite complicated in execution. It was nevertheless carried out and the two shops have been merged for some time now. The vertical filing system works just fine. Indeed, we are applying it elsewhere in the division and in the company as a general strategy for reducing space requirements and cost. More important, my division's "load" or indirect expenses have been reduced by $225,000. The rates are okay--for now.
What Was The Problem?
Reflect upon the incident just related. What was the problem? Rates too high? The pressure exerted by those who had to pay them? Too much space? Not enough work? Too many people? Moving to expensive space? Inefficient use of space? Poor planning? A lack of imagination? A failure to investigate? Ask six people and you'll get six different answers. That's what happens when you focus on the problem state. But, focus on the solved state, and things become clearer.
The charges for work performed in the division were going up again. The objective was to bring them down, to keep them at or near the preceding year's rates. This objective was itself a means to the more distant end of controlling charges to the programs--of managing the costs of work performed.
The upward pressure on rates was exerted by the relationship of indirect to direct expenses (see Figure 1 below).
Figure 1 - The Structure of Load Rate
Initially, owing to a decrease in workload and a move to more expensive space, indirect expenses constituted a larger portion of the total expense picture and had to be spread over a smaller base of productive hours. This drove up the load rate (a closely watched number), raising concern among those whose programs were charged for the work performed by the division. (Load rate is such an "attention getter" because it is a very good indicator of the relationship of indirect to direct costs.)
At the time of the move, the solution was to obtain more work for the division, increasing the base of productive hours and thus reducing the load rate and charges to the programs. Later, owing to another decrease in the workload and a sizable reduction in staff, the base of chargeable hours had once again decreased and indirect expenses once again dominated the expense picture. This time, the solution was to reduce the amount of space occupied and thus reduce the space allocation charge from corporate.
The objective of reducing space was stymied by a perceived inability to accommodate file storage requirements in a smaller space. Visualizing the files as stored in the vertical plane (i.e., making use of "air space") led to a search for vertical filing systems. The search was successful and fixed expenses charged to the division were reduced by $225,000 at a one-time cost of $16,000.
The transform-reduce-apply paradigm mentioned earlier is apparent throughout the case in point.
The goal or solved state was and is to maintain charges at an acceptable level. Charges are themselves driven by the hours worked and the rates charged for that work. Keeping charges under control is largely a matter of managing the interplay of chargeable hours worked (productivity) and load rate (the ratio of indirect to direct expenses).
Rate problems in my division are embedded in a larger structure consisting of those factors and relationships making up the company's cost accounting system. A portion of this structure is illustrated in Figure 1 above. The complete model constitutes both the "problem space" and the "search space" for solutions to "rate problems" (and other problems of a financial nature as well). The search is for actions that can be taken at one point and then ripple through the structure and produce the desired effects at other points.
Changing any of the factors in the cost-accounting structure in which the "rate problem" is embedded is an indirect process. None of those shown are directly manipulable. The space charges, for instance, were reduced as a result of reducing the amount of space occupied by and charged to the division. Space charges also could have been reduced by changing the rate charged for space.
Solving the rate problem was a matter of finding concrete means of altering factors that in turn led to changes in one or more of the factors shown in Figure 1 so as to achieve the desired ends. In the one case, this was obtaining more work, which increased the direct costs and, at the same time, reduced the indirect costs. In the other case, it was conceiving of and finding a vertical filing system. This enabled the use of less space, which led to lower allocations for space. This resulted in a lower load rate and that had the salutary effect of keeping charges for work performed at an acceptable level.
What's The point? What's The Moral? Where's The Magic?
There isn't any magic in Solution Engineering--that's the point. There is instead just a calm, methodical way of getting from where you are to where you want to be, of being able to figure out what to do about a situation that demands action. It is worth noting at this point that all solutions eventually hinge on human behavior--someone, somewhere, must do something.
There is a moral. In organizations, problems frequently aren't solved in any permanent sense. Situations are continuously changing and continually managed so as to maintain some approximation to a goal or solved state. Indeed, it is perhaps beneficial to think less in terms of solving problems and more in terms of staying on top of things.
Solution Engineering: A Summary
To solve a problem, it is necessary to act, to do something, to change something.
Organizations don't act, people do. Solutions always involve and depend on human behavior.
Action may be required because the current state of affairs is unacceptable or because some other state of affairs has become a goal.
Action may be prefigured or configured, which is to say it may be part of a repertoire of routines known as method or technique, or it may constitute a novel response.
Action is constrained. Some of the constraints on action include:
Action requires an object; one must act upon something.
In those systems called organizations, the objects of action include people, processes, policies, procedures, materials, information, financial results, and almost any other feature or situation one might imagine.
The purpose of action is to change the object being acted upon. These changes or effects may be characterized as follows:
Objects are often found or arranged in purposeful, patterned, dynamic relationships called systems.
In systems, change is typically indirect, that is, you don't change it, you change something else and it changes as a result.
Those patterned relationships called systems are also known as structures and problems may be viewed as embedded in these structures.
A solution is a course of action that, once carried out, changes the structure in which the problem is embedded in such a way that the original requirement to act is eliminated and no new problems are created (Barnard, 1938).
A problem may be said to exist in any situation where action is required and there is uncertainty regarding the action to take.
Uncertainty regarding the action to take might be attributable to uncertainty regarding any of the following factors or combinations thereof:
Uncertainty regarding the action to take is reduced by:
Given adequate knowledge of a system's structure, it is possible to say, for any given effect, the action(s) that will produce it and, for any given action, the effect(s) it will produce. It is possible, therefore, to engineer solutions.
References and Other Selected Sources
The sources listed below are those that have influenced my own thinking about problems, solutions, problem solving, solving problems, solution engineering and the engineering of solutions to problems. Some were cited in the text above. Think of them as possible resources. Please note that they are listed chronologically, oldest to newest.
This page last updated on June 27, 2015