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.