Troubleshooters.Com
Presents
Troubleshooting
Professional
Magazine
Volume 10 Issue
2, Spring,
2006
Expect
Excellence -- and Get It!
|
Copyright (C) 2006 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 ]
“Champions do not become
champions when they win the event, but in the hours, weeks, months, and
years they spend preparing for it." -- T. Alan Armstrong.
|
CONTENTS
Editor's Desk
By Steve Litt
Dear Steve,
My car was overheating so I my mechanic replaced the thermostat, so
that didn't help. Then he rodded out the radiator, but that didn't
help. Then he replaced the water pump, but the problem was still there.
So he replaced the radiator, but no joy. I've spent almost a thousand
dollars and my car still overheats. What should I do?
I get emails like this every month. What should the reader do?
The short answer is simple -- get a new mechanic. The current one adheres to diagnosis by guesswork.
Then you might ask me -- but how do I pick a new mechanic? After all, a lot of them are like the one described in the first paragraph.
That's a good question, and the topic of this month's Troubleshooting Professional Magazine.
Let me make it clear, however, that I'm not singling out the automotive
repair industry. Extended Troubleshooting bungles occur in Information
Technology. In office machine repair. In computer repair. If something
needs repair, there are bunglers out there waiting to screw it up. And
there are also professionals waiting to fix it right the first time.
If you need something repaired and for whatever reason can't do it
yourself, this issue of Troubleshooting Professional Magazine guides
you in picking a winner to do the repair, and giving that winner every
opportunity to do an excellent job.
So kick back, relax, and read how to be served with excellence. And remember, if you're a Troubleshooter, this is your
magazine.
What Excellence Looks Like
By Steve Litt
To find someone excellent, you must know what excellence looks like. On
one level the answer is trivial -- excellence is a job done quickly to
specifications (or better), for a reasonable price. In the case of
troubleshooting, the "specifications" are simply having the symptom
removed without subsequent related problems.
The trick, of course, is talking to several troubleshooters and figuring
out which ones will do an excellent job. What does an excellent
Troubleshooter look like?
The answer turns out to be simple enough. The excellent Troubleshooter troubleshoots using a process similar to the Universal Troubleshooting Process. The consumer thoroughly understanding the Universal Troubleshooting Process has two huge advantages:
- Evaluating the Troubleshooter: Speaking with the prospective
Troubleshooter, she can evaluate the extent to which the Troubleshooter conforms to a
valid troubleshooting process.
- Helping the Troubleshooter: She can help the Troubleshooter by
providing a concise and complete symptom description. In the case of an
intermittent she can look for, find and report a reproduction procedure.
The quickest and easiest way to learn the Universal Troubleshooting Process
is to read the book Twenty
Eight Tales of Troubleshooting.
Evaluating the Troubleshooter
The first hint of quality comes from looking around the shop. Is there
equipment all over the place? If so, they're not performing UTP
(Universal Troubleshooting Process) step 1, Prepare.
Not a good sign. Are there arguments between employees, or employees
and customers? Team troubleshooting is probably not practiced here. Do
they tell you it will be three days until they can get to it? They have
a throughput problem.
Now you're ready for the Big Kahune of Troubleshooter evaluation -- the
symptom description. I once gave a full typewritten page symptom
description to a garage. The counter guy thanked me for being so
complete. Later the tech who worked on the problem thanked me, and said
he wished all his other customers did the same thing. This garage did a
great job.
Another time I gave a full page description to a different garage. The
counter guy asked me a couple questions, wrote a sentence or two on the
repair ticket, and threw my symptom description in the garbage. I can't
tell you whether they did a good job or not -- I walked. If they're not
interested in the observations of someone who uses the car 24/7, but
instead are willing to use their own valuable time to try to recreate
the knowledge I already told them, they're going to be slow and
inaccurate.
To a certain extent you can judge the shop by suggesting
troubleshooting techniques. This must be done carefully, however,
because every Tom Dick and Harry thinks they're smarter than the
Troubleshooter, and the Troubleshooter's response is usually "then why
aren't you fixing it?" In certain cases though, suggesting a
troubleshooting technique can screen out complete incompetents.
For instance, one time my car key got stuck in the ignition with the
motor running. You could start the engine, but couldn't turn it off
with the key. I turned it off by removing spark plugs one at a time,
because I sure didn't want to unplug the battery on a running car,
because that can cause thousands of dollars in damage. Yeah, I got shocked doing it, but not badly -- sparkplugs are all voltage and very little current.
So I brought it to a garage, and before leaving it with them, asked the
service manager not to turn it off by disconnecting the battery. He
asked me how else I expected them to turn it off, and I said by
removing spark plug wires. He said no, disconnecting the battery is not
harmful, and he didn't want his techs getting shocked. I thanked him
and drove to a garage willing to do it the right way.
Helping the Troubleshooter
Everyone with an easy job please raise your hand.
Hey, I don't see any hands.
There are no easy jobs. Troubleshooting is no exception. Troubleshooters desperately need the user's help.
The number one help your Troubleshooter needs is a complete and
accurate symptom description. WHAT indicates to you that there's a
malfunction? WHEN does it seem to occur? HOW can the symptom be
reproduced? You can see a complete list of symptom description
questions at http://www.troubleshooters.com/utp/ustep3.htm.
Another help is a helpful attitude. An understanding that 50% to 99% of
the job is finding the root cause. Often, especially with computers,
actually fixing the root cause can be trivial. It's finding the
root cause that's tough. Therefore, don't ask your Troubleshooter
to diagnose it free of charge. Don't ask "how much just to look at
it?". Diagnostics is much more than "looking at it". Don't be surprised
if she charges you a
refused estimate charge if you decide not to go ahead with the repair
once she's isolated the root cause enough to give you an estimate.
Someone must pay her for her labor in figuring it out.
Occasionally the problem will take an extremely long time to diagnose.
If you understand the Universal Troubleshooting Process, you'll be able
to tell whether the diagnostic delay was due to bad troubleshooting, or
a tough problem. If it was a tough problem, don't begrudge the
Troubleshooter a little extra money, over and above the initial
estimate, for her time. For an example of a job so difficult that I
gladly paid extra for diagnosis, see http://www.troubleshooters.com/tpromag/200504/200504.htm#_Sylvias_Bucking_Buick.
Keep Your Troubleshooter Honest
By Steve Litt
Before any repair commences, ask your automotive tech to save the old
parts for you. You won't be able to re-use the old parts, and very
likely you won't even be able to see whether they're bad. You probably
won't even know for sure if they came off your car. What asking for the
parts does is to put your Troubleshooter on notice notice not to
charge you for parts not installed.
Is your Troubleshooter a crook? Probably not. It's my belief that
Troubleshooters exhibiting a pattern and practice of dishonesty are
rare. However, I think many Troubleshooters have, on rare
occasions, "fudged" on the repair invoice a little bit, usually in
response to a repair that went slower than usual. By asking for your
old parts back, you minimize the chance of fudging.
Be aware that the prices of some parts, such as alternators, include a
discount for return of the old alternator to the rebuilding shop. In
such cases you'll usually forego getting the old part, although
sometimes it's practical to at least see the old part before it's sent
back to the rebuilding facility.
None of this applies if you're an "internal customer" of the
Troubleshooter. In that case, your company would dictate policies
regarding parts.
Eliminate Finger Pointing
By Steve Litt
When I programmed for a medical management company, a customer couldn't
boot their computer. The hardware guy said it was software. I went out
and saw it wasn't software, so I threw it back in the hardware guy's
lap. This went on a couple more times, and then the boss said "I want
both you and the hardware guy to go out there, and neither of you can
come back until it's fixed."
We both went out there, we both did the diagnostics we knew how to do,
and finally found out that when you type in the boot device as part of
the bootup, upper case letters must be used. It wasn't hardware or
software -- it was user error, but we both made the same error. Only
when we put our heads together and worked from the same set of
diagnostic tests was the problem solved.
Finger pointing can stretch troubleshooting out by days or weeks. If you demand excellence, find a way to eliminate it.
Steve Litt is the author of four books on the subject of troubleshooting. You can email Steve here.
Communication
By Steve Litt
Excellence seldom springs from nastiness. The boss constantly
criticizing his flock will know no excellence -- only the absense of
mediocrity (maybe). Real praise for a job well done promotes
excellence. Along with the praise, suggestions for doing it even better
next time contribute to continuous improvement. Those suggestions
should be a part of a two way dialog -- it's entirely possible the
employee has considered the suggestion already and rejected for a
reason the boss doesn't see. Boss and employee can talk to determine if
the roadblock can be overcome.
Encourage communications between employees. I've found the best ideas
come from real brainstorming sessions (not yes-men applauding the ideas
of their leader, but real brainstorming sessions).
And let me repeat one more time -- the communication between Troubleshooter and User while acquiring a symptom description is everything.
Respect
By Steve Litt
If there's one thing I could drum into every organization, it would be to respect the intelligence
of its members. No programs of the month. No treasure hunts. No cutesy
posters admonishing the flocks to practice teamwork or respect. No
exhortations to "be entrapeneurial" when it's known that there's a
salary cap of 7% per year. A real entrapeneur could double his income
(or half it) in a year. No "you can go as far as you want in this
organization" when it's widely known that the boss always gets the
credit.
Respect their time too.
Nothing is more insulting to an employee's time than working a hundred
hours one week to rebuild a server, and then being forced to put in 40
hours of face time the next, just because "it's expected". Employees
should not be expected to fill in for hourly workers just because it's
cheaper. If a huge photocopying job is needed, have a secretary do it.
Programmers and network administrators should not have to drive across
town to deliver backup tapes.
Respect their personal needs.
Don't keep them away from their families for days on end. Don't make it
impossible for them to have a social life or get exercise.
Employees must respect their employer.
If they have nothing good to say about the company, they should keep
their mouth shut. Terminally negative employees, especially those
without a legitimate gripe, should be fired for the good and morale of
everyone.
Everyone must respect customers and vendors. Customers can take their business elsewhere, and vendors can tell you to take your business elsewhere.
Respect their money. If you ask a shop "how much just to look at it?",
you're asking them to diagnose on the cheap. In many situations,
diagnosis is tough, and the actual part replacement is easy. In a
corporate situation, if you ask them to fund company trips with their
credit cards, make it easy for them to fill out expense reports, and
pay them right away. Pay them adequately for use of a company car.
Don't make a 300 pound person ride coach coast to coast.
Respect and morale go hand in hand. Morale and performance go hand in hand.
Expect Excellence
By Steve Litt
Expect excellence, don't demand it. The difference is subtle but
powerful. Good or bad, people often do what's expected of them. On the
other hand, if people are given demands, all too often they're so
ornary they deliberately shirk the demand.
You've learned the Universal Troubleshooting Process. You've read this
magazine and put its advice to work. You've selected the right
Troubleshooter and given her all the necessary help. Given those
preparations, it's reasonable to expect excellence. Expect it.
Troubleshooting Professional Needs Theme Ideas
By Steve Litt
This is the tenth year I've published Troubleshooting Professional
Magazine, and I'm running out of theme ideas. I've written about the
UTP, The Attitude, intermittence, bottleneck analysis, toolsmanship,
and generic problem solving. I've written short stories, dense and dry
treatises, and humor. I can't think of what else to write.
Which is why I need your help. Please email me with topics you'd like to see covered in future Troubleshooting Professional Magazine issues.
Steve Litt is the author of Samba Unleashed. You can email Steve here.
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