There was a time I answered that question affirmatively. Not that I ever successfully used it to solve an interpersonal relationship, but problems are problems, right?". I actually made the mistake of using relationship problems as examples in some courses. Sometimes it worked, and sometimes it bombed very badly.

Eventually I backed off my claim of being able to solve relationships, guaranteeing only to solve problems in "well defined systems". But I still didn't know why the Universal Troubleshooting Process didn't work on fuzzily defined systems.

To figure that out, I had to learn about the anatomy of a problem. You see, a well defined system problem is a subset of generic problems. A well defined system comes with two additional pieces of information for the Troubleshooter:

1. Complete definition of system components and their relationships
2. An as-designed state and behavior

But the as-designed state and behavior is a vital distinction. Here's why...

The most basic definition of problem solving is the following 2 step process:

1. Analyze the problem state
2. Analyze the solved state

They both work 75 hours a day, and have responsibilities for their son and his activities. This obviously leaves no time. Should they:

• One quits his or her job, and adjust their budget and living accommodations to the lesser income.
• Both demand their companies respect their time, cutting their workload to 50 hours/week, and take the chance of getting fired, laid off or passed over for a promotion.
• One or both get new jobs that take less time, and take the chance of an interruption of income.
• Surround Junior with tutors and sitters to give them more time.
• Take a second mortgage out on their house, and start a business together.

Generic problem solving methodologies are equipped to address both the problem state and the solved state. The Universal Troubleshooting Process is not a generic problem solving methodology, and therefore is sufficient only in the subset of problems in which the solved state is "restore to the as-designed state and behavior". So why would anyone use the Universal Troubleshooting Process, when generic processes handle all problems?

Simply stated, tools meant to design and to weigh alternatives are wasteful in problems where the solved state degenerates to "the as-designed state and behavior". This issue has an article called Cars and Tanks that discusses just how wasteful this can be.

So the purpose of this article so far has been to show that generic problem solving methodologies and problem solving methodologies optimized for well defined systems are neither interchangeable, nor viable substitutes for each other.

The previously listed two step representation of generic problem solving actually leaves out a couple things. A more realistic generic problem solving process would look like this:

1. Analyze the problem state
2. Analyze the solved state
3. Determine how to transition to the solved state
4. Prevent future problems

           .-------------------------------.
           |                               |
           |                               V
Analyze the solved state          Determine the transition
           ^                               |
           |                               |
           `-------------------------------'

There are different kinds of future problems to prevent. One is a recurrence of this same problem. That's achieved primarily by the problem state analysis. Then there's the creation of different problems. This is an area for study in the solved state analysis.

Creativity Jump Starts

Many of us think most creatively when exercising. I've designed many a computer program while skateboarding, bike riding, or walking through the woods.

The Universal Troubleshooting Process's Troubleshooter's mantra, "How can I narrow this down just one more time?" can easily be adapted to creativity jump starting. There are other questions that can jump start creativity:

• How can I use this (perceived problem) to my advantage?
• Does the task or process even need to be done at all? Why? Can I eliminate part of it?
• How can I simplify?
• What are the priorities? Why?
• Whose help would be valuable in thinking this through?
• Can I think of similar problems or situations?
• Who has solved a problem like this before? What did they do?
• What are the ethical considerations?
• Who has a stake in the direction of the decision? Why? Have I talked to them?
• How can I reduce antagonism in the decision making process?
• Construct questions with words who, what, where, when, why, how and how much.
• Construct questions with phrases "what is" and "what isn't".

Methodology Availability

If you're lucky enough to be in a company whose budget allows you receive generic problem solving training from a vendor, do it. If not, I'd suggest a thorough reading the web material of Dr. Charles Camp and Fred Fred Nickols. Both are excellent, and the URLs are in the URL's section of this magazine.

And a word of warning. One day a generic problem solving vendor may try to sell you generic problem solving training for your technologists, even though the technologists primary troubleshooting is technical (restoring well defined systems back to their as designed state). These vendors may even offer to train you to be a trainer in their methodology, with the obvious resume benefits.

Sounds great, but be very careful. Because when it comes to fixing well defined systems, if your organization uses a generic problem solving methodology and your competitor uses something like the Universal Troubleshooting Process, they'll clean your clock.