Bias in Visualization

When faced with a large amount of data, one if the first things I do is graph the data in some way to get a visual impression. I'll even graph simple linear calibration plots since a quick glance will give a better impression of the data than looking at the slope, intercept and correlation coefficient. In this case, the visualization shows more than the individual data.

However, the opposite can happen, even though I'm sure you're familiar with the adage, "a picture is worth a thousand words." Recently the Flowing Data site held a visualization contest. The results were interesting. Even though everyone started with the same data set, each visualization tended to emphasize something different about the data set. As a whole, the visualizations presented a complete picture and highlighted aspects of the data one couldn't see from just the numbers, but each individual visualization tended to focus on one thing at the expense of others.

This may be your intent when visualizing data, but watch out for your own bias. Always include the data used to create your visualization (or when this is not practical a reference to it) so that others with a different perspective can visualize the data their own way and perhaps glean something different than you did.

There is fine line between illuminating data for your audience and prejudicing them.

FreeMind

Sometimes when I'm brainstorming ideas about a problem or perhaps involved in a root cause analysis, there isn't a clear way to record the ideas in a word processing program. Perhaps the ideas are unrelated or you are jumping around. How do you visualize the brainstorming?

One useful tool is mind-mapping software. There are several commercial tools out there but if you just want to see whether you could use it or get a better idea, try FreeMind. It allows you to quickly record your ideas and link them together. There is a lot of flexibility in formatting that allows you to visualize your thoughts and how they are (or aren't) related. I even tried to use it as a mini-database to keep track of projects I was working on. You can attach documents and make links so it works as a high level indexing system if you take the time to set it up properly. The nice thing is that with just a glance, you can visualize what you're working on.

Document Design

Much has been published about good design of information graphics. Tufte's and Stephen Few's books The Visual Display of Quantitative Information and Show Me the Numbers are definitely books you should read if you make graphs and tables of data.

I just finished an equally useful book directed more at the text documents you create. Robin Williams' The Non-Designer's Design Book is definitely a book everyone (including technical people) who creates documents should read. It's easy reading and she gives many simple, concrete examples of how to make your documents stand out. I'm no designer and pride myself on avoiding fancy-shmancy graphics that don't add value but this book points out simple things anyone can do to stand out.

Anything that can help communicate your problem solutions to others effectively is adding value.

E-mail Subjects

In the problem solving process you frequently send e-mail communicating status and results. We all know that our e-mails should contain a subject. However, I suggest you go one step further. Your e-mail subjects should contain a concise description of what the message is about. Even better, include some keywords or even the conclusion or primary finding of the e-mail. Sort of like tagging posts in your blog.

The people you provide results to are often higher level managers. They are probably inundated by Data Smog. Your message needs to stand out and hopefully be easily located by whatever indexing method your addressees use. Not everyone sorts things the same way so try to add keywords that search programs will find. If you are referring to a specific project, start the subject line with that project name. But don't just conclude the message with 'latest results' or 'update'. Do something meaningful to you and your audience.

Don't assume everyone is as intrigued by your project as you. Make sure you communicate effectively.

Looking for Trouble

One way to evaluate someone is how well they look for trouble. No, I'm not talking about whether they are a miscreant painting graffiti on trains. Rather it is whether they find inefficiencies and fix them or (even better) whether they can anticipate future problems.

As one develops expertise in an area, you hopefully progress through the following stages:

1. Procedure follower
2. Procedure interpreter
3. Problem solver
4. Problem definer

Early on, you just don't know enough about a subject. You simply go about following procedures and making sure you do them as written. Hopefully you quickly progress to someone who can interpret procedures. You don't have to be shown every little step and can instead be given general instructions. "Go to the store and pick up a gallon of milk" is much different than,

1. Get you coat and car keys.
2. Get in the car.
3. Start the car.
4. At the end of the driveway, turn right...

You get the drift.

Next you are at the level where you solve problems. You don't just follow procedures, but you are able to notice that the refrigerator doesn't contain any milk and you know what to do (or can develop a plan) about it.

Finally you reach a problem definer. A problem definer looks at the big picture and recognizes changes elsewhere that will lead to problems in your area of concern. i.e. You realize that your 8-year-old is now 15 and can drink a gallon of milk every other day. Your former custom of buying milk once a week isn't going to work and you are going have change your mode of operation to avoid the situation of opening the refrigerator and not finding any milk on a regular basis.

How well do you look for trouble? Does it creep up on you unexpectedly? Are you continually having the same problem? If so, you should examine yourself. You are probably just a problem solver. You need to look at your problems from a broader, more diverse perspective to determine if you are missing something.

Be a problem definer!

Dueling Kaizens

My last post about types of solutions brought to mind an experience we had with Kaizen events.

The first Kaizen event tackled a quality issue with one of our analyses and implemented a rather complex solution, which while providing more accurate results, led to a much more complicated maintenance. The second Kaizen event focused on the maintenance complexity and ended up undoing the work of the first team to make the maintenance quicker and simpler. Two Kaizen events ended up with a net zero change in the analysis. Needless to say, this was discouraging as well as a waste of money.

How did this happen? The Kaizen teams were made up mostly of those outside the group and one technician from the lab. Neither team had any members in common. The teams also did not have anybody who understood the overall problem and therefore focused on the one aspect they were challenged with. They were successful at the details but not in the overall problem.

Ultimately the lab chemists and technicians looked at the problem together and realized that the issue was not with the analysis itself, but with the environment the analysis was being done in. Improving the conditions under which the analysis was being performed, ended up solving both issues.

The advantage of bringing those unfamiliar with the process into a problem solving situation is that they have a beginner's mind. The disadvantage is that they don't have a full understanding of the situation. Although their input is valuable, they can't be allowed to dominate the process over those more familiar with the problem.

Kaizen and Innovation

Problem solutions can be realized in three ways,

• studying a problem and developing a solution
• small incremental improvements which will ultimately lead to a solution (Kaizen)
• a major break-through (Innovation)

The first is the most common way scientists and engineers tackle technical problems they face. The problem is analyzed, potential solutions are developed, tested and measured to see if they are effective, and ultimately implemented and monitored to insure continuing success. (DMAIC)

The other two approaches have their place in any successful organization and they should be cultivated by management.

The advantage of Kaizen is that it can be done by anybody in the organization. It many cases it is most effective when those actually doing the work are suggesting and making the changes with the help of engineers or those who have the bigger picture in mind.

Innovation is more of a serendipitous event. There is no formula or process you can follow to have innovation. However you can strive to develop an environment that is fertile for innovation to occur. I'll comment more about this in a later post.

What is your area of strength? Are you the problem solver, continuous improvment person, or an innovator? As individuals, we have a tendency to fall into one or the other area primarily. However you shouldn't neglect the others. If you are a problem solver, take some time to look for minor improvements or do something creative occasionally.

An organization should strive to have a balance of all three. Too many organizations emphasize one at the expense of the others. Innovators may never have a chance to be heard, get frustrated and leave; or perhaps the organization is full of wildly creative people but nothing ever gets off the ground because there aren't people to implement and grind out the solution.

Look at both yourself and your organization. If you are in management, does your organization have all three going on? If you are an individual contributor, are you trying to develop skills in those areas where you are weaker?

Failure to succeed at attempts

Previously I listed several broad categories for overall failure in a system. The first three are high level issues and not really under the individual person's or small group's control. They are really a failure of management and I won't bash them (for now).

Failure to succeed at problem solving attempts however is under the control of individuals. Some reasons why a particular solution fails are

• No known solution
• Too expensive
• Too late
• Solutions backfire

You could argue that if there is no known solution, it is beyond your control. However, problems demand persistence and innovation until a solution is found. The same could be said for solutions that are too expensive. That is really a sub-set of no known solution. It is incumbent on the problem solvers to find a cheaper, more feasible solution. (Perhaps failure is the solution?).

Being too late to implement a problem solution is really a lack of vision and falls under failure to anticipate. If you have a good understanding of your process or system, then you shouldn't be caught with your pants down, unable to implement a solution in time.

Perhaps the most unforgivable reason for failure is solutions that backfire. By using the appropriate problem solving tools, in the right way, you will be able to implement solutions that will succeed. At the very least, you will be able to detect non-ideal solutions and design/fix the problems that occur. That is the heart of the DMAIC philosophy and the cycle of action. You must monitor any solution to insure it is (and continues to be) successful. Just because it worked the first time doesn't mean you can check it off your action item list and move on to the next problem. If that is happening, then I would suggest you are not truly a problem solver.

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.

Technical Problem Solving - The Site!

I finally got enough on my Technical Problem Solving site that it will be somewhat useful to someone coming across it. I've now made it publicly available. It's still very bland but my goal for now is not looks but content.

Still need to work on the navigation and links within the site, maybe add some graphics, and continue to add content.

I guess it would be interesting to get a counter on the site to see if anyone is finding it. It seems nobody has found my blog yet, but then I'm doing this mostly for my own benefit at the moment. Just trying to learn how to use the tools readily available.

Data Smog - Final Thoughts

I finished Data Smog. David Shenk proposes several antidotes (chapters 18ff) to data smog.

• Be your own filter
• Be your own editor
• Simplify
• De-Nichify
• Don't forsake government

Other than than the last one, these are all useful advice for problem solvers.

Filtering what is coming at you is critical. When encountering a problem, you must be able to sort out what is important and what is noise. At the very least you should avoid distractions unrelated to the problem. Sometimes it is difficult to know what is important without spending some time on the problem.

Editor. Ultimately you will be called on to communicate your solution to others. Don't just spout out everything you learned but consider the audience you are presenting the problem to and what they need to know. What you communicate to fellow technical people may be different from what you tell the Marketing department. I've been starting to follow some blogs related to data visualization and the general advice given there (consider your message) applies to all your communication. Also consider what you will use to communicate (e.g. graphs, text, tables, loud shouting, arm-waving...).

Simplify. Sometimes to solve a problem you will have to simplify it first to understand the bigger issues. Then you can delve into the details. Many problem solving tools are simply addressing this issue.

De-Nichify. Sometimes the solutions to the problem are already out there, just in a different form or in a different field. If you are too focused in your own specialization, you may miss a solution. Sometimes the so-called innovators are those who are successful at putting together solutions from one arena with problems from another. If you attempt to maintain a broad perspective, you will be more likely to discover a solution.

Essential Ingredients of Problem Solving

I came across a list of essential ingredients of perception attributed to Rudolph Amheim. The list is

• active exploration
• correction
• grouping
• simplification
• abstractions
• analysis & synthesis
• completion
• selection
• comparison
• combining
• separating
• putting into context.

These are all things that are elements of problem solving. Cultivating these skills will enhance your ability to solve problems.

Data Smog-2007 update

I haven't re-read Shenk's book Data Smog yet, but I found the following post by him on Slate.Com made in 2007. He makes several observations about the current state of the information glut including talking about the vastly improved tools to filter the data coming at you. Google, RSS feeds, Readers, E-mail filters are all tools I need to master in order to avoid getting overwhelmed by the torrent of data coming at me.

The danger of being too connected is still there though and I think that in order to become a good problem solver, you need to be able to unplug yourself from the 'net and focus on the problem. A quote from his article highlights the dangers of constant interruptions. "We now know, for example, that it takes an experienced computer user an average of 15 minutes to return to "serious mental tasks" after answering e-mail or instant messages." My coworkers have become enamored with the Chat function in Windows but that message box popping up becomes annoying. That and the fact that my deskbar remains in the foreground, blocking what I'm working on whenever an IM arrives prevents me from focusing intently on whatever I'm working on. The best thing is to leave my desk and go in the lab where I cannot be disturbed as easily.

A broad focus

Currently I have started reading a variety of books and surfing websites that are related to problem solving and creativity. This presents a paradox. When one focuses in a narrow field your originality can be inhibited. Therefore it is imperative to read outside your field but that creates the data smog problem. What is important and how can you avoid getting overwhelmed by all the data coming your way.

Internet RSS feeds are a great way to subscribe to a variety of blogs and news sources of particular or peripheral interest to you. This is a great way to stimulate serendipity but one must make effective use of these tools to avoid becoming inundated by the information. This is what David Shenk warns about in his book Data Smog. I've started re-reading his book and am curious to see what his solutions are. The book is a bit dated (written in late 90s) but it is interesting to see how much farther things have come since then. However I think the tools to manage the information glut are getting better. It just takes discipline to use them and experience to use them effectively

Self-learning

I came across a comment in the graphpaper.com blog on the iPhone. Down near the end, on June 27, 2008. A Sabrina Simon makes the off-hand comment about people and self-learning. "...an academic leaning that requires an audience to invest in self-learning. After 36 years in business, I have yet to encounter a management group that is so inclined." I agree that many people won't or aren't able to self-learn.

That is a big issue when it comes to problem-solving. If you are not able to self-learn, you will have difficulty solving thorny problems. If you were able to look up the answer or ask someone, then you aren't really solving a problem, it's already been solved and you are just looking up the answer. I think the web site will assume a certain amount of self-learning will go on. I'm not sure how to develop some other person's self-learning ability. That's probably why I'm not a teacher.

Hopefully by reading blogs such as this, and visiting problem-solving websites, you already show a pre-disposition to self-learn and the information I hope to compile will aide you in your education.

Organizing the Process and Tools

I've started working on the web site and can already see that see that I need a good way of organizing my work. The web site paradigm is useful in that I can use it to form an outline and then flesh out the details by adding pages and sub-pages as desired. One of the first things I'm writing about is developing a plan and then developing a procedure to follow through on that plan. The web site and this blog are essentially forcing me to follow a plan by their structure but I don't have a good way of organizing my various thoughts and things I run across in my research. That brings me to suitable tools. I've spent a little time surfing and have found the following tools to help.

Google Notebooks. This Google application sits in my browser and I can clip information I find on the internet and paste it into the notebook. That way I don't have to use bookmarks (which can get cluttered and disorganized quickly) and the Google notebook is searchable so if I lose track of where I might have found something, I should be able to re-locate it quickly in my notebook.

The other tool I've found is SuperNoteCard. I'm also doing some reading offline and things I read aren't easily transferable to the internet. This application seems like it will be useful for recording stuff I come across and then organizing it later on. I haven't paid for it yet, because I want to play a little more with it. Not that there is a steep learning curve, it's pretty intuitive - just like a stack of paper notecards - but I'm not sure if I can't accomplish the same thing with the Google notebook.

What's my angle?

As I begin to work on the website and search for information on problem solving, it is clear that there is a lot out there. Problem solving is one of the key aspects of Quality Improvement or one of the many names it is given (TQM, Lean Enterprise). In addition to the self-educating aspect of the website, it will need to have something unique that other sites or books don't have. At this moment I don't have a clear idea of this but perhaps it will have something to do with injecting creativity into the problem solving process. As suggested by my diversity of thought post, we can sometimes fail to solve problems because we don't come up with creative solutions.

Despite frequent exhortations by managers to "think out of the box", I don't think we normally are able to do this. Hopefully my site will be able to incorporate practical suggestions for ways to develop the ability to "think out of the box".

Diversity of Thought

I started reading the book "Turning Numbers into Knowledge" (I suppose this book is in many way what my website will be about). In chapter 1 Koomey talks about a "Beginner's mind" - looking at things from a fresh, unbiased perspective. I think this is an issue of Diversity of thought. My company is currently making a big deal about "Diversity" without really defining what it means. Most people are taking it to mean we have to have male/female, ethnic group, race diversity. What may be more important than such diversity is a diversity of thought (and perhaps how you approach problems). You can have all white males in a room, but if they all approach a problem from a different perspective it is just as powerful as if you had a whole mix of race/gender/ethnicity. Perhaps even more powerful because you don't spend time trying to explain things to everyone. There must be a balance, diversity to get different perspectives, but some commonality or else you never get on the same page.

I suppose my website on Technical Problem solving should address ways to cultivate diverse thinking. I myself tend to approach things pretty uniformly. I wonder if that is typical of all people? If you can cultivate diverse thinking, then you can become a great problem solver since you don't have to waste time explaining things to yourself.

data, information, & Knowledge

Several years ago I read the book "Data Smog". The central premise of this book (as I remember it) was that we are being overloaded with data. I don't recall much about how one was supposed to deal with the issue. I suppose I should re-read that book since I expect it went beyond being a diatribe about data overload, but this blog and associated website are about the process of distilling Knowledge out of information which in turn comes from data. We are inundated with data and being a successful problem solver means that we must be able to obtain information from that data. Obtaining information alone is insufficient. I may have access to lots of information but if I don't act on it or use it, it is just information and not knowledge. I can be sitting in the middle of the Library of Congress and if I don't use that information, I have no knowledge. Knowledge is information in action.

I guess without a problem to solve, then knowledge is just information since you can't put it into action. Until I have a problem, I have no use for all that stuff in the library.

Initial Thoughts

In an attempt to compile, summarize, and make use of a variety of problem solving techniques and approaches, I have begun two simultaneous approaches. The first is a blog where I hope to document the process of creating a website devoted to technical problem solving. By documenting the process, I will hopefully be able to mine some useful information about the process. Also I suppose it will be used to track changes in my thoughts and the process over time and help me to find my way. As I have written on the website, this is in itself a problem solution and may be useful to others (and myself) in observing (reviewing) the process.

Today I created the website http://sites.google.com/site/technicalproblemsolving/ and posted some introductory comments. Pretty soon I need to establish an outline of the subjects I intend to cover. As is obvious by this item, I also created this blog.