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.
[ Troubleshooters.Com
| Back Issues | Linux Productivity Magazine ]
No problem can stand the assault of sustained thinking. -- Voltaire
|
CONTENTS
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.
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
|
Applicable
to
Generic
Problem
solving?
|
1
|
Prepare
|
Yes
|
2
|
Make a Damage Control Plan
|
Yes
|
3
|
Get the Symptom Description
|
Yes
|
4
|
Reproduce the Symptom
|
Sort of
|
5
|
Do the General (corrective)
Maintenance
|
Yes
|
6
|
Narrow it Down
|
No
|
7
|
Repair or Replace the Defective
Component
|
No
|
8
|
Test
|
Sort of
|
9
|
Take Pride
|
Yes
|
10
|
Prevent Future Occurrence
|
Yes
|
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".
Summary
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.
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.
Analysis
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.
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
http://opencontent.org/openpub/.
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 http://www.troubleshooters.com/openpub04.txt/ (wordwrapped for
readability
at http://www.troubleshooters.com/openpub04_wrapped.txt). The latest
version
is presently available at http://www.opencontent.org/openpub/).
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.
Trademarks
All trademarks are the property of their respective owners.
Troubleshooters.Com
(R) is a registered trademark of Steve Litt.
URLs Mentioned in this Issue