Working Smarter : Problem Solving

What do Shooting Down Enemy Airplanes and Solving Business Problems Have in Common? - Part 2

Aaron Stannard — Wed, 09 Sep 2009 15:04:00 GMT

Introduction

As I indicated in Part 1 of this post, there are similarities between solving the fire control problem and solving business problems. The basic problem and the basic process are almost exactly the same: hitting a moving target and the absolute necessity of having a running or continuous solution in order to do so. The easiest way of comparing the two is via a civilian version of the flowchart used in Part 1 (see Figure 2).

Got Problems?

There is no shortage of targets (i.e., problems) in the civilian world. Unlike the military, very little time is spent waiting around for the action to begin. In the civilian world, action is ongoing.

Prioritize & Select

There are always more problems to be solved than there are resources available to devote to solving them. As with targets, business problems must be prioritized and then selected. As with targets, the level of threat posed might be one criterion for setting priorities. Return on investment (ROI), that is, the ratio of the payoff of solving the problem against the cost of solving it might be another. Regardless of the criteria used, business problems, like targets, must be prioritized and selected for resolution. In a word, they, too, must be “targeted.”

Define, Measure & Monitor

This is the counterpart or equivalent of “acquire and track” with respect to a target and here is where a great many civilian problem-solving efforts go astray. Business problems are rarely defined (i.e., isolated, located and articulated); they are more rarely measured in terms of their costs and the benefits of solving them; and, rarest of all, business problems are hardly ever monitored on an ongoing basis so as to know at all times their status, their costs, the benefits of solving them and the effects actions taken are having on them. Making matters worse, problems are often asserted at the executive level, wrestled with at the middle management level and actually tackled at the line management and workforce level – all with very little two-way communication and even less mutual understanding.

Figure Out What to Do (Continuously)

Just as with the fire control problem, a solution to a business problem must be determined. And, just as with the fire control problem the solution must be kept current. Business problems are not fixed, static math problems with fixed, static solutions. When it comes to solving business problems, it is not so much a matter of coming up with a solution as it is a matter of making sure your solution keeps up with the problem.

Solving business problems is a matter of crafting an intervention, of changing things in one or more places so as to have the desired effects as measured somewhere else, often on the bottom line. In a Gun Fire Control System (GFCS), the solution is configured by a computer designed and built for that purpose. In a business, solutions are configured by people, and the solutions they configure vary with their skills, experience, biases and the problems themselves. So, if the heart of a gunnery system is the computer, the heart of a business problem-solving system is people. Moreover, instead of solving just one kind of problem, which is all that is expected of a GFCS computer, people must tackle and solve a wide range of problems. They are general problem solvers.

Got a Solution?

In a GFCS, the computer operators can tell if the computer has a solution to the fire control problem. Making that call with respect to business problems isn’t nearly as easy. If a solution is an intervention, a course of action intended to bring about certain effects, it’s important to understand just how the planned course of action will indeed produce the desired effects. If the linkages between the course of action you’re contemplating and the effects you’re seeking aren’t clear, you probably don’t have a solution.

Obtain & Assign Resources

Just as the gunnery officer on board ship cannot take a target under fire unless and until the ship’s guns have been released to his control, it is often the case that managers who are working business problems will require more and different kinds of resources than they ordinarily have under their control. There is, then, a requirement to obtain and assign resources to roles, tasks and responsibilities that must be fulfilled in order to solve the problem at hand. Frequently, this requires making a case for those resources.

Take Action

Taking action in a business setting is not a simple matter of loading and firing the guns (although it often looks that way and “hip-shooters” can be found in just about every organization). The actions necessary to solve important business problems often entail complex, multi-layered courses of actions – interventions that must be orchestrated and coordinated over time (often long periods of time). And, just as is the case with the fire control problem, these solutions, these courses of action, these interventions, must be kept current, which is to say they must be kept aligned with what is an ever-changing problem situation. Too often, I fear, we are guilty of solving the problem that was, not the one that is and certainly not the one that is about to be.

Assess the Effects

