Failure

In Chapter 14 of his book Collapse: How Societies Choose to Fail or Succeed, Jared Diamond lists general reasons for failure of societies and their ultimate demise. These apply also to working with technical problems. If you don't succeed at problem solving you will ultimately be out of business. I'll just list them now as food for thought and ruminate on each of them later on.

• Failure to anticipate
• Failure to perceive a present problem.
• Failure to try to solve a problem
• Failure to succeed at attempts to solve the problem
  

My website is primarily directed at providing assistance in solving known problems, but taking a look at the big picture of why you get into problems in the first place is beneficial. Ideally, one anticipates problems before they happen and work out solutions proactively. That is the reasoning behind FMEA (Failure Mode & Effects Analysis). Even though you may not have had prior experience of failure of your process or system, or failure may have occurred in the past, FMEA is a tool for detecting weaknesses and developing safeguards.

Measurement

I've neglected to mention the importance of measurement in problem solving. The Six Sigma process emphasizes measurements and statistics to make sense of those measurements. Unless you measure the current state, and the state after implementing changes or improvements, you cannot claim success. Measurement is the foundation of problem solving. Before you can visualize, or model, or even brainstorm solutions, you must be able to characterize the current state.

Remember when you were a kid and your parents would mark your height on something so you could track your growth? Measurement must be done to show progress. Perhaps you've gone on a diet. Sure you feel better as you lose weight, but you don't go by those feelings alone, you check your weight (and perhaps your waistline) frequently to track your progress.

Without measurement, you are blind to your current situation and how it may (or may not) change.

The Art of Problem Solving

I've written about visualization as a way to solve problems.

Here's a visualization of the problem solving process itself. I like it so much I've added it to my links in the sidebar.

Nice!

Modeling

Modeling is a way to combine play, mapping, and visualization. Many of us built models when we were kids. Looking back, it was a great way to learn the parts of a car. My brother even had a model of a V8 engine with all the pistons, pulleys, camshaft etc. I still visualize that model when it comes to problems with my 4 cylinder turbo-charged engine in my VW.

Consider how modeling might help you solve your problem. A model might be a physical model, a computer simulation (everything from weather-prediction models using supercomputers to a simple Excel spreadsheet), or maybe a diagram sketched out on a napkin. Once you have a model, feel free to play with it, make changes and see what happens. Remember it's only a model and there will be aspects of the real situation that they don't model, nevertheless, a model is a great way to develop some intuition about your situation.

Excel is a great way to build a simple model of many systems. Take some time to get familiar with Excel and move beyond simple formulas and formatting. If you're using Excel to make pretty tables or just keep lists, you're missing a lot. There are a lot of resources on the internet for Excel. Two of my favorites for picking up tips and new techniques that I can use are Pointy-Haired Dilbert and Peltier Technical Services. One of them had a great method for randomizing a list which I now use routinely to run my analysis samples in random order to avoid time effects in my analysis.

Beginner versus Expert

Since my last post I have been doing some thinking about the Beginner's versus Expert mind. Clearly there must be balance between these two extremes. One the one hand, you want someone experience working on the problem. When you have bypass surgery your main concern is how many times your doctor has performed one. You don't look for a resident who has only watched a bypass surgery in the hope that they will come up with an innovative approach. On the other hand, an expert may jump to conclusions based on past history and miss a nuance that points to a different solution.

The same processes that make us creative by allowing us to see relationships between seemingly unrelated things can lead to error. Drawing conclusions from small amounts of information can help you react/respond to new situations but sometimes we jump to conclusions, classifying a new situation as an old one even when there are significant differences.

How to avoid this pitfall of the expert? It is critical to always circle back and evaluate your solution to insure it is working. Problem solving involves a cycle - it is never a single pass.

Play as a problem solving tool.

The Presentation Zen blog had a post today about play and refers to the beginner's mind. I touched on the beginner's mind before in my Diversity of Thought post. The PZ blog does much better job of stimulating thoughts about play than I could so I thought I'd just direct you there. Read the post with a problem you have in mind.

Problem solving often requires a fresh perspective. Play frees the mind from whatever rut you are in.

Mapping

Another form of visualization that is useful is mapping. One of our most keen sense is vision and our brains are highly adapted to processing visual inputs. Creating a map of whatever process you are trying to troubleshoot is a great way to for you to visualize what is going on. Particularly if it is a team problem solving situation and not everyone has an idea of the whole process and may only know about details of certain portions of the process. Mapping works for physical processes like a refinery and soft ones like order processing. Both big and small.

One of the reason high level programming languages are so great is that they create a map as part of the program. The more structured your code is, the better you (and others) can understand it and debug it.

When creating a map, don't get bogged down in the details. Create a high level map first, then you can go about filling in the details.

Proactive versus Reactive

I was reading Seth Godin's blog and found his post about Reacting, Responding & Initiating. His thoughts are pertinent to problem solving also.

The term "problem solving" implies that you are reacting to a situation. This may be true but the ultimate problem solution is to anticipate problems before they occur. Initiate solutions before the problems even occur. This is the root behind much of the Quality philosophy. A problem avoided is priceless since low quality (problems) hurt you in so many ways, some of which can't be quantified.

Are you reacting to problems that have occurred, responding to external data which indicates a problem is imminent (e.g. a trend on a statistical process control chart) or are you initiating solutions to weaknesses in whatever process you are working on?


- I guess I'm reacting to Seth's posting - we can't always be initiators!

Visualize

I have started following a number of blogs related to visualization. Since I'm a technical person, these are primarily related to visualization of data such as Flowing Data, Pointy-Haired Dilbert, and Me, Myself, and Blissantz. Putting aside the specific area of data visualization for now, visualization in general is important in problem solving.

Do you have an overall view of whatever you are trying to deal with? If it is a piece of equipment, do you have a block diagram in mind? How much do you know about the pieces? Problem solving often requires you to isolate the cause of the problem. Without a good mental picture of the equipment, you cannot begin to determine the problem source. When I was in school, we always worked with older equipment. This was great since you could open it up and look inside and figure out what the parts did. Unfortunately much equipment is getting miniaturized and controlled entirely by external software and it is getting harder and harder to open it up and visualize what is going on inside of it. When you are faced with an entire tool on a microchip its pretty hopeless. However, I still refer back to my mental pictures of equipment that I formed 20 years ago, opening up spectrometers when dealing with equipment that has now become extremely self-contained.

If you don't have a good mental picture of what you are dealing with, you should make it a priority to develop one. Perhaps there is some old equipment in storage that you can poke around in. Perhaps some more experienced coworker can provide you a picture. Read the manual. Whatever approach you choose, striving to visualize the hardware you have is imperative.

As we move deeper and deeper into a virtual world, it pays to have your feet in the real world.

Inquire

Now that my site is at least superficially present, I hope to start using this blog to point out useful links that I come across and also throw out some ideas to make you think about how to become a more effective problem solver.

The first suggestion is: Inquire. If you notice something unusual in your data, inquire! Often you will learn more from a single unusual data point than from looking at reams of usual data. Statistical process control is a great example of this. Often we are tempted to ignore outliers but in reading any process control text there's a lot of emphasis put on dealing with outliers. Typically the outlier has a unique cause associated with it and if you can determine the cause, you will learn more about your process than from all the in-control data. An example of learning from your mistakes. An outlier is not necessarily a mistake, sometimes the value is actually desirable. Recently we noticed a particularly good section in one of our control charts. Why? Once we figure out why, we have a great opportunity to improve our process.