<?xml version='1.0' encoding='UTF-8'?><?xml-stylesheet href="http://www.blogger.com/styles/atom.css" type="text/css"?><feed xmlns='http://www.w3.org/2005/Atom' xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/' xmlns:georss='http://www.georss.org/georss' xmlns:gd='http://schemas.google.com/g/2005' xmlns:thr='http://purl.org/syndication/thread/1.0'><id>tag:blogger.com,1999:blog-4544803008461181295</id><updated>2011-09-26T14:29:52.195-07:00</updated><category term='Network'/><category term='Modelling'/><category term='Measurement'/><category term='Root Cause'/><category term='Diversity'/><category term='Evaluation'/><category term='Visualization'/><category term='Statistics'/><category term='Uncertainty'/><category term='Distraction'/><category term='Improvement'/><category term='Simplicity'/><category term='Focus'/><category term='Creativity'/><category term='Consumption'/><category term='Failure'/><category term='Bias'/><category term='Learning'/><category term='Organization'/><category term='Database'/><category term='Tools'/><category term='Beauty'/><category term='Iteration'/><category term='Randomness'/><category term='multi-tasking'/><category term='Process'/><category term='Imagination'/><category term='Data Smog'/><category term='Communication'/><category term='Optimization'/><title type='text'>Technical Problem Solving</title><subtitle type='html'></subtitle><link rel='http://schemas.google.com/g/2005#feed' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/posts/default'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default?max-results=100'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/'/><link rel='hub' href='http://pubsubhubbub.appspot.com/'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><generator version='7.00' uri='http://www.blogger.com'>Blogger</generator><openSearch:totalResults>71</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>100</openSearch:itemsPerPage><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-6898509091697480985</id><published>2011-04-09T07:39:00.000-07:00</published><updated>2011-04-09T07:44:49.931-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Improvement'/><category scheme='http://www.blogger.com/atom/ns#' term='Failure'/><title type='text'>James Dyson and Failure</title><content type='html'>I've posted regarding failure and problem-solving before. I came across &lt;a href="http://www.wired.com/epicenter/2011/04/in-praise-of-failure/all/1" target="blank"&gt;this&lt;/a&gt; by James Dyson on Wired.com, arguably one of the more famous inventors of our time and his thoughts on failure.&lt;br /&gt;&lt;br /&gt;Too often we're afraid to fail. Whether because of embarrassment, cost, or safety issues. However, it is one of the best ways to learn. Very few of us can manage to solve problems entirely in theory and place them into practice flawlessly.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-6898509091697480985?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/6898509091697480985/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=6898509091697480985' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/6898509091697480985'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/6898509091697480985'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2011/04/james-dyson-and-failure.html' title='James Dyson and Failure'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-2743120557060528149</id><published>2010-12-10T18:58:00.000-08:00</published><updated>2010-12-10T19:18:10.014-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Focus'/><category scheme='http://www.blogger.com/atom/ns#' term='Creativity'/><category scheme='http://www.blogger.com/atom/ns#' term='Improvement'/><category scheme='http://www.blogger.com/atom/ns#' term='multi-tasking'/><title type='text'>Breaks versus Interruptions</title><content type='html'>It is a good idea to take a break when working on a problem for a variety of reasons.&lt;br /&gt;&lt;ul&gt;&lt;li&gt;Overcoming mental blocks.&lt;/li&gt;&lt;li&gt;Getting a fresh perspective on a problem&lt;/li&gt;&lt;li&gt;&lt;a href="http://technicalproblemsolving.blogspot.com/2010/07/isolation-and-creativity.html?showComment=1280922079707#c4492087663760006081" target="_blank"&gt;Incubation &lt;/a&gt;&lt;br /&gt;&lt;/li&gt;&lt;/ul&gt;However, interruptions destroy the momentum you've built up.  Some of the more obvious forms of interruptions.&lt;br /&gt;&lt;ul&gt;&lt;li&gt;Instant messages&lt;/li&gt;&lt;li&gt;E-mail notifications&lt;/li&gt;&lt;li&gt;Co-workers&lt;/li&gt;&lt;li&gt;Phone calls&lt;/li&gt;&lt;/ul&gt;To remain productive you must take &lt;span style="font-style: italic;"&gt;breaks&lt;/span&gt; rather than experience &lt;span style="font-style: italic;"&gt;interruptions&lt;/span&gt;.  The fundamental difference is that &lt;span style="font-style: italic;"&gt;you&lt;/span&gt; &lt;span style="font-style: italic;"&gt;decide&lt;/span&gt; when to take a break. &lt;span style="font-style: italic;"&gt; Other people&lt;/span&gt; &lt;span style="font-style: italic;"&gt;decide&lt;/span&gt; when to interrupt you.&lt;br /&gt;&lt;br /&gt;If you're a manager, make sure the people that work for you are free of interruptions.  Perhaps designate certain time periods where people can be off the grid, focusing on the difficult problems. Then other times when interaction is encouraged.  Both are important and so you need to make time for both.&lt;br /&gt;&lt;br /&gt;If you're not a manager, perhaps block off time in your calendar, turn off the instant messaging and E-mail notifications so that you can't be bothered.&lt;br /&gt;&lt;br /&gt;I wonder if anyone has ever studied the workplace and the amount of interruptions that modern day workers encounter and the effect on productivity.  Although we're more productive today because of technological advances, we may now be turning the corner where we are becoming less productive due to the inability to focus on problems.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-2743120557060528149?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/2743120557060528149/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=2743120557060528149' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2743120557060528149'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2743120557060528149'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2010/12/breaks-versus-interruptions.html' title='Breaks versus Interruptions'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-5853651414527493793</id><published>2010-11-05T16:24:00.000-07:00</published><updated>2010-11-19T17:07:47.175-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Diversity'/><category scheme='http://www.blogger.com/atom/ns#' term='Bias'/><category scheme='http://www.blogger.com/atom/ns#' term='Creativity'/><title type='text'>Short Memory</title><content type='html'>"&lt;span style="font-style: italic;"&gt;You can’t improve a design when you’re emotionally attached to past decisions. Improvements come from flexibility and openness.&lt;/span&gt;"  A quote from the &lt;a href="http://37signals.com/" target="_blank"&gt;37signals&lt;/a&gt; blog.&lt;br /&gt;&lt;br /&gt;This brings me back to diverse thinking and confirmation bias.  The longer we work on a problem, the more focused we are.  The good part is that we tune out the unimportant and distractions, but the downside is that we are less open to a new insight which might lead to a better solution.&lt;br /&gt;&lt;br /&gt;How does one achieve a balance between focus and freshness?  One way is to have several projects going at once (who doesn't) but rather than flitting back-and-forth in a feeble attempt to multi-task, I think you should dedicate significant chunks of time and effort to one problem.  Then switch to another without re-visiting the first problem for some time.  When you return to the initial problem you can't help but have a fresh perspective.  You've also allowed for some incubation to occur.  The longer you've worked on a project, the harder it is to return with a fresh perspective.  That's where the challenge is.&lt;br /&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;The time spent devoted to one project is a factor you can play with.  If it is a project you're familiar with, you can stay away from it for some time.  For a new, unfamiliar project, don't stay away too long because you may end up spending too much time refreshing your memory.&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-5853651414527493793?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/5853651414527493793/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=5853651414527493793' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/5853651414527493793'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/5853651414527493793'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2010/11/short-memory.html' title='Short Memory'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-7522389543878242234</id><published>2010-11-01T12:37:00.000-07:00</published><updated>2010-11-03T11:37:17.106-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Organization'/><category scheme='http://www.blogger.com/atom/ns#' term='Process'/><category scheme='http://www.blogger.com/atom/ns#' term='Communication'/><title type='text'>Technical Report Writing</title><content type='html'>Communication is one of a problem solver's core competencies.  NASA has put together a guide for its staff on &lt;a href="http://grcpublishing.grc.nasa.gov/editing/vidoli.CFM" target="_blank"&gt;writing technical reports &lt;/a&gt;and it's out there for free on the internet.  While it can be of help in documenting your work, it is helpful in other ways.&lt;br /&gt;&lt;br /&gt;Chapter 1, &lt;span style="font-style: italic;"&gt;Stages of Report Preparation&lt;/span&gt;, could also be though of as a high-level overview of stages of problem solving.  &lt;span style="font-style: italic;"&gt;&lt;br /&gt;&lt;/span&gt;&lt;ol&gt;&lt;li&gt;&lt;span style="font-style: italic;"&gt;Gathering &lt;/span&gt;of data, &lt;/li&gt;&lt;li&gt;&lt;span style="font-style: italic;"&gt;analyzing &lt;/span&gt;to extract information,&lt;br /&gt;&lt;/li&gt;&lt;li&gt;&lt;span style="font-style: italic;"&gt;outlining &lt;/span&gt;to highlight missing information, &lt;/li&gt;&lt;li&gt;&lt;span style="font-style: italic;"&gt;writing &lt;/span&gt;to build knowledge, and &lt;/li&gt;&lt;li&gt;&lt;span style="font-style: italic;"&gt;revision &lt;/span&gt;to perfect communication and knowledge transfer &lt;/li&gt;&lt;/ol&gt;When faced with a problem.  Don't just jump in aimlessly, &lt;span style="font-style: italic;"&gt;gather &lt;/span&gt;your data, &lt;span style="font-style: italic;"&gt;analyze &lt;/span&gt;it to diagnose the problem better, &lt;span style="font-style: italic;"&gt;outline &lt;/span&gt;possible solutions.  &lt;span style="font-style: italic;"&gt;Write &lt;/span&gt;(or implement) a solution and finally, &lt;span style="font-style: italic;"&gt;revise &lt;/span&gt;the solution to perfect it and address any oversights or limitations.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-7522389543878242234?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/7522389543878242234/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=7522389543878242234' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/7522389543878242234'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/7522389543878242234'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2010/11/technical-report-writing.html' title='Technical Report Writing'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-8624884924507005923</id><published>2010-10-30T12:13:00.000-07:00</published><updated>2010-11-03T11:33:26.927-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Simplicity'/><category scheme='http://www.blogger.com/atom/ns#' term='Beauty'/><title type='text'>Beautiful Tools</title><content type='html'>&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://upload.wikimedia.org/wikipedia/commons/7/7b/Hammer2.jpg"&gt;&lt;img style="float: left; margin: 0pt 10px 10px 0pt; cursor: pointer; width: 282px; height: 246px;" src="http://upload.wikimedia.org/wikipedia/commons/7/7b/Hammer2.jpg" alt="" border="0" /&gt;&lt;/a&gt;&lt;br /&gt;An example of a beautiful solution. A hammer is simple yet can be used in a variety of situations (sometimes too many). It doesn't take a manual to understand how to use it.  It is beautiful because of its simplicity.  There's not much you can do to make it more effective. (Sure there are special hammers optimized for specific purposes, but that is a different kind of beauty). &lt;br /&gt;&lt;br /&gt;Probably every toolbox in the world has a hammer and if you don't, you've probably tried using other things in place of a hammer (your fist, a wrench, a rock) and found that they don't quite live up to the usefulness of the hammer.&lt;br /&gt;&lt;br /&gt;Just like Quality can be defined as fitness for use, Beauty (of a solution) is fitness for use.  A hammer fits it's purpose.  Nothing more, nothing less.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-8624884924507005923?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/8624884924507005923/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=8624884924507005923' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/8624884924507005923'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/8624884924507005923'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2010/10/example-of-beautiful-solution.html' title='Beautiful Tools'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-1388436656401470508</id><published>2010-10-29T18:42:00.000-07:00</published><updated>2010-10-30T12:00:58.622-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Simplicity'/><category scheme='http://www.blogger.com/atom/ns#' term='Beauty'/><category scheme='http://www.blogger.com/atom/ns#' term='Optimization'/><title type='text'>Beautiful Problem Solving</title><content type='html'>I have in interest in data visualization and there's a new book out there called &lt;a href="http://www.shelfari.com/books/14210260/Beautiful-visualization", target="_blank"&gt;Beautiful Visualization&lt;/a&gt;.  That got me to thinking about whether solutions to problems can be beautiful.&lt;br /&gt;&lt;br /&gt;They can, but what makes them beautiful?  There are characteristics the comprise the solutions whether they are a tool, a process, or a procedure.  Simplicity, flexibility, completeness, complexity.  What is of value depends on the situation and the user.&lt;br /&gt;&lt;br /&gt;&lt;a href="http://en.wikipedia.org/wiki/Shaker_furniture", target="_blank"&gt;Shaker furniture &lt;/a&gt;is famous for its simplicity and its functionality.  What makes it beautiful is that it is both simple &lt;span style="font-style:italic;"&gt;and &lt;/span&gt;functional.  Too simple and it would lose some of its functionality and would not be as beautiful.  Finding that balance is an art.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-1388436656401470508?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/1388436656401470508/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=1388436656401470508' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/1388436656401470508'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/1388436656401470508'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2010/10/beautiful-problem-solving.html' title='Beautiful Problem Solving'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-2073400263882101490</id><published>2010-10-26T17:26:00.000-07:00</published><updated>2010-10-28T19:04:45.755-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Creativity'/><category scheme='http://www.blogger.com/atom/ns#' term='Learning'/><category scheme='http://www.blogger.com/atom/ns#' term='Consumption'/><category scheme='http://www.blogger.com/atom/ns#' term='Communication'/><title type='text'>Creation, Consumption, and Communication</title><content type='html'>We engage in three basic types of activities: &lt;span style="font-weight:bold;"&gt;Creation &lt;/span&gt;of new ideas, &lt;span style="font-weight:bold;"&gt;consumption &lt;/span&gt;of existing ideas, and &lt;span style="font-weight:bold;"&gt;communication&lt;/span&gt;, either of existing ideas or our own new ideas.  Each of these has importance and there must be a balance among the three.  &lt;br /&gt;&lt;br /&gt;I've posted about &lt;a href="http://technicalproblemsolving.blogspot.com/2010/07/isolation-and-creativity.html", target = "_blank"&gt;Isolation and Creativity&lt;/a&gt; before and there's a new book (and free e-book) about the need to &lt;a href="http://zenhabits.net/focus-book/", target = "_blank"&gt;focus &lt;/a&gt;in order to be productive.  I've not worked my way through it (lack of focus I suppose) but it looks like the author will present various tools and techniques for eliminating distractions and the Data Smog that assaults us all the time.&lt;br /&gt;&lt;br /&gt;I've also posted about consumption (or learning).  One should spend time being exposed to new ideas, getting inspiration from others.  Consumption shouldn't just be of the things we like or that agree with our mind-set but should expand our ideas.  Not that we blindly accept everything that comes our way, but that we are able to see things from another perspective.  Nothing is more dangerous than someone who is certain they are correct.  Doesn't matter where.  As Nassim Taleb points out in the &lt;a href="http://en.wikipedia.org/wiki/Black_swan_theory", target="_blank"&gt;Black Swan&lt;/a&gt;, Experts are people who don't know what they don't know.&lt;br /&gt;&lt;br /&gt;And finally communication.  Check the tag cloud for posts about that topic.&lt;br /&gt;&lt;br /&gt;There must be a balance of all three.  We will be strong in one of these areas.  You must cultivate your skills in the other areas.  While being able to switch from one to another is important, don't get into the situation which the author of Focus describes where you flutter from one to another so quickly that you cannot build up any momentum.  &lt;br /&gt;&lt;br /&gt;These three areas are a stool that your problem solving skills sit upon.  Make sure each leg is strong and capable of supporting the weight of the problems you must address.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-2073400263882101490?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/2073400263882101490/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=2073400263882101490' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2073400263882101490'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2073400263882101490'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2010/10/creation-consumption-and-communication.html' title='Creation, Consumption, and Communication'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-5266896011172783871</id><published>2010-07-31T13:13:00.001-07:00</published><updated>2010-07-31T13:34:50.665-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Communication'/><title type='text'>Unscientific America - Thoughts about communication</title><content type='html'>In their book, &lt;a href="http://lccn.loc.gov/2009015482", target="_blank"&gt;Unscientific America: How scientific illiteracy threatens our future&lt;/a&gt;, Chris Mooney and Sheril Kirshenbaum make the point that it is not so much that Americans are not knowledgeable about science but that there is a lack of communication between scientists and the general public. The book examines many of the reasons for this but in reading the book, it brought to mind the "Curse of Knowledge" from &lt;a href="http://technicalproblemsolving.blogspot.com/2009/09/getting-your-solution-to-stick.html"&gt;Made to Stick&lt;/a&gt;.  &lt;br /&gt;&lt;br /&gt;As scientists and engineers, we address all sides of a problem, considering the advantages and disadvantages and weighing their relative merits.  This is vital, but once a decision has been made, one should consider simplifying things in order to more effectively communicate. To what extent one simplifies depends on the audience.  In Chapter 5, Mooney and Kirshenbaum write about Preston Manning who distinguishes between "source-oriented communicators" and "&lt;a href="http://www.interactions.org/pdf/SLAC_pavan_manning.pdf", target="_blank"&gt;receiver-oriented communicators&lt;/a&gt;". Don't communicate from your perspective but "think about the audience and how to reach it". Are you talking to other engineers, to engineering managers, to business leaders, to the general public?  Each of these audiences will need a different presentation tailored to their perspective.&lt;br /&gt;&lt;br /&gt;There is a difference between transmitting information and communication information.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-5266896011172783871?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/5266896011172783871/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=5266896011172783871' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/5266896011172783871'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/5266896011172783871'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2010/07/unscientific-america-thoughts-about.html' title='Unscientific America - Thoughts about communication'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-6868660387569976584</id><published>2010-07-24T19:44:00.000-07:00</published><updated>2010-07-24T19:57:47.284-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Creativity'/><category scheme='http://www.blogger.com/atom/ns#' term='Imagination'/><title type='text'>Isolation and Creativity</title><content type='html'>I've also come across a blog posting about the &lt;a href="http://www.getfinch.com/finch/entry/the_creativity_trigger/", target="_blank"&gt;Creativity Trigger&lt;/a&gt;.  I might be misinterpreting it a bit, but one of the things the author mentions is being overloaded by information such that one doesn't have original thoughts but merely reforms what someone else has already done.  Well he's a designer, and originality has more value in that area that for a scientist or engineer, but I think we can learn from him.  While it is important to be &lt;a href="http://technicalproblemsolving.blogspot.com/2010/07/networks-hubs-and-problem-solving.html"&gt;linked&lt;/a&gt;, and exposed to many &lt;a href="http://technicalproblemsolving.blogspot.com/2009/09/active-exploration.html"&gt;sources of information&lt;/a&gt;, you should also balance this with times of isolation.  This can bring new solutions, approaches, and strategies towards our problems.  &lt;br /&gt;&lt;br /&gt;Like everything in life, we need to strike a balance in how we go about solving problems.  You can't be everything at all times, so take the time to make a conscious shift in your approach from time to time.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-6868660387569976584?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/6868660387569976584/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=6868660387569976584' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/6868660387569976584'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/6868660387569976584'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2010/07/isolation-and-creativity.html' title='Isolation and Creativity'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-7318013737038031486</id><published>2010-07-24T19:24:00.000-07:00</published><updated>2010-07-24T19:57:30.171-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Network'/><category scheme='http://www.blogger.com/atom/ns#' term='Diversity'/><title type='text'>Networks, Hubs, and Problem Solving</title><content type='html'>I recently finished reading &lt;a href="http://lccn.loc.gov/2003282237" target="_blank"&gt;Linked: How Everything is Connected to Everything Else and What it Means.&lt;/a&gt;  In this overview of networks and the many places they appear in the world, the author mentions that there are hubs that connect different areas of the network to each other and they are key in getting information across the network.  You may have heard of the &lt;a href="http://en.wikipedia.org/wiki/Six_Degrees_of_Kevin_Bacon", target = "_blank"&gt;six degrees of Kevin Bacon&lt;/a&gt; which is a game people play to relate any actor to Kevin Bacon based on movies they have acted in in common.  The reason this game works is because there are actors who have acted in many movies alongside many other actors. Because of these actors who are 'hubs', actors who seem to have nothing in common are linked to each other.&lt;br /&gt;&lt;br /&gt;That brought to mind problem solving.  If you are an expert in one area, but have no connections to other disciplines, your impact will be in a relatively small area.  You only interact with others with a similar background and your problem solving will have depth but not breadth.  Your network is isolated, or you rely on someone else to be the hub to network your skills and knowledge to other areas.&lt;br /&gt;&lt;br /&gt;Try to foster links in other disciplines, that way &lt;span style="font-style:italic;"&gt;you &lt;/span&gt;will be a hub that will transfer solutions to many areas, just the way a major actor links many actors together.  Likewise, engage those from other areas since they may be working on things that are solutions to the problems you have.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-7318013737038031486?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/7318013737038031486/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=7318013737038031486' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/7318013737038031486'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/7318013737038031486'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2010/07/networks-hubs-and-problem-solving.html' title='Networks, Hubs, and Problem Solving'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-5178514434918620600</id><published>2010-07-07T18:18:00.000-07:00</published><updated>2010-07-07T18:30:02.171-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Creativity'/><category scheme='http://www.blogger.com/atom/ns#' term='Database'/><category scheme='http://www.blogger.com/atom/ns#' term='Organization'/><title type='text'>Organization and Creativity</title><content type='html'>One doesn't think of a methodical, organized person as creative. There's no eureka moment, frenzy of activity, or sudden change to point to.  However, part of being creative is being prepared.  Musicians practice long hours on very basic skills in order to have the ability to demonstrate artistry with ease.  You can't play a concerto without having mastered tone and articulation.  Despite what one might think, making music doesn't come naturally.&lt;br /&gt;&lt;br /&gt;Problem solvers should build up a database (some might call it a repertoire) of information, techniques, and connections.  You never know what might be of importance in addressing a problem you encounter.  If you haven't toyed around with something, you won't know it's capabilities when faced with a problem.  I've posted on this topic before, perhaps more specifically.  Take time to learn new skills, play around with things, and build up a database of information in order to be prepared for your next eureka moment.&lt;br /&gt;&lt;br /&gt;Here's Joan Rivers sharing about her creativity.&lt;br /&gt;&lt;object width="660" height="405"&gt;&lt;param name="movie" value="http://www.youtube.com/v/87yztkvEsIk&amp;amp;hl=en_US&amp;amp;fs=1?rel=0&amp;amp;border=1"&gt;&lt;/param&gt;&lt;param name="allowFullScreen" value="true"&gt;&lt;/param&gt;&lt;param name="allowscriptaccess" value="always"&gt;&lt;/param&gt;&lt;embed src="http://www.youtube.com/v/87yztkvEsIk&amp;amp;hl=en_US&amp;amp;fs=1?rel=0&amp;amp;border=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="660" height="405"&gt;&lt;/embed&gt;&lt;/object&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-5178514434918620600?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/5178514434918620600/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=5178514434918620600' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/5178514434918620600'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/5178514434918620600'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2010/07/organization-and-creativity.html' title='Organization and Creativity'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-3281857192151075335</id><published>2010-06-24T19:22:00.000-07:00</published><updated>2010-06-24T19:29:44.943-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Learning'/><category scheme='http://www.blogger.com/atom/ns#' term='Failure'/><title type='text'>More about Failure</title><content type='html'>We like to celebrate our successes.  We have graduation parties, celebrate the completion of projects, a big sale, etc.  It's easy.&lt;br /&gt;&lt;br /&gt;How do you deal with your failures?  Do you try to forget about them, sweeping them under the rug?  Maybe you're embarrassed about the failure or have been punished for the failure.&lt;br /&gt;&lt;br /&gt;I think it's important (perhaps after some time has passed) to review your failures to see what might have gone wrong. Is there something specific you can avoid in the future?  Is there a pattern emerging where similar situations end up the same?  Recognizing patterns is what we as humans are good at, but we need to be looking for them.  Burying your head in the sand and hoping to forget about a bad experience increase the chances that you'll end up in a similar situation again.&lt;br /&gt;&lt;br /&gt;Also, leaders shouldn't punish people for failures (other than perhaps ethical failures - and certainly criminal failures).  It will make them afraid to take risks, try something new, or be creative.  How can you expect creative solutions to difficult problems if the consequences of failure are too great.  &lt;br /&gt;&lt;br /&gt;Mistakes can be golden if you learn from them.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-3281857192151075335?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/3281857192151075335/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=3281857192151075335' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/3281857192151075335'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/3281857192151075335'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2010/06/more-about-failure.html' title='More about Failure'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-8568258859508383132</id><published>2010-06-01T12:32:00.000-07:00</published><updated>2010-06-01T12:39:07.806-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Bias'/><category scheme='http://www.blogger.com/atom/ns#' term='Creativity'/><title type='text'>Overcoming Mental Blocks</title><content type='html'>A quote from the &lt;a href="http://37signals.com/svn/posts/2369-sometimes-a-design-isnt-working-because" target="blank"&gt;signal vs noise &lt;/a&gt; blog. "Sometimes a design isn’t working because you think you can’t change the one element that needs to be changed"&lt;br /&gt;&lt;br /&gt;The same goes for problem solutions. Maybe you're not finding an effective solution because you are locked in on something as being essential when it isn't.  Take a step back, attack the problem with a beginner's mind and maybe another solution will present itself. &lt;br /&gt;&lt;br /&gt;I was once faced with an analysis problem in which I couldn't avoid the compound I was trying to analyze decompose in the equipment. After many iterations of trying to find a way to avoid decomposition, I finally realized that if I deliberately decomposed the compound in a known manner, the solution was easy.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-8568258859508383132?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/8568258859508383132/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=8568258859508383132' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/8568258859508383132'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/8568258859508383132'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2010/06/overcoming-mental-blocks.html' title='Overcoming Mental Blocks'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-6322106983026492037</id><published>2010-05-22T19:13:00.000-07:00</published><updated>2010-05-22T19:19:03.729-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Improvement'/><category scheme='http://www.blogger.com/atom/ns#' term='Iteration'/><category scheme='http://www.blogger.com/atom/ns#' term='Measurement'/><title type='text'>The importance of measurement.</title><content type='html'>I was in recent discussion about quality and a couple of good points were made.&lt;br /&gt;&lt;ul&gt;&lt;li&gt;You cannot improve what you do not measure.&lt;/li&gt;&lt;li&gt;You cannot manage what you do not measure.&lt;/li&gt;&lt;/ul&gt;Measurement helps to visualize problems and gives us perspective.  Whenever you implement a solution, be sure to include measurements so you can evaluate whether the solution is truly effective.  Ideally it is a measurement you were doing before you implemented the solution so you can quantify the improvement, but at the very least, include some measurements so that future improvements can be quantified.  Sometimes it will take a couple of attempts to arrive at the optimum solution.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-6322106983026492037?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/6322106983026492037/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=6322106983026492037' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/6322106983026492037'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/6322106983026492037'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2010/05/importance-of-measurement.html' title='The importance of measurement.'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-1876805759672001006</id><published>2010-05-10T12:31:00.000-07:00</published><updated>2010-05-10T12:37:24.377-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Bias'/><category scheme='http://www.blogger.com/atom/ns#' term='Root Cause'/><title type='text'>Lazy Thinking</title><content type='html'>Prejudice in problem solving is caused by lazy thinking.  When we are pre-disposed to a particular solution, we need to be careful to avoid simply assuming the previous solution is the correct one this time also.  This is related to the "beginner's mind". &lt;br /&gt;&lt;br /&gt;How do you strike a balance between re-creating the wheel every time a problem comes up and re-applying the same solution?  It has to do with lazy thinking.   If you carefully consider a problem instead of jumping to conclusions, it doesn't cost much in terms of effort and will help avoid overlooking potential new solutions or new wrinkles to an old problem.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-1876805759672001006?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/1876805759672001006/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=1876805759672001006' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/1876805759672001006'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/1876805759672001006'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2010/05/lazy-thinking.html' title='Lazy Thinking'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-9105898242219452669</id><published>2010-04-28T12:34:00.001-07:00</published><updated>2010-04-28T13:07:55.414-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Communication'/><title type='text'>Chartjunk or Communication?</title><content type='html'>EagerEyes recently &lt;a href="http://eagereyes.org/criticism/chart-junk-considered-useful-after-all"&gt;posted &lt;/a&gt;about a study investigation the memorability of graphics and data. That brings to mind my earlier thoughts about communication. You may have the best data in the world but if it's not communicated well, then you've missed the target. I suppose which path you take depends on your audience.&lt;br /&gt;&lt;br /&gt;When you're presenting to an audience of a similar backround or perhaps more knowledgeable about that data than yourself, minimize chartjunk and seek to present the data in as unbiased a manner as possible.&lt;br /&gt;&lt;br /&gt;When you're the expert and are seeking to communicate the results of your interpretation, resist the "curse of knowledge" and incorporate some of the suggestions from &lt;a href="http://lccn.loc.gov/2006046467" target="_blank"&gt;Made to Stick &lt;/a&gt;to increase the memorability of the results and analysis. A perfect data presentation following Tufte's guidance may not be the optimal solution.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-9105898242219452669?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/9105898242219452669/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=9105898242219452669' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/9105898242219452669'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/9105898242219452669'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2010/04/chartjunk-or-communication.html' title='Chartjunk or Communication?'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-3719363237137280633</id><published>2010-04-11T19:26:00.000-07:00</published><updated>2010-04-11T19:38:09.927-07:00</updated><title type='text'>Expanding your Skills</title><content type='html'>I haven't posted much this year.  My excuse is that I've been spending time learning PHP and Python programming.  In the case of PHP It seems I don't have an immediate need for that knowledge but since it is commonly used to control many websites it seemed prudent to at least get a basic knowledge of that language.&lt;br /&gt;&lt;br /&gt;A knowledge of &lt;a href="http://www.python.org", target = "_blank"&gt;Python&lt;/a&gt; has been more useful.  I expect that Python aficionados will give many reasons to use that language, but I've found it useful for processing text files generated by our lab equipment to create summaries so they can be processed by our software to input data in a LIMS. &lt;br /&gt;&lt;br /&gt;Don't be stagnant in your skills but continue to explore new areas.  Some may not be immediately useful (like PHP in my case) and others will be.  However, without exploring something new, you'll never be open to the possibilities that the new skill may present. Don't get stuck being happy with the status quo because you don't know what else is possible because your skills remain focused in a narrow area.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-3719363237137280633?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/3719363237137280633/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=3719363237137280633' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/3719363237137280633'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/3719363237137280633'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2010/04/expanding-your-skills.html' title='Expanding your Skills'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-1605093291569279319</id><published>2010-02-06T17:44:00.000-08:00</published><updated>2010-02-06T18:41:50.814-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Creativity'/><category scheme='http://www.blogger.com/atom/ns#' term='Imagination'/><title type='text'>Imagination</title><content type='html'>I haven't posted in some time.  It's probably a lack of imagination.&lt;br /&gt;&lt;br /&gt;Why is it that some people are content to do the same job, the same way over and over.  I don't think it's that they're lazy.  In most cases what they are doing is labor intensive.  They might be very proficient and fast at what they do.&lt;br /&gt;&lt;br /&gt;I think it's a lack of imagination. They can't imagine doing it a different way. Not automated, not faster, not different.  Just doing it.&lt;br /&gt;&lt;br /&gt;I follow a couple of blogs on Excel. The posts are mostly about customizing and automating so one can do things faster, and exactly the way you want them to be instead of relying on what the programmers envisioned. The desire to do things differently requires imagination about the way you want things to be.&lt;br /&gt;&lt;br /&gt;Work on your imagination and who knows where it will lead.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-1605093291569279319?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/1605093291569279319/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=1605093291569279319' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/1605093291569279319'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/1605093291569279319'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2010/02/imagination.html' title='Imagination'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-8300478951723072878</id><published>2009-12-11T08:52:00.001-08:00</published><updated>2009-12-27T18:09:26.227-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Learning'/><category scheme='http://www.blogger.com/atom/ns#' term='Failure'/><title type='text'>Fail=Success</title><content type='html'>Sorry for re-posting but not only does &lt;a href="http://lifehacker.com/5423552/the-key-to-success-do-stuff?utm_source=feedburner&amp;amp;utm_medium=feed&amp;amp;utm_campaign=Feed%3A+lifehacker%2Ffull+%28Lifehacker%29&amp;amp;utm_content=Google+Reader", target="_blank"&gt;this post&lt;/a&gt; have good advice but I've recently come across the &lt;a href="http://lifehacker.com/"target="_blank"&gt;Lifehacker &lt;/a&gt;website.  If you use computers (and what scientist or engineer doesn't), Lifehacker has many great tips, links to make your computing life easier.  They are scouring the web so you don't have to.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-8300478951723072878?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/8300478951723072878/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=8300478951723072878' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/8300478951723072878'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/8300478951723072878'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/12/failsuccess.html' title='Fail=Success'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-2164612628122608946</id><published>2009-11-27T09:43:00.000-08:00</published><updated>2009-11-27T09:57:44.043-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Database'/><title type='text'>Databases</title><content type='html'>Some of my earlier posts have had to do with information (or data) visualization.  Before you can visualize data, it must be readily available.  In today's age of computers, your data is certainly electronic but if it is spread across multiple servers, directories, and files it is unmanageable and not available.  This is where relational databases come in. &lt;br /&gt;&lt;br /&gt;If your data is in a well-designed relational database, you can access it in a variety of ways.  Most data analysis software (e.g. Excel, MiniTab, Origin, Quality Analyst are a few that I've used) has wizards that make it easy to develop SQL queries to retrieve data.  With a minimal knowledge of SQL you can modify the wizard queries to make them even more powerful.  The &lt;span style="font-style: italic;"&gt;important &lt;/span&gt;part is to have your data in a database to begin with.  While a LIMS or another database may seem like an expensive investment, it will pay off in the long run by giving you many opportunities to examine your data and find answers to your problems in data you have already gathered rather than having to design new experiments. &lt;br /&gt;&lt;br /&gt;In today's age of tight budgets, many companies want concrete justification for purchase and use of a database.  The problem is that a database will help you solve problems that you haven't even imagined yet and so it is hard to provide evidence of the "hard" savings that a database will provide.&lt;br /&gt;&lt;br /&gt;Anybody with an eye towards the future (not just the next 3 months) should have a relational database for storing their data and begin inserting data immediately.  Without data in your database, it will be useless.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-2164612628122608946?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/2164612628122608946/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=2164612628122608946' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2164612628122608946'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2164612628122608946'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/11/databases.html' title='Databases'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-221815400385776922</id><published>2009-09-28T18:05:00.000-07:00</published><updated>2009-09-28T18:11:56.905-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Data Smog'/><category scheme='http://www.blogger.com/atom/ns#' term='Visualization'/><title type='text'>Know your data</title><content type='html'>Often we gather data to aid in solving a problem we encounter.  One trap that you can fall into is that the data is not exactly what you think it is.  For example, you might be taking pressure readings from a process line to decide whether a filter is plugged.  The pressure readings may be normal leading you to believe that the filter is not plugged and in satisfactory condition.  However, if the pressure gauge is upstream of the filter, then the data is misleading you.  The filter may be plugged but the pressure gauge location is misleading you.   &lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;This is particularly a problem if you don't have good change control on your equipment.  The diagram you are working on may not reflect reality.  It is always a good idea to go look at what you're working on, both the help you visualize the process and to make sure things are as you think they are.  The biggest danger to problem solving is thinking you can sit back in your office and just think through the problem. &lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-221815400385776922?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/221815400385776922/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=221815400385776922' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/221815400385776922'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/221815400385776922'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/09/know-your-data.html' title='Know your data'/><author><name>Tech Problem Solver</name><uri>http://www.blogger.com/profile/00082055607681100379</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-6694728619050432523</id><published>2009-09-06T11:44:00.000-07:00</published><updated>2009-09-06T12:02:13.014-07:00</updated><title type='text'>Active Exploration</title><content type='html'>When I was in school I was listening to a talk about a topic (or so I thought) unrelated to my research.   The speaker mentioned in passing that they were adding hydrogen to the helium microwave plasma.  That caught my attention as I realized that it may be suitable for the problems I was having getting my project on RF ICPs to work.  With a little bit of literature searching I was able to find much work from the light bulb industry that addressed the problem that I was having.  Imagine my surprise that my "research" problem had already been encountered (in a somewhat different form) in another industry.&lt;br /&gt;&lt;br /&gt;You should always be aware of potential solutions to problems you might encounter in unexpected places.  In "Made to Stick" the authors talk about the power of spotting a good story that supports what you want to communicate.  Unless you are actively looking for such an story, you may miss it when you come across it.  Likewise problem solutions may elude you unless you have the problem(s) in mind and you are actively looking for solutions. &lt;br /&gt;&lt;br /&gt;Don't neglect this &lt;a href="http://technicalproblemsolving.blogspot.com/2008/10/essential-ingredients-of-problem.html"&gt;key ingredient of problem solving&lt;/a&gt;.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-6694728619050432523?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/6694728619050432523/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=6694728619050432523' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/6694728619050432523'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/6694728619050432523'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/09/active-exploration.html' title='Active Exploration'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-1959275343534083814</id><published>2009-09-06T11:22:00.000-07:00</published><updated>2009-09-06T11:41:43.989-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Communication'/><title type='text'>Getting your solution to Stick</title><content type='html'>In their book "&lt;a href="http://lccn.loc.gov/2006046467" target="_blank"&gt;Made to Stick&lt;/a&gt;" Chip and Dan Heath make the following statement (slightly edited) in the Epilogue.&lt;br /&gt;&lt;br /&gt;"[Problem solving] has two stages: the Answer stage and the Telling Others stage.  In the Answer stage, you use your expertise to arrive at the [solution] you want to share. [...]&lt;br /&gt;Here's the rub:  The same factors that worked to your advantage in the Answer stage will backfire on you during the Telling Others stage"&lt;br /&gt;&lt;br /&gt;After solving a problem, we know a lot about it.  The problem is, the people who we are communicating the solution to, don't know nearly as much.  This is where the "Curse of Knowledge" comes in.  What we already know, we have to get across to others.  The problem is that what we think is important may not matter unless you can get others to buy in to your solution.  The book provides the recipe for SUCCESs. &lt;br /&gt;&lt;br /&gt;www.madetostick.com is their website.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-1959275343534083814?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/1959275343534083814/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=1959275343534083814' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/1959275343534083814'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/1959275343534083814'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/09/getting-your-solution-to-stick.html' title='Getting your solution to Stick'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-5250019705433798409</id><published>2009-08-31T18:01:00.000-07:00</published><updated>2009-08-31T18:20:30.393-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Learning'/><category scheme='http://www.blogger.com/atom/ns#' term='multi-tasking'/><category scheme='http://www.blogger.com/atom/ns#' term='Communication'/><title type='text'>Multi-tasking, Learning and Phone Conferences</title><content type='html'>My company is getting more distributed.  Workers on a project (problem) located at opposite ends of the country and even overseas.  For that reason, we are having increasingly frequent phone conferences.  They're great for touching base frequently without having to hop on a plane but I have some doubts about how effective these meetings really are.&lt;br /&gt;&lt;br /&gt;My earlier post about multi-tasking cites evidence that multi-tasking is a misnomer and yet these phone conferences are a invitation to do so.  One ear on the phone, sending an e-mail and perhaps even in IM or working on a document is probably pretty standard behavior for participants in a phone conference.  Frequently someone is asked a question and their response is "Pardon, please repeat the question."  Their attention was elsewhere.&lt;br /&gt;&lt;br /&gt;In the chapter 9 of his book &lt;a href="http://www.brainrules.net/" target="_blank"&gt;Brain Rules&lt;/a&gt;, John Medina reviews studies which show that optimal learning is when multiple senses are involved .  In phone conferences, we only have one of our senses involved.  When you're in a meeting, you're learning, unless of course you are doing all the talking.  You're learning what others know, what you have to work on, what they're working on. &lt;br /&gt;&lt;br /&gt;The phone conference is a less than ideal learning situation.  I wonder if there are any studies on the efficiency of face-to-face meetings versus phone only and phone and visuals.  I wonder where the break-even point is for the travel costs versus the wasted time in the meetings.&lt;br /&gt;&lt;br /&gt;Some suggestions for your next phone conference.&lt;br /&gt;&lt;ul&gt;&lt;li&gt;Send an agenda out beforehand so everyone is prepared to &lt;span style="font-style: italic;"&gt;learn &lt;/span&gt;about the topics.&lt;/li&gt;&lt;li&gt;Use some sort of desktop sharing program so everyone is seeing the same information.&lt;/li&gt;&lt;li&gt;Send out minutes along with any visuals after the meeting is over so everyone can review the outcomes. (Another chance to learn what was discussed).&lt;br /&gt;&lt;/li&gt;&lt;li&gt;If you're a participant.  Pay attention.  It may seem like you're more productive when sending IMs, EMs, but every time you ask for something to be repeated you're wasting x number of other people's time.&lt;/li&gt;&lt;/ul&gt;Modern technology has made many things more efficient, but our brains are still "primitive".  We learn best by incorporating multiple senses and reviewing the information multiple times.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-5250019705433798409?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/5250019705433798409/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=5250019705433798409' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/5250019705433798409'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/5250019705433798409'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/08/multi-tasking-learning-and-phone.html' title='Multi-tasking, Learning and Phone Conferences'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-6097515607153803698</id><published>2009-08-28T18:37:00.001-07:00</published><updated>2009-08-28T18:55:03.715-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Improvement'/><category scheme='http://www.blogger.com/atom/ns#' term='Iteration'/><category scheme='http://www.blogger.com/atom/ns#' term='Optimization'/><title type='text'>Being Good Enough</title><content type='html'>This month, Wired magazine has an &lt;a href="http://www.wired.com/gadgets/miscellaneous/magazine/17-09/ff_goodenough", target = "_blank"&gt;article &lt;/a&gt;about products that are good enough to do the job but not great. The point of the article is that this is how these products can creep up on the leaders in the field until eventually the are capable of surpassing them. &lt;br /&gt;&lt;br /&gt;The same applies to problem solutions.  Often we are perfectionists, trying to anticipate every possible angle before implementing the solution.  Sometimes this can delay implementation of a solution and result in lost opportunities. Often (except when safety is involved) getting a partial solution in place quickly is more important than addressing all the issues beforehand.  You can then evaluate what the weaknesses are under operation and utilize an iterative process to optimize the system. Your supporting structures (management of change, document creation, document control, etc.) need to be efficient enough so that they aren't a drag on the process.&lt;br /&gt;&lt;br /&gt;If your support functions are more taxing to complete than the solution itself then something is wrong. Often Quality organizations become enamored with lots of checks and balances and the whole process gets bogged down. Often these people aren't users of the process but only enforcers. If you start thinking to yourself that you know how to do something but don't want to cut through all the red tape to get it implemented, then something is seriously wrong.  Both because good ideas may not get implemented and because people are tempted to take shortcuts without submitting the ideas to the proper review process. This can lead to unintended consequences.&lt;br /&gt;&lt;br /&gt;Even our best laid plans can go awry.  One needs to balance the desire for a "right the first time" solution with the inevitable refining process that occurs anytime you try something new. Continuous improvement works best when it is continuous.  If it proceeds in fits and starts, then often it won't re-start.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-6097515607153803698?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/6097515607153803698/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=6097515607153803698' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/6097515607153803698'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/6097515607153803698'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/08/being-good-enough.html' title='Being Good Enough'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-1001435243793899616</id><published>2009-08-24T17:25:00.000-07:00</published><updated>2009-08-24T17:34:05.732-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Distraction'/><category scheme='http://www.blogger.com/atom/ns#' term='multi-tasking'/><category scheme='http://www.blogger.com/atom/ns#' term='Communication'/><title type='text'>Distractions</title><content type='html'>Over time, the communications and information streams that we are exposed to have gotten more and more complex.  This interferes with problem solving.  &lt;a href="http://www.pnas.org/content/early/2009/08/21/0903620106.abstract"target = _blank&gt;Here &lt;/a&gt;is some recent research by a group at Stanford which demonstrates that multi-taskers are actually less capable multi-taskers than those who don't multi-task.&lt;br /&gt;&lt;br /&gt;I've read about people who have figured out through data visualization techniques when most of their e-mails arrive.  They then set aside a few times each day when the address e-mails.  I only get 10s of e-mails a day.  I can't imagine someone who may receive hundreds.  They must develop an efficient system to wade through this smog.&lt;br /&gt;&lt;br /&gt;If you cannot focus on the problem seriously, you will have trouble finding effective solutions.  While there may be a time to get exposed to new ideas, and stimulate your creative problem solving, it is not in the midst of a problem.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-1001435243793899616?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/1001435243793899616/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=1001435243793899616' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/1001435243793899616'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/1001435243793899616'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/08/distractions.html' title='Distractions'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-3462066055562937614</id><published>2009-08-10T18:38:00.001-07:00</published><updated>2009-08-10T18:52:31.067-07:00</updated><title type='text'>Thinking Strategies</title><content type='html'>Garr Reynolds posted a presentation on &lt;a href="http://www.slideshare.net/garr/think-like-designer-1835628"target="_blank"&gt; Thinking like a Designer&lt;/a&gt;.  His rules apply to problem solvers also.  We must always work within constraints but need to balance this with the beginner's mind.  Our solutions should be as simple as possible while still being innovative. We need to be able to communicate our ideas effectively, etc. &lt;br /&gt;&lt;br /&gt;Check out his blog for many ideas about effective communication.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-3462066055562937614?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/3462066055562937614/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=3462066055562937614' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/3462066055562937614'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/3462066055562937614'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/08/think-like-designer-with-notes-view.html' title='Thinking Strategies'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-2796615876761004671</id><published>2009-08-10T16:54:00.000-07:00</published><updated>2009-08-10T17:05:32.432-07:00</updated><title type='text'>Measuring Perceptions of Uncertainty</title><content type='html'>I found the reference I mentioned in my previous post.  It is Figure 18 in Chapter 12 of &lt;a href="https://www.cia.gov/library/center-for-the-study-of-intelligence/csi-publications/books-and-monographs/psychology-of-intelligence-analysis/PsychofIntelNew.pdf"target="_blank"&gt;Psychology of Intelligence Analysis &lt;/a&gt; &lt;br /&gt;&lt;br /&gt;The table shows the probability assigned by various reader to statements containing verbal expressions of uncertainty.  For some terms, such as &lt;em&gt;'highly likely' &lt;/em&gt;or &lt;em&gt;'probably'&lt;/em&gt; the probability assigned by various users spanned a range as high as 50%.  Clearly using verbal descriptions of probability is probably :-) a bad a idea!&lt;br /&gt;&lt;br /&gt;Nicolas Bissantz beat me to this topic by at least 1 week in his posting.  &lt;a href="http://blog.bissantz.com/attribution" target="_blank"&gt;Speechless not numberless&lt;/a&gt;  He gives examples from the financial and medical area.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-2796615876761004671?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/2796615876761004671/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=2796615876761004671' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2796615876761004671'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2796615876761004671'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/08/measuring-perceptions-of-uncertainty.html' title='Measuring Perceptions of Uncertainty'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-4988313078151656191</id><published>2009-08-03T21:01:00.000-07:00</published><updated>2009-08-03T21:20:52.178-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Uncertainty'/><category scheme='http://www.blogger.com/atom/ns#' term='Communication'/><category scheme='http://www.blogger.com/atom/ns#' term='Measurement'/><title type='text'>Quantifying Uncertainty</title><content type='html'>Scientists and engineers are familiar with quantifying uncertainty in situations where we have data and measurements available.  If we know the measurement standard deviation and the number of measurements we made, we can calculate a confidence interval in which the true answer lies.&lt;br /&gt;&lt;br /&gt;Things are more complicated when we are asked to make a judgment call.  For example, what if you are asked when you will get a report finished.  You might answer, "probably tomorrow".  The problem with this is that "probably" can mean something quite different to different people.  "Probably" to you might mean "maybe" to another.  Some will use the word "unlikely" instead of "might" or "might not".&lt;br /&gt;&lt;br /&gt;Although it will seem uncomfortable, try to put some sort of odds on your judgment calls.  If you answer, "there's a 90% chance I'll be finished tomorrow" it's a lot less ambiguous than "I'll &lt;span style="font-style:italic;"&gt;probably&lt;/span&gt; be finished tomorrow".  Even though the odds might only be 70% or 80%, they're certainly not 20% or even 50%.  Attempting to apply some sort of numerical as opposed to verbal uncertainty will make your communication clearer.&lt;br /&gt;&lt;br /&gt;Somewhere I've come across a study of what various verbal uncertainty terms meant to different people.  I'll try to find it again and post it here.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-4988313078151656191?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/4988313078151656191/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=4988313078151656191' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/4988313078151656191'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/4988313078151656191'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/08/quantifying-uncertainty.html' title='Quantifying Uncertainty'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-236748658927787012</id><published>2009-07-26T11:18:00.000-07:00</published><updated>2009-07-26T11:28:27.919-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Visualization'/><category scheme='http://www.blogger.com/atom/ns#' term='Communication'/><title type='text'>Creating Meaning Visually</title><content type='html'>I've posted before on the importance of visualization in problem solving.  &lt;a href="http://www.ted.com/talks/tom_wujec_on_3_ways_the_brain_creates_meaning.html" target="_blank"&gt;  Here Tom Wujec&lt;/a&gt; tells us how the way the brain creates meaning from images.  More evidence on the importance of visualization in getting a handle on larger problems.  A good visualization is critical when presenting your ideas to a group or when working together in a group where different people have different ways of thinking about a problem.  Visualization techniques (like mapping or modeling) can help to get everyone aligned.&lt;br /&gt;&lt;br /&gt;&lt;span style="font-style:italic;"&gt;By the way, this TED site is a great place to stimulate your imagination by seeing presentations by excellent speakers on a variety of topics.&lt;/span&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-236748658927787012?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/236748658927787012/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=236748658927787012' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/236748658927787012'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/236748658927787012'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/07/creating-meaning-visually.html' title='Creating Meaning Visually'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-2204593267953670698</id><published>2009-06-17T13:36:00.000-07:00</published><updated>2009-06-17T14:02:00.733-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Randomness'/><category scheme='http://www.blogger.com/atom/ns#' term='Bias'/><category scheme='http://www.blogger.com/atom/ns#' term='Root Cause'/><title type='text'>Causal Bias</title><content type='html'>&lt;a href="http://4.bp.blogspot.com/_lrj7S5AfIac/SjlWsYvLHyI/AAAAAAAAAAU/Wq89k6vyw10/s1600-h/RootCauseExample2.png"&gt;&lt;img id="BLOGGER_PHOTO_ID_5348401353033719586" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 400px; CURSOR: hand; HEIGHT: 172px" alt="" src="http://4.bp.blogspot.com/_lrj7S5AfIac/SjlWsYvLHyI/AAAAAAAAAAU/Wq89k6vyw10/s400/RootCauseExample2.png" border="0" /&gt;&lt;/a&gt;&lt;br /&gt;&lt;div&gt;&lt;a href="http://2.bp.blogspot.com/_lrj7S5AfIac/SjlWke05tAI/AAAAAAAAAAM/K_M1rfILdzM/s1600-h/RootCauseExample2.png"&gt;&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;&lt;div&gt;As humans we naturally look for a cause for every event even if none exists. A gambler will attribute a winning streak to "being hot" or "beginners luck" when in reality randomness alone prevails.&lt;/div&gt;&lt;br /&gt;&lt;br /&gt;&lt;div&gt;&lt;/div&gt;&lt;br /&gt;&lt;div&gt;You should be aware of this tendency in problem solving also. We naturally want to find a concrete reason for every event. Take the rudimentary root cause analysis here. Our first instinct is to look for the cause of a rupture disk failure as an overpressure in the reactor. After all, isn't that what the rupture disk is there for? This can quickly lead down the path of investigating the reaction conditions and potentially getting involved in a costly solution.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;Another explanation is just that the disk failed randomly. (Insert Link to Drunkard's Walk) Perhaps it was installed incorrectly? The installation can be considered random, particularly if someone who doesn't routinely do the task was involved.  Maybe the disk was an outlier (not really random problem) and failed at a much lower pressure than design pressure?&lt;/div&gt;&lt;br /&gt;&lt;div&gt;What evidence do you to support either route? Is it simple evidence (like pressure readings from a data logging transducer) or the opinion of an expert who has had bad experience with runaway reactions in the past? The strength of the Apollo Root cause approach is that it helps you to explore many different pathways, but most critically you need evidence to support whatever pathway you go down.&lt;/div&gt;&lt;br /&gt;&lt;div&gt;Perhaps you have evidence for both. In the future I'll explore ways to weigh evidence in order to choose the proper route to explore.&lt;/div&gt;&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-2204593267953670698?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/2204593267953670698/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=2204593267953670698' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2204593267953670698'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2204593267953670698'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/06/causal-bias.html' title='Causal Bias'/><author><name>Tech Problem Solver</name><uri>http://www.blogger.com/profile/00082055607681100379</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><media:thumbnail xmlns:media='http://search.yahoo.com/mrss/' url='http://4.bp.blogspot.com/_lrj7S5AfIac/SjlWsYvLHyI/AAAAAAAAAAU/Wq89k6vyw10/s72-c/RootCauseExample2.png' height='72' width='72'/><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-2936218636567203543</id><published>2009-06-03T09:26:00.000-07:00</published><updated>2009-06-05T16:17:33.520-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Bias'/><category scheme='http://www.blogger.com/atom/ns#' term='Root Cause'/><title type='text'>Beware of a Story</title><content type='html'>Real life is complicated and messy. If you encounter a root cause analysis where the data fits the solution too neatly, be careful. It is rare that all evidence fits a theory, it if does, there's a chance that something was left out in order to make it fit or the data was handled incorrectly. This is known as 'silent evidence' since it is not presented or available. This is another form of confirmation bias, the situation where we only focus on data that fits our mind-set or theory.&lt;br /&gt;&lt;br /&gt;For an &lt;a href="http://economix.blogs.nytimes.com/2009/05/05/obesity-and-the-fastness-of-food/" target="_blank"&gt;example of this &lt;/a&gt;see, the "story" presented by a correlation plot of time spent eating versus Body Mass Index (BMI) for a number of countries presented on the NY Times website. Read the comments and you can see that there are many flaws in the story illustrated by the x-y scatterplot. The plot weaves a nice story supporting the author's prejudice about fast food but the data does not support that story. (nor does it &lt;em&gt;not&lt;/em&gt; support it)&lt;br /&gt;&lt;br /&gt;A strength of the Apollo root cause analysis approach is that it helps force you to consider many causes that contribute. However, the trap we fall into is to focus on only one cause-effect path and neglect others. This may make a nice story but won't necessarily reflect reality.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-2936218636567203543?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/2936218636567203543/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=2936218636567203543' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2936218636567203543'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2936218636567203543'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/06/beware-of-story.html' title='Beware of a Story'/><author><name>Tech Problem Solver</name><uri>http://www.blogger.com/profile/00082055607681100379</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-1049727699536306659</id><published>2009-05-23T12:20:00.000-07:00</published><updated>2009-05-23T12:32:06.955-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Creativity'/><title type='text'>We're all Creative</title><content type='html'>In &lt;a href="http://lccn.loc.gov/2008016560" target="_blank"&gt;Moving To Higher Ground&lt;/a&gt;, Wynton Marsalis writes that creativity is not the province of  a small, specialized group of people but that everyone is creative.  He gets kids to blast away on instruments doing whatever and points out that they are creating.&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;He goes on to say "&lt;span class="Apple-style-span" style="font-style: italic;"&gt;I told you it was easy&lt;/span&gt; [to be creative].  &lt;span class="Apple-style-span" style="font-style: italic;"&gt;It's only hard if you want to sound good.&lt;/span&gt;"&lt;/div&gt;&lt;div&gt;We don't lack creativity.  The trick is bringing that creativity to fruition.&lt;br /&gt;&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-1049727699536306659?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/1049727699536306659/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=1049727699536306659' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/1049727699536306659'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/1049727699536306659'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/05/were-all-creative.html' title='We&apos;re all Creative'/><author><name>Tech Problem Solver</name><uri>http://www.blogger.com/profile/00082055607681100379</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-8481876846886239610</id><published>2009-05-16T12:56:00.000-07:00</published><updated>2009-05-18T12:26:54.258-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Diversity'/><category scheme='http://www.blogger.com/atom/ns#' term='Creativity'/><title type='text'>Relationship of Art &amp; Science</title><content type='html'>Too often we focus on our strengths. Scientists &amp;amp; engineers have strong analytical skills and cultivate those throughout their education. Others have artistic skills and cultivate those. Frequently this is of necessity because we don't have time for both. Mae Jemison, an astronaut, doctor, and dancer (not necessarily in that order) talks about the relationship between art and science in a &lt;a href="http://www.ted.org/index.php/talks/mae_jemison_on_teaching_arts_and_sciences_together.html" target="_blank"&gt;TED talk&lt;/a&gt;. &lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Problem solving requires creativity and as I've mentioned before, developing our creativity requires developing all parts of our mind. Try doing something new. Even if you aren't successful (or even moderately good), it will stimulate your mind. Bust out the crayons and color with your kids, try photography, write a &lt;a href="http://dissertationhaiku.wordpress.com/" target="_blank"&gt;Haiku&lt;/a&gt;, who knows what. Just try something you wouldn't normally do today.&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-8481876846886239610?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/8481876846886239610/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=8481876846886239610' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/8481876846886239610'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/8481876846886239610'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/05/relationship-of-art-science.html' title='Relationship of Art &amp; Science'/><author><name>Tech Problem Solver</name><uri>http://www.blogger.com/profile/00082055607681100379</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-4109385176595826550</id><published>2009-05-07T16:57:00.001-07:00</published><updated>2009-05-15T18:16:05.393-07:00</updated><title type='text'>Scientific Method and Problem Solving</title><content type='html'>In the scientific method one suggests a hypothesis and then tries to find evidence disproving it.  Failure to find evidence that refutes the theory means the theory is true.&lt;br /&gt;&lt;br /&gt;This approach is a more robust method of problem solving than suggesting a solution (hypothesis) and then doing experiments to support it.&lt;br /&gt;&lt;br /&gt;As Heuer points out in Chapter 4 of his &lt;a href="https://www.cia.gov/library/center-for-the-study-of-intelligence/csi-publications/books-and-monographs/psychology-of-intelligence-analysis/PsychofIntelNew.pdf"target="_blank"&gt;book&lt;/a&gt;, a hypothesis (solution) can never be proven by even a large body of evidence since many hypotheses may be consistent with the evidence, but a single instance of incompatible evidence is enough to sink a hypothesis.&lt;br /&gt;&lt;br /&gt;When suggesting solutions, plan some experiments that seek to disprove them.  If you are unable to cause your solution to fail deliberately, it will be that much stronger.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-4109385176595826550?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/4109385176595826550/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=4109385176595826550' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/4109385176595826550'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/4109385176595826550'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/05/scientific-method-and-problem-solving.html' title='Scientific Method and Problem Solving'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-7194948580783718183</id><published>2009-05-02T09:21:00.001-07:00</published><updated>2009-05-02T09:40:18.515-07:00</updated><title type='text'>Psychology of Intelligence Analysis</title><content type='html'>I recently came across a book written for Intelligence Analysts in the CIA.  After reading just the introduction and the a couple of chapters I can tell it will be the subject of several (many?) future posts.  Although this book by Richards Heuer, Jr. is directed towards the analysis of what I call "soft" information, it is equally useful for scientists and engineers working with more concrete (or simple) evidence.&lt;br /&gt;&lt;br /&gt;&lt;a href="https://www.cia.gov/library/center-for-the-study-of-intelligence/csi-publications/books-and-monographs/psychology-of-intelligence-analysis/PsychofIntelNew.pdf"target="_blank"&gt;Psychology of Intelligence Analysis &lt;/a&gt; is available on-line.  There is also a &lt;a href="http://lccn.loc.gov/2006287615" target="_blank"&gt; 2006 version &lt;/a&gt; available .&lt;br /&gt;&lt;br /&gt;This book is about avoiding pitfalls when analyzing information and looks like it will address the topic from a higher level.  In Chapter 2 Heuer already addresses the issues of simple evidence and confirmation bias.  Heuer points out that &lt;span style="font-weight:bold;"&gt;"We tend to perceive what we expect to perceive"&lt;/span&gt; It is easier to notice data that already fits into our mind-set and is similar to what we already know.  This is a little different than perceiving what we &lt;span style="font-style:italic;"&gt;want &lt;/span&gt;to perceive which I think is a little easier to recognize and avoid.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-7194948580783718183?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/7194948580783718183/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=7194948580783718183' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/7194948580783718183'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/7194948580783718183'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/05/psychology-of-intelligence-analysis.html' title='Psychology of Intelligence Analysis'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-3428779107093822094</id><published>2009-04-30T12:13:00.001-07:00</published><updated>2009-05-02T09:17:17.981-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Randomness'/><category scheme='http://www.blogger.com/atom/ns#' term='Bias'/><title type='text'>Confirmation Bias</title><content type='html'>We often look for data to support our proposed solution. "&lt;a href="http://lccn.loc.gov/2007042507"target="_blank"&gt;The Drunkard's Walk: How Randomness Rules Our Lives &lt;/a&gt;" mentions this in relation to us picking only the random events that support our hypotheses.  We also will plan experiments that support our existing hypothesis instead of looking for ways to disprove it.&lt;br /&gt;&lt;br /&gt;The best solutions are those which can't be made to fail as opposed to those which need the stars aligned (or maybe that special operator) to work.&lt;br /&gt;&lt;br /&gt;Psychologist's also have a term for this as I heard on the radio this morning.  "Magical Thinking" or something like that.  We tend only to remember what we want and not look at the data impartially.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-3428779107093822094?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/3428779107093822094/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=3428779107093822094' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/3428779107093822094'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/3428779107093822094'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/04/confirmation-bias.html' title='Confirmation Bias'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-2404417007006791747</id><published>2009-03-16T18:41:00.000-07:00</published><updated>2009-04-19T17:53:31.716-07:00</updated><title type='text'>Fly larvae and simple evidence.</title><content type='html'>In the Monster of Florence, the investigators ignored simple evidence that cannot be faked and instead relied on the testimony of people with vested interests in the outcome.  Instead of taking the evidence of fly larvae on the corpses (fly larvae had no interest in the outcome of the murder investigation), they instead trusted the testimony of people since that testimony fit their theory as to the time of death better than the physical evidence of the body's decay.&lt;br /&gt;&lt;br /&gt;When investigating a root cause and gathering evidence to support a solution, keep in mind the types of evidence you are gathering.  Often we want a certain outcome to be true and interpret information to fit that outcome.  This will often lead you down the wrong path.  Try to gather evidence that is independent of the solution you seek.  I call this simple evidence.  It cannot be faked and can only be interpreted in one way.&lt;br /&gt;&lt;br /&gt;If your evidence requires assumptions then it is not simple evidence.  Those assumptions may be wrong.  Often our assumptions are biased by our experiences our outlook.  Try to avoid them.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-2404417007006791747?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/2404417007006791747/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=2404417007006791747' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2404417007006791747'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2404417007006791747'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/03/fly-larvae-and-simple-evidence.html' title='Fly larvae and simple evidence.'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-3699091583244602516</id><published>2009-03-16T17:44:00.000-07:00</published><updated>2009-03-16T18:38:38.362-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Failure'/><title type='text'>Occam's Razor</title><content type='html'>I just finished, "&lt;a href="http://lccn.loc.gov/2008000771"target="_blank"&gt;The Monster of Florence &lt;/a&gt;".  Douglas Preston and Mario Spezi's account of a serial killer in Florence, Italy and the investigations attempting to find the killer(s).&lt;br /&gt;&lt;br /&gt;I was struck by the complexity of the theories that the investigators proposed in order to build their case against some individuals (and groups).  This brought to mind Occam's Razor's, a principle that states that you should make as few assumptions as possible when trying to explain a phenomenon.&lt;br /&gt;&lt;br /&gt;This applies to finding solutions.  The more complex the solution, you develop, the more chances there are for problems in the future.  Keeps things simple and your solutions will have greater longevity, be easier to implement, and easier for others to follow.  Complex solutions can be a house of cards that will come crashing down when one aspect or another isn't fully implemented as intended.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-3699091583244602516?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/3699091583244602516/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=3699091583244602516' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/3699091583244602516'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/3699091583244602516'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/03/occams-razor.html' title='Occam&apos;s Razor'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-825242041168061440</id><published>2009-02-07T19:39:00.000-08:00</published><updated>2009-02-07T19:48:51.573-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Tools'/><category scheme='http://www.blogger.com/atom/ns#' term='Diversity'/><title type='text'>De Bono's Six Hats</title><content type='html'>One problem solving technique commonly used is brainstorming - a technique with which I'm sure you are all familiar.  However, we all see things from our perspective. One variation to try to force you out of your "common sense" is the &lt;a href="http://en.wikipedia.org/wiki/De_Bono_Hats"target="_blank"&gt;De Bono hats&lt;/a&gt;.  There are many references on the web and published so you can look them up for yourself.&lt;br /&gt;&lt;br /&gt;One thing I'm contemplating is whether you can do this within your own field.  Sometimes we try to solve all problems with whatever tool we're best at.  Try using a tool other than your favorite for the problem.&lt;br /&gt;&lt;br /&gt;For example, maybe Excel isn't the best tool for presenting your data.  Perhaps a Word document would be better or even - dare I say - Powerpoint.&lt;br /&gt;&lt;br /&gt;Don't use duct tape and vise grips to fix everything.  Get to learn different tools and give them a try.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-825242041168061440?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/825242041168061440/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=825242041168061440' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/825242041168061440'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/825242041168061440'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/02/de-bonos-six-hats.html' title='De Bono&apos;s Six Hats'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-5269214521658384112</id><published>2009-01-26T07:57:00.001-08:00</published><updated>2009-02-08T19:59:55.360-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Communication'/><title type='text'>Changing E-Mail Subjects</title><content type='html'>Along the lines of my earlier post about e-mailing.&lt;br /&gt;&lt;br /&gt;Have you ever been part of an e-mail chain where the subject morphed from the original to something else? &lt;br /&gt;&lt;br /&gt;Don't be afraid to &lt;span style="font-style:italic;"&gt;change &lt;/span&gt;the subject line or recipients of an e-mail chain or delete non-relevant sections.  In addition to intellectual property issues, there can be a lot of waste associated with not keeping the e-mail header information current.&lt;br /&gt;&lt;br /&gt;E-mail is pervasive and many people get hundreds of e-mails a day.  If your subject does not communicate effectively, your message won't even see the light of day.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-5269214521658384112?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/5269214521658384112/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=5269214521658384112' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/5269214521658384112'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/5269214521658384112'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/01/e-mail-subjects.html' title='Changing E-Mail Subjects'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-7072596203719464670</id><published>2009-01-07T12:09:00.000-08:00</published><updated>2009-01-07T12:16:03.740-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Root Cause'/><title type='text'>Conditions &amp; Actions</title><content type='html'>When doing a cause &amp;amp; effect analysis, remember that for any effect there is both a &lt;span style="font-style: italic;"&gt;condition &lt;/span&gt;and an &lt;span style="font-style: italic;"&gt;action &lt;/span&gt;that must occur.&lt;br /&gt;&lt;br /&gt;In order for a fire to start, you need more than the &lt;span style="font-style: italic;"&gt;conditions &lt;/span&gt;of fuel, oxygen and heat.  You also need an &lt;span style="font-style: italic;"&gt;action &lt;/span&gt;(e.g. a spark, a match strike) for the first to start.  Sometimes the conditions are actions might be so obvious that you don't think of them at first, but it helps to include them since ti broadens your thinking - leading to better brainstorming or diverse thinking.  You might not think to include oxygen as a condition for a fire but you might miss an important solution if you don't.  That's why we use inert gas (nitrogen) glove boxes when working with pyrophoric materials.&lt;br /&gt;&lt;br /&gt;Looking for both conditions and actions will help you to build a more complete picture and ultimately lead to more effective solutions.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-7072596203719464670?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/7072596203719464670/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=7072596203719464670' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/7072596203719464670'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/7072596203719464670'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2009/01/conditions-actions.html' title='Conditions &amp; Actions'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-4232447600493092511</id><published>2008-12-26T09:48:00.000-08:00</published><updated>2009-02-07T19:49:53.588-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Visualization'/><category scheme='http://www.blogger.com/atom/ns#' term='Evaluation'/><category scheme='http://www.blogger.com/atom/ns#' term='Communication'/><title type='text'>Bias in Visualization</title><content type='html'>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.&lt;br /&gt;&lt;br /&gt;However, the opposite can happen, even though I'm sure you're familiar with the adage, "&lt;span style="font-family: trebuchet ms;"&gt;a picture is worth a thousand words.&lt;/span&gt;" Recently the Flowing Data site held a visualization &lt;a href="http://flowingdata.com/2008/12/01/contest-win-two-edward-tufte-books-enter-now/" target="_blank"&gt;contest&lt;/a&gt;.  The &lt;a href="http://flowingdata.com/2008/12/11/winner-of-tufte-books-and-many-other-good-entries/"&gt;results&lt;/a&gt; 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.&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;There is  fine line between illuminating data for your audience and prejudicing them.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-4232447600493092511?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/4232447600493092511/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=4232447600493092511' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/4232447600493092511'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/4232447600493092511'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/12/bias-in-visualization.html' title='Bias in Visualization'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-2779275784148467850</id><published>2008-12-22T12:12:00.000-08:00</published><updated>2009-02-07T19:50:22.198-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Tools'/><category scheme='http://www.blogger.com/atom/ns#' term='Visualization'/><category scheme='http://www.blogger.com/atom/ns#' term='Communication'/><title type='text'>FreeMind</title><content type='html'>&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_21FS69mjqwg/SU_3xbe2S7I/AAAAAAAAACg/L-DDxtZ2rkk/s1600-h/FM_Sample.png"&gt;&lt;img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 320px; height: 95px;" src="http://1.bp.blogspot.com/_21FS69mjqwg/SU_3xbe2S7I/AAAAAAAAACg/L-DDxtZ2rkk/s320/FM_Sample.png" alt="" id="BLOGGER_PHOTO_ID_5282713316491676594" border="0" /&gt;&lt;/a&gt;&lt;br /&gt;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?&lt;br /&gt;&lt;br /&gt;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 &lt;a href="http://freemind.sourceforge.net/wiki/index.php/Main_Page" target="_blank" &gt;FreeMind&lt;/a&gt;.  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.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-2779275784148467850?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/2779275784148467850/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=2779275784148467850' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2779275784148467850'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2779275784148467850'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/12/freemind.html' title='FreeMind'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><media:thumbnail xmlns:media='http://search.yahoo.com/mrss/' url='http://1.bp.blogspot.com/_21FS69mjqwg/SU_3xbe2S7I/AAAAAAAAACg/L-DDxtZ2rkk/s72-c/FM_Sample.png' height='72' width='72'/><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-4846393660037891625</id><published>2008-12-15T15:11:00.001-08:00</published><updated>2008-12-16T13:19:31.198-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Communication'/><title type='text'>Document Design</title><content type='html'>Much has been published about good design of information graphics.  Tufte's and Stephen Few's books &lt;a style="font-family: trebuchet ms; font-weight: bold;" href="http://lccn.loc.gov/2001271866"&gt;The Visual Display of Quantitative Information&lt;/a&gt; and &lt;a href="http://lccn.loc.gov/2004101575"&gt;&lt;span style="font-family: trebuchet ms; font-weight: bold;"&gt;Show Me the Numbers&lt;/span&gt;&lt;/a&gt; are definitely books you should read if you make graphs and tables of data.&lt;br /&gt;&lt;br /&gt;I just finished an equally useful book directed more at the text documents you create.  Robin Williams' &lt;a href="http://lccn.loc.gov/2008273333"&gt;&lt;span style="font-family: trebuchet ms; font-weight: bold;"&gt;The Non-Designer's Design Book&lt;/span&gt;&lt;/a&gt; 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. &lt;br /&gt;&lt;br /&gt;Anything that can help communicate your problem solutions to others effectively is adding value.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-4846393660037891625?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/4846393660037891625/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=4846393660037891625' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/4846393660037891625'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/4846393660037891625'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/12/document-design.html' title='Document Design'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-2684705530773805096</id><published>2008-12-12T17:03:00.001-08:00</published><updated>2008-12-15T15:11:03.133-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Data Smog'/><category scheme='http://www.blogger.com/atom/ns#' term='Communication'/><title type='text'>E-mail Subjects</title><content type='html'>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.&lt;br /&gt;&lt;br /&gt;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 '&lt;span style="font-family:trebuchet ms;"&gt;latest results&lt;/span&gt;' or '&lt;span style="font-family:trebuchet ms;"&gt;update&lt;/span&gt;'.  Do something meaningful to you and your audience.&lt;br /&gt;&lt;br /&gt;Don't assume everyone is as intrigued by your project as you.  Make sure you communicate effectively.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-2684705530773805096?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/2684705530773805096/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=2684705530773805096' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2684705530773805096'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2684705530773805096'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/12/e-mail-subjects.html' title='E-mail Subjects'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-6478667755985321273</id><published>2008-12-08T12:30:00.000-08:00</published><updated>2008-12-09T12:19:36.800-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Diversity'/><category scheme='http://www.blogger.com/atom/ns#' term='Improvement'/><title type='text'>Looking for Trouble</title><content type='html'>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.&lt;br /&gt;&lt;br /&gt;As one develops expertise in an area, you hopefully progress through the following stages:&lt;br /&gt;&lt;ol&gt;&lt;li&gt;Procedure follower&lt;/li&gt;&lt;li&gt;Procedure interpreter&lt;/li&gt;&lt;li&gt;Problem solver&lt;/li&gt;&lt;li&gt;Problem definer&lt;/li&gt;&lt;/ol&gt;&lt;span style="font-weight: bold;"&gt;&lt;/span&gt;Early on, you just don't know enough about a subject.  You simply go about &lt;span style="font-weight: bold;"&gt;following procedures&lt;/span&gt; and making sure you do them as written.  Hopefully you quickly progress to someone who can &lt;span style="font-weight: bold;"&gt;interpret procedures&lt;/span&gt;.  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,&lt;br /&gt;&lt;ol&gt;&lt;li&gt;Get you coat and car keys.&lt;/li&gt;&lt;li&gt;Get in the car.&lt;/li&gt;&lt;li&gt;Start the car.&lt;/li&gt;&lt;li&gt;At the end of the driveway, turn right...&lt;/li&gt;&lt;/ol&gt;You get the drift.&lt;br /&gt;&lt;br /&gt;Next you are at the level where you &lt;span style="font-weight: bold;"&gt;solve problems&lt;/span&gt;.  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.&lt;br /&gt;&lt;br /&gt;Finally you reach a &lt;span style="font-weight: bold;"&gt;problem definer&lt;/span&gt;.  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.&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;Be a problem definer!&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-6478667755985321273?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/6478667755985321273/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=6478667755985321273' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/6478667755985321273'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/6478667755985321273'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/12/looking-for-trouble.html' title='Looking for Trouble'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-8334384557215958532</id><published>2008-12-06T09:12:00.000-08:00</published><updated>2008-12-08T12:28:51.499-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Improvement'/><category scheme='http://www.blogger.com/atom/ns#' term='Failure'/><title type='text'>Dueling Kaizens</title><content type='html'>My last post about types of solutions brought to mind an experience we had with Kaizen events.&lt;br /&gt;&lt;br /&gt;The &lt;span style="font-style: italic;"&gt;first &lt;/span&gt;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 &lt;span style="font-style: italic;"&gt;second &lt;/span&gt;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.&lt;br /&gt;&lt;br /&gt;How did this happen?  The Kaizen teams were made up mostly of those &lt;span style="font-style: italic;"&gt;outside &lt;/span&gt;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.&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;The advantage of bringing those unfamiliar with the process into a problem solving situation is that they have a &lt;a href="http://technicalproblemsolving.blogspot.com/2008/11/beginner-versus-expert.html"&gt;beginner's mind&lt;/a&gt;.  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.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-8334384557215958532?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/8334384557215958532/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=8334384557215958532' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/8334384557215958532'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/8334384557215958532'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/12/dueling-kaizens.html' title='Dueling Kaizens'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-2545306692682577581</id><published>2008-12-06T08:50:00.000-08:00</published><updated>2008-12-06T09:24:18.045-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Creativity'/><category scheme='http://www.blogger.com/atom/ns#' term='Improvement'/><title type='text'>Kaizen and Innovation</title><content type='html'>Problem solutions can be realized in three ways,&lt;br /&gt;&lt;ul&gt;&lt;li&gt;studying a problem and developing a solution&lt;/li&gt;&lt;li&gt; small incremental improvements which will ultimately lead to a solution (&lt;a href="http://en.wikipedia.org/wiki/Kaizen"&gt;Kaizen&lt;/a&gt;)&lt;/li&gt;&lt;li&gt;a major break-through (Innovation)&lt;/li&gt;&lt;/ul&gt;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)&lt;br /&gt;&lt;br /&gt;The other two approaches have their place in any successful organization and they should be cultivated by management.&lt;br /&gt;&lt;br /&gt;The advantage of &lt;span style="font-weight: bold;"&gt;Kaizen &lt;/span&gt;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.&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;Innovation &lt;/span&gt;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.&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;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?&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-2545306692682577581?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/2545306692682577581/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=2545306692682577581' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2545306692682577581'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2545306692682577581'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/12/kaizen-and-innovation.html' title='Kaizen and Innovation'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-6956767680627263201</id><published>2008-12-02T15:43:00.000-08:00</published><updated>2008-12-02T15:55:08.577-08:00</updated><title type='text'>Failure to succeed at attempts</title><content type='html'>&lt;a href="http://technicalproblemsolving.blogspot.com/2008/11/failure.html"&gt;Previously&lt;/a&gt; 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 &lt;span style="font-style: italic;"&gt;(for now&lt;/span&gt;).&lt;br /&gt;&lt;br /&gt;Failure to succeed at problem solving attempts however is under the control of individuals.  Some reasons why a particular solution fails are&lt;br /&gt;&lt;ul&gt;&lt;li&gt;No known solution&lt;/li&gt;&lt;li&gt;Too expensive&lt;/li&gt;&lt;li&gt;Too late&lt;/li&gt;&lt;li&gt;Solutions backfire&lt;/li&gt;&lt;/ul&gt;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?).&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;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.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-6956767680627263201?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/6956767680627263201/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=6956767680627263201' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/6956767680627263201'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/6956767680627263201'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/12/failure-to-succeed-at-attempts.html' title='Failure to succeed at attempts'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-6897928025358317918</id><published>2008-11-29T11:50:00.001-08:00</published><updated>2008-11-29T12:05:44.606-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Failure'/><title type='text'>Failure</title><content type='html'>In Chapter 14 of his book &lt;a href="http://lccn.loc.gov/2004057152"&gt;Collapse: How Societies Choose to Fail or Succeed&lt;/a&gt;, &lt;a href="http://en.wikipedia.org/wiki/Jared_Diamond"&gt;Jared Diamond&lt;/a&gt; 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.&lt;br /&gt;&lt;ul&gt;&lt;li&gt;Failure to anticipate&lt;/li&gt;&lt;li&gt;Failure to perceive a present problem.&lt;/li&gt;&lt;li&gt;Failure to try to solve a problem&lt;/li&gt;&lt;li&gt;Failure to succeed at attempts to solve the problem&lt;br /&gt;&lt;/li&gt;&lt;/ul&gt;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 &lt;span style="font-style: italic;"&gt;proactively.&lt;/span&gt;  That is the reasoning behind &lt;a href="http://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis"&gt;FMEA&lt;/a&gt; (Failure Mode &amp;amp; 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.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-6897928025358317918?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/6897928025358317918/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=6897928025358317918' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/6897928025358317918'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/6897928025358317918'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/11/failure.html' title='Failure'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-720990424781209933</id><published>2008-11-25T17:34:00.000-08:00</published><updated>2008-11-25T17:39:09.568-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Measurement'/><title type='text'>Measurement</title><content type='html'>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.&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;Without measurement, you are blind to your current situation and how it may (or may not) change.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-720990424781209933?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/720990424781209933/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=720990424781209933' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/720990424781209933'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/720990424781209933'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/11/measurement.html' title='Measurement'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-2068062667306575707</id><published>2008-11-21T19:46:00.001-08:00</published><updated>2008-11-21T20:56:10.253-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Visualization'/><title type='text'>The Art of Problem Solving</title><content type='html'>I've written about visualization as a way to solve problems.&lt;br /&gt;&lt;br /&gt;Here's a&lt;a href="http://www.idiagram.com/CP/process.html"&gt; &lt;/a&gt;&lt;a href="http://www.idiagram.com/CP/process.html"&gt;visualization&lt;/a&gt; of the problem solving process itself.  I like it so much I've added it to my links in the sidebar.&lt;br /&gt;&lt;br /&gt;Nice!&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-2068062667306575707?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/2068062667306575707/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=2068062667306575707' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2068062667306575707'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2068062667306575707'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/11/art-of-problem-solving.html' title='The Art of Problem Solving'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-7917454689813844701</id><published>2008-11-20T08:07:00.000-08:00</published><updated>2008-11-20T08:30:18.609-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Modelling'/><category scheme='http://www.blogger.com/atom/ns#' term='Creativity'/><category scheme='http://www.blogger.com/atom/ns#' term='Visualization'/><title type='text'>Modeling</title><content type='html'>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.&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;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 &lt;a href="http://chandoo.org/wp/"&gt;Pointy-Haired Dilbert&lt;/a&gt; and &lt;a href="http://peltiertech.com/WordPress/"&gt;Peltier Technical Services&lt;/a&gt;.  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.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-7917454689813844701?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/7917454689813844701/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=7917454689813844701' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/7917454689813844701'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/7917454689813844701'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/11/modeling.html' title='Modeling'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-322458755678514437</id><published>2008-11-18T07:58:00.000-08:00</published><updated>2008-11-18T08:13:12.505-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Creativity'/><category scheme='http://www.blogger.com/atom/ns#' term='Evaluation'/><title type='text'>Beginner versus Expert</title><content type='html'>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.&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;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.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-322458755678514437?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/322458755678514437/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=322458755678514437' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/322458755678514437'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/322458755678514437'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/11/beginner-versus-expert.html' title='Beginner versus Expert'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-4901223507193119711</id><published>2008-11-13T08:44:00.000-08:00</published><updated>2008-11-13T12:35:06.345-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Creativity'/><title type='text'>Play as a problem solving tool.</title><content type='html'>The Presentation Zen blog had a post today about &lt;a href="http://www.presentationzen.com/presentationzen/2008/11/play-is-good-for-you-and-its-good-for-business.html"&gt;play&lt;/a&gt; and refers to the &lt;a href="http://en.wikipedia.org/wiki/Beginner%27s_mind"&gt;beginner's mind&lt;/a&gt;.  I touched on the beginner's mind before in my &lt;a href="http://technicalproblemsolving.blogspot.com/2008/09/diversity-of-thought.html"&gt;Diversity of Thought&lt;/a&gt; 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.&lt;br /&gt;&lt;br /&gt;Problem solving often requires a fresh perspective. Play frees the mind from whatever rut you are in.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-4901223507193119711?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/4901223507193119711/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=4901223507193119711' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/4901223507193119711'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/4901223507193119711'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/11/beginners-mind.html' title='Play as a problem solving tool.'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-4506415771939469986</id><published>2008-11-10T10:32:00.000-08:00</published><updated>2008-11-10T10:39:43.103-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Visualization'/><title type='text'>Mapping</title><content type='html'>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. &lt;br /&gt;&lt;br /&gt;&lt;span style="font-style: italic;"&gt;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.&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;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.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-4506415771939469986?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/4506415771939469986/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=4506415771939469986' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/4506415771939469986'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/4506415771939469986'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/11/mapping.html' title='Mapping'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-2661886506447681038</id><published>2008-11-08T07:54:00.000-08:00</published><updated>2008-11-08T08:03:33.309-08:00</updated><title type='text'>Proactive versus Reactive</title><content type='html'>I was reading Seth Godin's blog and found his post about &lt;a href="http://sethgodin.typepad.com/seths_blog/2008/11/reacting-respon.html"&gt;Reacting, Responding &amp;amp; Initiating&lt;/a&gt;.  His thoughts are pertinent to problem solving also. &lt;br /&gt;&lt;br /&gt;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.  &lt;span style="font-style: italic;"&gt;Initiate &lt;/span&gt;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. &lt;br /&gt;&lt;br /&gt;Are you &lt;span style="font-style: italic;"&gt;reacting &lt;/span&gt;to problems that have occurred, &lt;span style="font-style: italic;"&gt;responding &lt;/span&gt;to external data which indicates a problem is imminent (e.g. a trend on a statistical process control chart) or are you &lt;span style="font-style: italic;"&gt;initiating&lt;/span&gt; solutions to weaknesses in whatever  process you are working on?&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;span style="font-style: italic;"&gt;- I guess I'm reacting to Seth's posting - we can't always be initiators!&lt;/span&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-2661886506447681038?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/2661886506447681038/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=2661886506447681038' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2661886506447681038'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2661886506447681038'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/11/proactive-versus-reactive.html' title='Proactive versus Reactive'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-5885198710027717253</id><published>2008-11-05T12:18:00.000-08:00</published><updated>2008-11-09T17:43:02.050-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Visualization'/><title type='text'>Visualize</title><content type='html'>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 &lt;a href="http://flowingdata.com/"&gt;Flowing Data&lt;/a&gt;, &lt;a href="http://chandoo.org/wp/"&gt;Pointy-Haired Dilbert&lt;/a&gt;, and &lt;a href="http://blog.bissantz.com/"&gt;Me, Myself, and Blissantz&lt;/a&gt;.  Putting aside the specific area of &lt;span style="font-style: italic;"&gt;data &lt;/span&gt;visualization for now, visualization in general is important in problem solving.&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;As we move deeper and deeper into a virtual world, it pays to have your feet in the real world.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-5885198710027717253?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/5885198710027717253/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=5885198710027717253' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/5885198710027717253'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/5885198710027717253'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/11/visualize.html' title='Visualize'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-8800468702895876260</id><published>2008-11-03T15:50:00.000-08:00</published><updated>2008-11-03T15:58:29.720-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Statistics'/><title type='text'>Inquire</title><content type='html'>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.&lt;br /&gt;&lt;br /&gt;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.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-8800468702895876260?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/8800468702895876260/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=8800468702895876260' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/8800468702895876260'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/8800468702895876260'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/11/inquire.html' title='Inquire'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-6743081171673236075</id><published>2008-10-30T12:38:00.001-07:00</published><updated>2008-10-30T12:41:22.132-07:00</updated><title type='text'>Technical Problem Solving - The Site!</title><content type='html'>I finally got enough on my &lt;a href="http://sites.google.com/site/technicalproblemsolving/"&gt;Technical Problem Solving site&lt;/a&gt; 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.&lt;br /&gt;&lt;br /&gt;Still need to work on the navigation and links within the site, maybe add some graphics, and continue to add content.&lt;br /&gt;&lt;br /&gt;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.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-6743081171673236075?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/6743081171673236075/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=6743081171673236075' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/6743081171673236075'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/6743081171673236075'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/10/technical-problem-solving-site.html' title='Technical Problem Solving - The Site!'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-597055862887415890</id><published>2008-10-28T11:57:00.001-07:00</published><updated>2008-11-01T14:25:06.925-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Data Smog'/><title type='text'>Data Smog - Final Thoughts</title><content type='html'>I finished &lt;a href="http://lccn.loc.gov/96039496"&gt;Data Smog&lt;/a&gt;.  David Shenk proposes several antidotes (chapters 18ff) to data smog.&lt;br /&gt;&lt;ul&gt;&lt;li&gt;Be your own filter&lt;/li&gt;&lt;li&gt;Be your own editor&lt;/li&gt;&lt;li&gt;Simplify&lt;/li&gt;&lt;li&gt;De-Nichify&lt;/li&gt;&lt;li&gt;Don't forsake government&lt;/li&gt;&lt;/ul&gt;Other than than the last one, these are all useful advice for problem solvers.&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;Filtering &lt;/span&gt;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.&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;Editor&lt;/span&gt;.  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...).&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;Simplify&lt;/span&gt;.  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.&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;De-Nichify&lt;/span&gt;.  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.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-597055862887415890?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/597055862887415890/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=597055862887415890' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/597055862887415890'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/597055862887415890'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/10/data-smog-final-thoughts.html' title='Data Smog - Final Thoughts'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-4146651877263804569</id><published>2008-10-24T12:55:00.001-07:00</published><updated>2008-10-28T12:08:33.193-07:00</updated><title type='text'>Essential Ingredients of Problem Solving</title><content type='html'>I came across a list of essential ingredients of perception attributed to Rudolph Amheim.  The list is&lt;br /&gt;&lt;ul&gt;&lt;li&gt;active exploration&lt;/li&gt;&lt;li&gt;correction&lt;/li&gt;&lt;li&gt;grouping&lt;/li&gt;&lt;li&gt;simplification&lt;/li&gt;&lt;li&gt;abstractions&lt;/li&gt;&lt;li&gt;analysis &amp;amp; synthesis&lt;/li&gt;&lt;li&gt;completion&lt;/li&gt;&lt;li&gt;selection&lt;/li&gt;&lt;li&gt;comparison&lt;/li&gt;&lt;li&gt;combining&lt;/li&gt;&lt;li&gt;separating&lt;/li&gt;&lt;li&gt;putting into context.&lt;/li&gt;&lt;/ul&gt;&lt;br /&gt;These are all things that are elements of problem solving.  Cultivating these skills will enhance your ability to solve problems.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-4146651877263804569?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/4146651877263804569/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=4146651877263804569' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/4146651877263804569'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/4146651877263804569'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/10/essential-ingredients-of-problem.html' title='Essential Ingredients of Problem Solving'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-3322580429664458505</id><published>2008-10-18T12:52:00.000-07:00</published><updated>2008-11-01T14:25:57.869-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Data Smog'/><title type='text'>Data Smog-2007 update</title><content type='html'>I haven't re-read Shenk's book &lt;a href="http://lccn.loc.gov/96039496"&gt;Data Smog &lt;/a&gt;yet, but I found the following post by him on &lt;a href="http://www.slate.com/id/2171128/"&gt;Slate.Com&lt;/a&gt; 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.&lt;br /&gt;&lt;br /&gt;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 &lt;em&gt;experienced&lt;/em&gt; 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.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-3322580429664458505?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/3322580429664458505/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=3322580429664458505' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/3322580429664458505'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/3322580429664458505'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/10/data-smog-2007-update.html' title='Data Smog-2007 update'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-8632501424546465121</id><published>2008-10-18T08:50:00.001-07:00</published><updated>2008-10-18T08:52:50.884-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Data Smog'/><title type='text'>A broad focus</title><content type='html'>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.&lt;br /&gt;&lt;br /&gt;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 &lt;span style="font-weight: bold;"&gt;Data Smog&lt;/span&gt;.  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&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-8632501424546465121?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/8632501424546465121/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=8632501424546465121' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/8632501424546465121'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/8632501424546465121'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/10/broad-focus.html' title='A broad focus'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-3180528941563037024</id><published>2008-10-14T12:19:00.000-07:00</published><updated>2008-10-14T12:29:43.743-07:00</updated><title type='text'>Self-learning</title><content type='html'>I came across a comment in the &lt;a href="http://www.graphpaper.com/2008/01-25_edward-tuftes-iphone"&gt;graphpaper.com&lt;/a&gt; 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.&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;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.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-3180528941563037024?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/3180528941563037024/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=3180528941563037024' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/3180528941563037024'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/3180528941563037024'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/10/self-learning.html' title='Self-learning'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-3451389301143856028</id><published>2008-10-07T12:50:00.000-07:00</published><updated>2008-10-07T13:00:02.818-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Tools'/><title type='text'>Organizing the Process and Tools</title><content type='html'>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.&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;The other tool I've found is &lt;a href="http://www.mindola.com/"&gt;SuperNoteCard&lt;/a&gt;.  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.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-3451389301143856028?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/3451389301143856028/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=3451389301143856028' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/3451389301143856028'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/3451389301143856028'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/10/organizing-process.html' title='Organizing the Process and Tools'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-7567038054859011607</id><published>2008-10-02T13:12:00.000-07:00</published><updated>2008-10-02T13:17:43.615-07:00</updated><title type='text'>What's my angle?</title><content type='html'>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. &lt;br /&gt;&lt;br /&gt;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".&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-7567038054859011607?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/7567038054859011607/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=7567038054859011607' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/7567038054859011607'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/7567038054859011607'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/10/whats-my-angle.html' title='What&apos;s my angle?'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-2594628946931125853</id><published>2008-09-26T12:34:00.001-07:00</published><updated>2008-11-13T12:35:56.697-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Diversity'/><category scheme='http://www.blogger.com/atom/ns#' term='Creativity'/><title type='text'>Diversity of Thought</title><content type='html'>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.&lt;br /&gt;&lt;br /&gt;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.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-2594628946931125853?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/2594628946931125853/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=2594628946931125853' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2594628946931125853'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2594628946931125853'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/09/diversity-of-thought.html' title='Diversity of Thought'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-7000087551211275495</id><published>2008-09-24T14:02:00.001-07:00</published><updated>2008-10-28T12:07:15.532-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Data Smog'/><title type='text'>data, information, &amp; Knowledge</title><content type='html'>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. &lt;br /&gt;&lt;br /&gt;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.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-7000087551211275495?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/7000087551211275495/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=7000087551211275495' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/7000087551211275495'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/7000087551211275495'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/09/data-information-knowledge.html' title='data, information, &amp; Knowledge'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4544803008461181295.post-2031270550825774720</id><published>2008-09-23T12:54:00.000-07:00</published><updated>2008-09-23T17:08:41.128-07:00</updated><title type='text'>Initial Thoughts</title><content type='html'>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.&lt;br /&gt;&lt;br /&gt;Today I created the website &lt;a href="http://sites.google.com/site/technicalproblemsolving/"&gt;http://sites.google.com/site/technicalproblemsolving/&lt;/a&gt; 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.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4544803008461181295-2031270550825774720?l=technicalproblemsolving.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://technicalproblemsolving.blogspot.com/feeds/2031270550825774720/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4544803008461181295&amp;postID=2031270550825774720' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2031270550825774720'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4544803008461181295/posts/default/2031270550825774720'/><link rel='alternate' type='text/html' href='http://technicalproblemsolving.blogspot.com/2008/09/initial-thoughts.html' title='Initial Thoughts'/><author><name>mattj</name><uri>http://www.blogger.com/profile/05532899509096532143</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry></feed>