This should be an easy, almost automatic step but, unfortunately, it isn’t. This is because, as noted earlier, we often fail to adequately define, measure and monitor the problems we set out to solve. Were we to do so, noting the effects of our actions would be comparatively simple. Instead, we push measurement and assessment to the back-end of the process and there it languishes for want of interest and resources. Consequently, instead of a steely-eyed assessment of the effects of actions taken, what frequently happens is that those in charge declare victory; they announce that the problem has been solved and all concerned move on to whatever situation is now center stage.

Results as Desired?

As the preceding item suggests, this decision is often made in a de facto manner, the consequence of declaring victory. Successes are claimed, failures are buried and the problem is swept under the rug until such time as it resurfaces, often bearing a new label and just as often being made the target of old solutions also bearing new labels. But, if the decision is an honest one, the problem either has been solved (or affected to an extent such it is no longer a priority) or it remains a focal point for action. Again, the importance of maintaining a “running” solution is apparent.

Summary & Conclusions

As I asserted at the beginning of this two-part post, I am convinced that much of what I know about solving problems I learned as a Fire Control Technician (FT) in the Navy. The lessons I learned go well beyond the Fire Control problem itself. I also learned to troubleshoot complex systems, a form of problem solving known as “fault isolation” and which lies at the heart of the much-vaunted Kepner-Tregoe approach. The two most important lessons I learned are these:

1. Problems are dynamic and solutions must be dynamic as well; moreover, solutions must keep pace with the problems they are meant to solve;

2. All problems are embedded in some larger structure and the solution to the problem lies somewhere in that larger structure.

Can what I learned be passed along to others? I think so. I’ve tried to do that with many of the articles I’ve written about problem solving, solving problems and an approach I call “Solution Engineering.” I hope others find this post and my other articles helpful in honing and otherwise improving their own problem solving skills.

Click here to read Problem-Solving Lessons Learned in the Navy, Part 1.

About the Author: My name is Fred Nickols. I am a writer, an independent consultant and a former executive. Visual aids of one kind or another have played a central role in my work for many years. My goals in writing for SmartDraw’s Working Smarter blog are to: (1) provide you with some first-rate content you can’t get anywhere else, (2) illustrate how important good visuals can be in communicating such content and (3) illustrate also the critical role visuals can play in solving the kinds of problems we encounter in the workplace. I encourage you to comment on my posts and to contact me directly if you want to pursue a more in-depth discussion.

What do Shooting Down Enemy Airplanes and Solving Business Problems Have in Common? - Part 1

Aaron Stannard — Fri, 04 Sep 2009 15:04:00 GMT

Introduction

Surprisingly, the answer to the question in the title of this post is “A Lot!”

Shooting down an enemy airplane is done by a weapons system that solves what is known as “the fire control problem.” What I learned about solving the fire control problem while serving in the Navy has been of great value to me in solving the kinds of problems I have encountered in businesses and other organizations during my civilian career as a consultant and executive. The central point I’d like to make in this post is as follows:

Most problems encountered in organizations are dynamic. They are, as people so often say, “moving targets.” There is not and can never be a static solution to a dynamic problem. The first lesson to be learned from the fire control problem is this: to hit a moving target requires a continuous or “running” solution, one that is regularly updated to reflect the current situation. Dynamic problems are not “defined” and then “solved.” Instead, the definition of this kind of problem evolves over time as does its solution. Dynamic problems must be measured and monitored, just as targets are tracked. If you do not approach dynamic problems in this fashion, you are likely to solve the problem that was, not the problem that is.

Solving the Fire Control Problem

With the exception of stationary targets ashore, the basic problem to be solved is that of hitting a moving target, of putting a projectile or some other explosive device where the target will be – and to do so from a platform that is itself in motion. The calculations involved in performing this feat constitute what is known as “the fire control problem.” The flowchart in Figure 1 illustrates the basic process of taking a moving target under fire and, if all goes well, of destroying or disabling it. A guided tour of this process follows.

Got Targets?

A target might be a convoy, an ammo dump, a bridge, a road, a concentration of enemy troops, an enemy ship, an enemy aircraft or even a missile. Except in actual combat or during training exercises, there are no targets. But, once the fighting starts, numerous targets present themselves.

Prioritize & Select

