When Problem Solving Methods Fail

Posted by bob on September 28, 2014

Sometimes we simply cannot “solve” a problem to our own satisfaction.  There are many reasons this can happen, but these reasons probably do not mean your problem-solving method was bad.

Probably the most common causes of failure are lack of time or money.  As the old saying goes, “Rome was not built in a day.”  But management or your customer often place an unrealistic schedule on a project and then also constrain the funds available to pursue solutions.  The people and results (quality) then suffer.

But situations like this do not mean that you cannot learn something from the experience.  You might learn that you cannot achieve a ten million dollar project for one hundred dollars.  You might learn that you cannot do a long-term project in a single night.  But you also might create a long list of very specific ideas that don’t fix a specific problem.  If you keep track of these ideas with good documentation, you may shorten your next problem-solving exercise.  On the other hand, maybe you prefer to keep repeating the same mistakes. Like old friends, we grow familiar with such errors and maybe accept them a little too easily.

A very common experience is to find that your list of What Do I know is very short and the list of What Don’t I Know about a specific problem is a much longer list.  When the information is not commonly available knowledge, it can take you a long time to work through these lists.

Perhaps the most destructive event to any project is the late arrival of a previously hidden constraint.  You are suddenly told, “Oh, didn’t you know?  This product has to fit into a space this small.”  All of your design assumptions go into the trash and you have to start from scratch.  Sometimes the late arriving constraint is simply a change in the rules for how the product is tested.

I recently ran into a situation where I wanted to adapt one audio product to work with a different product.  That is a very common problem, usually easily solved.  One part of this system was well documented; the second component was very poorly documented by its manufacturer.  Worse than this, a lot of the information available on the internet was simply wrong or misleading.  In this specific case, it turned out that the vendor provided an ordinary-looking audio cable with a hidden feature: the cable included a network of hidden resistors to accomplish some specific goals of their product.

A simple diagram would have saved hours of measurements and thinking.  It was very unobvious--to me at least--that this cable would be released into production without any special marking; or perhaps a notation in the user manual.  A simple tag or a note or diagram in the documentation could have saved me a lot of time and effort. 

I wonder how many people will be burned by this “special” cable when it gets thrown into a collection of other cables remaining after the primary product is no longer useful.  It is not an unreasonable assumption that most of the cables we use on a daily basis are simply conductors and connectors.  Having been burned, I will probably never make that same assumption so easily.  But I wonder how many other people will eventually fall into the same trap.

Although I eventually solved this problem, it was only because I had no time deadline.  It frustrated me to think that if I had needed this solution within a reasonable time, I would have been forced to throw the one product aside and purchase a different, more expensive solution.