Troubleshooters.Com Presents

Troubleshooting Professional Magazine

Volume 8 Issue 4, Fall, 2004
Generic Problem Solving With the Universal Troubleshooting Process
Copyright (C) 2004,2005 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Troubleshooting Professional Magazine. All rights reserved to the copyright holder, except for items specifically marked otherwise (certain free software source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes all risk and responsibility for any outcome.

Steve Litt is the author of the Universal Troubleshooting Process Courseware,
which can be presented either by Steve or by your own trainers.

He is also the author of Troubleshooting Techniques of the Successful Technologist,
Rapid Learning: Secret Weapon of the Successful Technologist, and Samba Unleashed.

[ Troubleshooters.Com | Back Issues | Linux Productivity Magazine ]

No problem can stand the assault of sustained thinking. -- Voltaire


Editor's Desk

By Steve Litt
You might be surprised at this month's topic. After all, I've harshly criticized the vendors of generic problem solving methodologies for trying to sell them as technical troubleshooting tools. And once upon a time, while in class attempting examples using the Universal Troubleshooting Process to solve business problems, I lost so much credibility that I never again made such a claim.

So let me say it one more time. You CANNOT DEPEND on the Universal Troubleshooting Process to solve business problems, relationship problems, political problems, personal problems, or any problem on any fuzzily defined system. The Universal Troubleshooting Process (UTP for short) is sufficient only for solving problems on well defined systems.

That being said, vast portions of the UTP are very helpful in generic problem solving. As long as you're a UTP expert, you might as well know how it can help you in other areas of your life.  So kick back, relax, and enjoy the read. And remember, if you're a Troubleshooter, this is your magazine.
Steve Litt is the author of "Troubleshooting Techniques of the Successful Technologist".  Steve can be reached at Steve Litt's email address.

UTP Crossover

By Steve Litt
Sometimes one chart is worth a thousand words. Here's a chart of the steps of the UTP, and their applicability to generic problem solving:
Step name
Make a Damage Control Plan
Get the Symptom Description
Reproduce the Symptom
Sort of
Do the General (corrective) Maintenance
Narrow it Down
Repair or Replace the Defective Component
Sort of
Take Pride
Prevent Future Occurrence

Step 1: Prepare

This is equally applicable to technical troubleshooting and generic problem solving. In any human endeavor, preparation is a must. Tools must be assembled, customers and co-workers must be contacted, documentation must be gathered. Most of all, the person performing the task must attain an attitude conducive to success.

Step 2: Make a Damage Control Plan

This is equally applicable to technical troubleshooting and generic problem solving.

Athletes suffer career ending injuries. Employees make career ending mistakes. Businesses fail from bad decisions. The danger of catastrophy surrounds our every action. And yet we must take action, for inaction is a surer, if slower, route to failure. Doomed if we do, doomed if we don't -- what do we do?

The answer is to make a damage control plan. How far will you go without backup precautions? How can you prepare to minimize risk?

The collegiate wrestler does daily bridges and other neck strengthening exercises so a head-first slam on the mat is less likely to break his neck. An employee decides in advance what orders he will refuse in order to stay out of serious criminal, legal or employment trouble. The business obtains insurance and has its lawyers review contracts.

As my career began, Richard Nixon resigned because of Watergate. But several of his hirelings did jail time. I made up my mind that I would never never break the law at the request of an employer, even if it meant termination. A couple years later an employer asked me to violate EEOC regulations. With no uncertainty in my voice, I said no. My employer did the right thing and backed down. Yeah, they lost money on that job, but we all stayed out of prison and lived to make money another day.

Step 3: Get the Symptom Description

This is equally applicable to technical troubleshooting and generic problem solving.

It's pretty hard to solve a problem if the problem isn't defined. The magic questions for well defined and fuzzily defined systems are remarkably similar:

Well defined
What indicates to you that there is a malfunction?
Fuzzily defined
How does the system's performance differ from your expectations?

With the well defined system there's an as-designed state and behavior, and any departure from that is a malfunction. The fuzzily defined system was custom designed to perform a certain way, but that certain way may not have been optimal, or may have subsequently become suboptimal. As a result, a part of the symptom description in a fuzzily defined system is the expectations of the customer/employee/boss.

In fact, with fuzzily defined systems, the problem can be fixed by changing performance, expectations, or both. Sometimes a solution is found in which both expectations and performance are qualitatively and completely changed.

One cannot begin to solve any problem, whether of a system well or fuzzily defined, until one understands the nature of the problem. You'll note that all generic problem solving methodologies include something analogous to getting the symptom description, and include it very early in the process.

Step 4: Reproduce the Symptom

This is somewhat applicable generic problem solving.

Whether well or fuzzily defined, you don't try to reproduce a symptom if doing so creates a safety hazzard. For instance, if the symptom description was "missile #454 came within 8 seconds of launch", that's a symptom you do not try to reproduce. If safety dictates, shut down the system and research exactly what happened, mostly by interviews.

Whether well or fuzzy, try to observe the symptom. If not safety critical, try to cause it to occur if such causation is not harmful. Such causation usually isn't harmful in well defined systems, but very well might be in fuzilly defined systems. Consider the symptom "labor unrest reduces profit". Nobody would purposely incite labor unrest.

In the case of fuzzily defined systems, you don't so much reproduce a symptom as observe it, but the principle is similar. If possible, there's a need to confirm the symptom description.

Step 5: Do the General (corrective) Maintenance

This is equally applicable to technical troubleshooting and generic problem solving.

The purpose of corrective maintenance is to catch a lucky break and thus avoid the brutal parts of troubleshooting or problem solving. You do it by performing maintenance which, if things ran better, would really be preventive maintenance. Things that should be done anyway.

If a car bucks at higher speeds, and there have been no filter replacements or tuneups in 2 years, before trying to diagnose it, replace the fuel and air filters and give the car a tuneup. These things should be done at least once a year anyway, so they should be done now, and doing so just might fix the problem.

Now for some examples in fuzzily defined systems:

You have no energy. That's the departure from expectations. A further look at your lifestyle shows you get only 4 hours of sleep a night because you're so busy partying. Knowing that humans are "designed" to operate optimally on 8 hours a night, before seeing a doctor and possibly being misdiagnosed and malpracticed, doesn't it make sense to try getting 8 hours a night for awhile and observe the change in symptom?

Sales and profits have been down for several months. That's the departure from expectations. A further look at your business shows that your two salesmen make only one sales call each per week, because they're so loaded down with administrative work. Knowing that a salesman must make sales calls, before hiring another salesman, or firing the existing ones, or launching a new product line, or running an expensive ad campaign, wouldn't it make sense to offload some of the administrative work from the salesmen so they could make several sales calls per day, like salesmen are supposed to? Then, if  sales and profits are still down, you can begin more rigorous problem solving activities.

Step 6: Narrow it Down

This is ABSOLUTELY NOT applicable generic problem solving. DON'T TRY IT!

Step 6 of the UTP is based on numerous diagnostic tests. These diagnostic tests are harmless because they can be "backed out" (undone), and these diagnostic tests do not cause any harm. For instance, several lines of source code can be commented out of a program, and the program run against test data, to see if that affects the symptom. Regardless of the outcome, later on the lines of source code can be uncommented, and the original test data restored.

Consider how different things are in a fuzzily defined system. Imagine your company's sales and profit are way down, and you suspect the problem to be your advertising agency. Imagine that "as a test", you swapped out your agency with a "known good" agency (whatever "known good" might mean in the case of an advertising agency). One of two things can happen. Either sales return to expectations, or they don't. If they do, everything's fine. But what if they don't?

If sales don't return, you've proven the original ad agency wasn't the root cause (sort of). But you can't just back out this diagnostic test. You now have a contract with the new agency, like it or not. Your old agency might sue you if you breached a contract by firing them. Even if you somehow could fire the new agency, what's the likelihood that the old agency would take you back at the same rates?

Oh, and here's another problem: It might take a year or more to determine whether the agency change caused a sales change. That's just too long a time -- too much red ink under the dam.

Sort of

I mentioned that if the sales don't return, you've proven the original ad agency wasn't the root cause. That's sort of true, but not really. Ad agencies aren't in any way interchangable parts. Each has strengths and weaknesses that interact in specific ways with specific clients and specific markets. This is another way in which Step 6 of the UTP can give false indications in generic problem solving.

Step 7: Repair or Replace the Defective Component

This is not applicable generic problem solving.

With fuzzily defined systems, repair isn't simply a matter of repairing a defective part. Both expectations and performance must be addressed. Often an alternative, completely off the spectrum being considered, ends up being the best solution.

Step 8: Test

This is sort of applicable generic problem solving, except that instead of testing for disappearance of a symptom, you must test for a match between performance and expectations.

Step 9: Take Pride

This is applicable to ABSOLUTELY any human endeavor. It's probably more important in business, sports and life in general than it is in troubleshooting.

I discovered the power of immediately taking pride in accomplishments while investigating Troubleshooting. But Troubleshooting is just the tip of the iceberg. We humans have a tendency to focus on our failures and forget our successes. That's why it's vital to indelibly mark each victory in our mind. By immediately celebrating all victories, we permanently add those victories to our mental balance sheets.

How many stories do you hear of highly successful people getting to the top of the mountain, only to self-destruct soon after. They've accomplished the goal, there's nowhere else to go, and they feel let down. Consider the frequent heavy abuse of drugs and alcohol among the most successful, especially those achieving success at a young age. How often do we forget our daily successes, and focus on a failure. Or focus on the fact that we've reached the top and have no place to go. Without memories of our successes, we leave ourselves open to burnout, and maybe even substance abuse.

It's vital to celebrate victories as they happen. Don't put it off -- the feeling will float off in the winds of everyday life. Celebrate immediately in order to stamp the image of your victory firmly in your mind. Make taking pride a priority. Celebrate with your family, with your friends, with your co-workers, and with yourself. Celebrate every victory. Find a celebration place. Go there. Make sure your balance sheet has a surplus of remembered victories.

Step 10: Prevent Future Occurrence

This is as important in generic problem solving as it is in technical troubleshooting. In the corporate world it's called "lessons learned", and developed during "debriefing". In personal self-help it's often expressed in sayings like "if you keep doing the same things, you'll keep getting the same results".


Of the 10 steps of the Universal Troubleshooting Process, 2 are definitely not applicable to generic problem solving, two are somewhat applicable, and the other 6 are completely applicable to generic troubleshooting. What you can take away from this discussion is that by learning and practicing the Universal Troubleshooting Process, you've gained some excellent habits for solving all sorts of problems -- personal, interpersonal, relationship, sports and business.
Steve Litt is the creator of the Universal Troubleshooting Process.  Steve can be reached at Steve Litt's email address.

Learning a Generic Problem Solving Methodology

By Steve Litt
They say a second language is easier to learn because you've learned the concept of grammar in your native language. Your second computer language is easier to learn because you've learned the concept of syntax in your first. Similarly, your second problem solving methodology is easier to learn because you've learned some very basic principles from your first.

In any human endeavor you need to start out prepared, and you need a foundation of safety. These are steps 1 and 2 in the UTP, and they're unstated in most generic problem solving methdologies, but they're obviously needed. In any human endavor, you must start out with the right attitude (UTP step 1). Although this isn't stated in most generic problem solving methodologies, I'm sure practitioners of these methodologies would tell you it's true. Also, in the field of self-help, the idea of attitude is stressed almost to a fault, with one 1970's author going so far as to state you can learn to play an excellent game of golf by sitting back in a chair each day and imagining yourself playing golf.

You've learned that a problem is a descrepancy between performance and expectations. In the case of technical troubleshooting expectations are simply "as designed", but you understand the concept. You cannot solve a problem unless you find out in what way performance differs from expectations. You need a symptom description.

You need to observe the symptom for yourself. In the case of technical troubleshooting you reproduce the symptom in order to observe it. In generic problem solving it's usually just there, although if it's not you might need to try to reproduce it.

Whether a technical problem or a problem in a fuzzily defined system, before doing a lot of work to fix the problem, you look and see if there's anything obviously wrong. Something that should be fixed anyway. Maybe you'll get lucky and that will fix it.

As an example, you and your spouse are having trouble. Meanwhile, you're getting only 4 hours of sleep a night. Before spending a king's ransom on a marriage councillor, why not try getting 8 hours of sleep a night. Humans need at least 6, 8 is better, to even stay healthy. Maybe now that you're awake enough to listen without frustration or attention drift, your relationship will improve.

Next comes analysis. When troubleshooting a well defined system, analysis is as simple as divide and conquer. With fuzzily defined systems it's a complex analysis of performance improvements and related expectations. More on analysis later.

Next you implement the solution. In troubleshooting that's "repair or replace the defective component". With fuzzily defined systems it involves constructing a new system, managing expectations, and training.

Once it's implemented, did it really work. Test. Is the machine performing to specification? Is the newly modified business system performing to the new expectation?

If you want a happy workforce, take pride.

And finanally, prevent future occurrence. With a machine, inform everyone what caused it and how to avoid it. With a business system or other fuzzily defined system, take a long look into the future looking for potential problems and opportunities, and make plans to address them.


Analyzing a well defined system involves continual narrowing of the root cause scope. Solving a problem on a fuzzily defined system is much more difficult. You must analyze expectations, and see if any alternative expectations serve your needs better. You must research various performance-improvement/expectation pairs, and evaluate their cost of implementation (use the word "cost" loosely). Brainstorming helps.

I don't claim to be an authority, but would imagine that you start with lots of input -- brainstorming with lots of people, in order to get improvement/expectation pairs. Find a way to evaluate each for cost and best fit. Choose one.

What to take away from this article

I don't claim to be a generic problem solving expert. Yet it's pretty obvious that whatever problem solving methodology you choose, you can incorporate elements of the the Universal Troubleshooting Process into it and improve your results. If you've not yet learned a generic problem solving methodology, research several, secure in the fact that you already have the UTP under your belt, so the next methodology will be easier.
Steve Litt is the author of the Universal Troubleshooting Process courseware.   Steve can be reached atSteve Litt's email address.

Letters to the Editor

All letters become the property of the publisher (Steve Litt), and may be edited for clarity or brevity. We especially welcome additions, clarifications, corrections or flames from vendors whose products have been reviewed in this magazine. We reserve the right to not publish letters we deem in bad taste (bad language, obscenity, hate, lewd, violence, etc.).
Submit letters to the editor to Steve Litt's email address, and be sure the subject reads "Letter to the Editor". We regret that we cannot return your letter, so please make a copy of it for future reference.

How to Submit an Article

We anticipate two to five articles per issue, with issues coming out monthly. We look for articles that pertain to the Troubleshooting Process, or articles on tools, equipment or systems with a Troubleshooting slant. This can be done as an essay, with humor, with a case study, or some other literary device. A Troubleshooting poem would be nice. Submissions may mention a specific product, but must be useful without the purchase of that product. Content must greatly overpower advertising. Submissions should be between 250 and 2000 words long.

Any article submitted to Troubleshooting Professional Magazine must be licensed with the Open Publication License, which you can view at At your option you may elect the option to prohibit substantive modifications. However, in order to publish your article in Troubleshooting Professional Magazine, you must decline the option to prohibit commercial use, because Troubleshooting Professional Magazine is a commercial publication.

Obviously, you must be the copyright holder and must be legally able to so license the article. We do not currently pay for articles.

Troubleshooters.Com reserves the right to edit any submission for clarity or brevity, within the scope of the Open Publication License. If you elect to prohibit substantive modifications, we may elect to place editors notes outside of your material, or reject the submission, or send it back for modification. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com. Authors: please understand we can't place hyperlinks inside articles. If we did, only the first article would be read, and we can't place every article first.

Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):

Copyright (c) 2001 by <your name>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, version  Draft v1.0, 8 June 1999 (Available at (wordwrapped for readability at The latest version is presently available at

Open Publication License Option A [ is | is not] elected, so this document [may | may not] be modified. Option B is not elected, so this material may be published for commercial purposes.

After that paragraph, write the title, text of the article, and a two sentence description of the author.

Why not Draft v1.0, 8 June 1999 OR LATER

The Open Publication License recommends using the word "or later" to describe the version of the license. That is unacceptable for Troubleshooting Professional Magazine because we do not know the provisions of that newer version, so it makes no sense to commit to it. We all hope later versions will be better, but there's always a chance that leadership will change. We cannot take the chance that the disclaimer of warranty will be dropped in a later version.


All trademarks are the property of their respective owners. Troubleshooters.Com (R) is a registered trademark of Steve Litt.

URLs Mentioned in this Issue