Owing to the presence of multiple targets offering varying degrees of threat it is necessary to select the target to be taken under fire. This typically happens as a consequence of prioritizing targets based on the degree of threat they present – to your ship or perhaps to some other ship or assets you are trying to protect. You can’t take all targets under fire simultaneously; you must choose.

Acquire & Track

Once a target is selected or “designated” the task at hand is one of acquiring and tracking the designated target. The component of the Gun Fire Control Systems (GFCS) that serves this tracking purpose is the fire control radar. Once acquired, the target’s position and movement can be monitored and tracked. This information is fed to another component of the GFCS, the GFCS computer.

Solve the Fire Control (FC) Problem (Continuously)

The target is moving, the ship is moving, the deck of the ship is rolling and pitching and, in the case of a piloted aircraft, the pilot doesn’t want to be greeted by a projectile and so the target is frequently taking evasive action. Figuring out where the target will be and calculating gun orders so that when the gun is fired the projectile will intercept the target is the job of the GFCS computer. Most important, it maintains a “running solution” (i.e., it solves the fire control problem on a continuous basis). Static solutions won’t do. Everything involved is changing continuously and the solution must keep pace. Otherwise, there is no hope of hitting a moving target.

Got A Solution?

Once the solution stabilizes, the gunnery system is ready to do its job.

Bring the Guns to Bear

The gun mounts can be swung out, matched up with the orders being sent from the computer and the guns can be placed in automatic. Everything is ready.

Commence Firing

Assuming the target being tracked is still the priority and the solution to the fire control problem is being maintained, the guns are loaded and the command to commence fire is issued.

Assess the Effects

Basically, this is a matter of determining if the bullets hit the target or, in the case of projectiles with proximity fuzes, if they came close enough to the target to detonate and do enough damage to make the target no longer of interest. In any event, the effects of firing on the target must be determined.

Target Destroyed?

If it’s been destroyed, you can cease firing, look for and take under fire other targets or, if there are no more targets, you can simply cease firing altogether. But, if the target has not been destroyed or sufficiently damaged to render its threat of less consequence than other targets, you will keep firing and that entails ensuring that you still have a solution to the fire control problem. The target might have broken track and you will have to reacquire and track it, then solve the fire control problem again (and keep solving it) so as to take the target under fire again.

The Civilian Version: Solving Business Problems

Guess what? Things aren’t all that different in the civilian world. There, too, the targets of interest are often moving targets. Change permeates everything. And, as is the case with the fire control problem, the rate of change is a critical factor. As I was to learn to learn when I entered the civilian sector, the process of solving business problems has a lot in common with the process of solving the fire control problem. In the next portion of this post, we’ll look at some of those commonalities.

Click here to read Problem-Solving Lessons Learned in the Navy, Part 2.

Four Tips for “Beefing Up” Your Problem-Solving Tool Box – Part Four

Rich — Mon, 04 May 2009 09:25:00 GMT

This is part four of a four-part guest post contributed by Fred Nickols, Managing Partner of Distance Consulting LLC. All four parts focus on improving your problem solving efforts.

Tip #4: Draw pictures of the structure of the problem

A picture or model of the elements and relationships in a problem situation will help you to more quickly and more completely grasp the situation and figure out what to do about it.

Consider, for example, the diagram shown in Figure 4. It depicts the structure of a general-purpose work system. The elements of this system include inputs, a processor, outputs, a controller, and two control loops. On the front end of this system is a task initiation loop and on the back end is an evaluation and termination loop (the dotted lines). The relationships among these elements are such that inputs to the work system interact with the processor. The interactions between inputs and processor, which typically consist of prefigured routines, are referred to as “processes.” These processes produce the work system’s outputs. All this occurs under the watchful eye of the controller.

If the outputs of the work system are faulty, several possibilities are suggested by the structure of the diagram in Figure 4. The inputs might be faulty. The processor or the controller might be malfunctioning. Perhaps one or the other or both of the control loops is open and no information is getting through. Whatever the contributing factors, the diagram provides guidance regarding places to look for what might be causing the problem and for what might have to be changed in order to solve it.

The use of diagrams or schematics as an aid to problem solving is not new. Technicians have been using schematics as troubleshooting aids for years. Computer programmers and systems analysts are familiar with, if not dependent on, flowcharts and data structure models. Industrial engineers have relied on process flow diagrams ever since the days of Frederick Winslow Taylor. Diagrams and schematics should be found in your problem solving toolbox too.

Most important, get in the habit of visualizing the problems you tackle.

More Information

This is an edited excerpt from a longer piece titled “Ten Tips for Beefing Up Your Problem Solving Tool Box” that appears on Fred Nickols’ articles web site (www.skullworks.com). Many other articles dealing with problem solving and additional workplace-related subjects can be found there as well. Fred can be contacted by e-mail at nickols@att.net.

Be sure to read the previous three parts of this article from Fred Nickols.

If you liked this post, make sure you subscribe to our RSS feed or follow us on Twitter.

Four Tips for “Beefing Up” Your Problem-Solving Tool Box – Part Three

Rich — Wed, 29 Apr 2009 09:28:00 GMT

This is part three of a four-part guest post contributed by Fred Nickols, Managing Partner of Distance Consulting LLC. All four parts focus on improving your problem solving efforts.

Tip #3: Think of problem solving as a “cover-the-bases” activity

Information does not make itself available to suit the requirements of anyone’s problem solving process. Solving a problem in a complex organization has much in common with detective work. We are forced to follow leads and unearth clues. Further, it is generally the case in complex organizations that no one individual possesses all the information necessary to solve a given problem. Vital information appears in bits and pieces. We have different backgrounds, perceptual filters, and value priorities. Different people seek and assimilate information in different ways.

Consequently, if you listen carefully to almost any discussion of a problem in a group setting, what you’ll hear is conversation that shifts from problem to symptom to cause to solution and back again, often in no particular order. Such “bouncing around” is natural. Don’t worry about it. Above all else, don’t try to force yourself (or others) to follow some lock-step, linear process. The task of problem solving is very much a type of intelligence work, a matter of piecing things together.

A systematic approach is necessary but the point of having one is to make sure you tend to all the things that need tending to, that you “cover the bases,” not trot around them in a 1-2-3 fashion. Figure 3 depicts a set of 12 “bases” to be covered or tasks that typically need tending to in the course of solving a problem.

Ordinarily, bases 4 and 5 are mutually exclusive; you do one or the other but not both. If you’re dealing with a problem where something has gone wrong, then your best bet, at least initially, is to focus on finding and fixing the cause of the problem. On the other hand, if you’re out to achieve some state of affairs never before attained, or if the cause of the problem has been found but can’t be corrected, then you’ll have to design and engineer a solution to the problem. In either case, you’ll have to settle on a course of action and carry it out.

Be sure to check back for part 4 from Fred Nickols. To read part one click here. To read part two click here.

If you liked this post, make sure you subscribe to our RSS feed or follow us on Twitter.

Four Tips for “Beefing Up” Your Problem-Solving Tool Box – Part Two

Rich — Mon, 27 Apr 2009 08:46:00 GMT

This is part two of a four-part guest post contributed by Fred Nickols, Managing Partner of Distance Consulting LLC. All four parts focus on improving your problem solving efforts.

Tip #2: Be clear about all of your goals and objectives

Ultimately, the aim of problem solving is action. To engage in problem solving is to search for a solution. A solution is a course of action that produces the solved state. To actually solve a problem is to implement the solution that has been found and demonstrate that it works. Solving problems requires intervention as well as investigation.

Intervening in complex organizations requires of us that (a) we are clear about all our goals and objectives and that (b) we carefully think through the likely effects of any actions we are contemplating.

Actions taken in an organizational context often “ripple” outward from the point of intervention, sometimes having unforeseen and unintended consequences. Our goals and objectives, therefore, are typically multi-dimensional; that is, we seek to eliminate some conditions, and to achieve others. There also are conditions we seek to preserve or avoid. (See Figure 2, the Goals Grid).

If we don’t want something that already exists, our goal is typically one of eliminating it. If we want something that doesn’t exist, our goal is ordinarily one of achieving it. Four categories of goals and objectives can be derived from the interplay of our perceptions and preferences: Achieve, Preserve, Avoid, and Eliminate.

For any problem situation, it is useful to ask the following questions as a way of clarifying all your goals and objectives:

What are we trying to achieve?
What are we trying to preserve?
What are we trying to avoid?
What are we trying to eliminate?

These same questions are also useful in examining any contemplated course of action. For example, if you’ve decided to solve the problems with a legacy accounts payable system by replacing it with a popular commercial version, you are well-served by asking the questions above in relation to that new accounts payable system.

Be sure to check back for parts 3 and 4 from Fred Nickols. To read part one, click here.

If you liked this post, make sure you subscribe to our RSS feed or follow us on Twitter.

Four Tips for “Beefing Up” Your Problem Solving Tool Box – Part One

Rich — Tue, 21 Apr 2009 14:54:00 GMT

This is part one of a four-part guest post contributed by Fred Nickols, Managing Partner of Distance Consulting LLC. All four parts focus on improving your problem solving efforts.

Introduction

Problems come in all sizes, shapes, and colors. There is no guaranteed step-by-step or “by the numbers” process for solving every problem we encounter. We must instead configure or adapt our problem solving processes to fit the problem at hand. As problem solvers, we have more in common with the cabinet-maker than with the assembly-line worker. What we need, then, are plans and blueprints, high-quality materials, a decent place to work, a well-stocked tool box, and the knowledge and skills necessary to properly select and use the tools in it. Toward that end, here are four tips for “beefing up” your problem solving toolbox.

Focus on clearly defining the solved state.
Be clear about all your goals and objectives.
Think of problem solving as a “cover-the-bases” activity.
Draw diagrams and otherwise picture the structure of the problem.

Tip #1: Focus on clearly defining the solved state

Pay at least as much attention to the solved state as you pay to the problem state. As Robert F. Mager’s fable of the sea horse reminds us, “If you’re not sure where you’re going, you’re liable to end up someplace else—and not even know it.”

When solving a problem, we typically wish to do more than simply rid ourselves of some unacceptable situation. More often than not we are trying also to achieve some other, more desirable state of affairs.

Conceptually speaking, we’re trying to move from the problem state (a) to the solved state (a’). We do so by traversing what is called “the solution path” (see Figure 1).

It seems obvious that if we do not focus some of our attention on the solved state, the likelihood of attaining it is diminished. Unfortunately, the problem state typically attracts all our attention. The squeaky problem state wheel gets the grease. On occasion, this is an appropriate response. If the roof is caving in, then discussions about where to go can wait until we’re safely outside.

But, if we’re not in an emergency situation and if we still have nothing more in mind than doing something to rid ourselves of the problem state, we can create situations where the solution to one problem creates one or more new problems. Solutions that create new problems are “inefficient” solutions. An “efficient” solution is one that creates no new problems.

Perhaps the best-known step in any problem solving process is the one most people think of as the first step: “Define the Problem.” This is probably the most misunderstood and poorly executed step in the process. For many people, “Define the Problem” means simply to provide a written statement of the problem. There is much more to it than that. To define means to establish boundaries, to encompass, to enclose, to locate, to isolate, to distinguish, to differentiate, to set apart. To define the problem state (or the solved state) means, at the very least, to do the following:

To establish boundaries; to delineate (Locate).
To give distinguishing characteristics; to differentiate (Isolate).
To state the nature of; to describe precisely (Articulate).
To state the meaning of; to provide a definition (Explicate).

Rarely are definitions of the problem state or the solved state crystal-clear up front. Clarity typically develops over time. In many cases, the definition of a problem may be considered complete only after the problem has been solved. Until then, it is a shifting, evolving, changing part of the process. Thus, although “Defining the Problem” is a good step with which to begin the problem solving process, it is only a starting point and it must be revisited on a regular basis. This also is true of any definition of the solved state.

There are several ways of focusing on the solved state. One is to define it the same way we would define the problem state. Another is to list possible measures or indicators of its attainment. Ask yourself questions like these: “How will I know the problem has been solved? What will I accept as evidence? What does the solved state look like?” Yet another way is to be clear about all the goals and objectives of the problem solving effort. (This last point is so important that it constitutes a tip all its own—the next one.)

Be sure to check back for parts 2, 3 and 4 from Fred Nickols.

If you liked this post, make sure you subscribe to our RSS feed or follow us on Twitter.