Potential pitfalls
Fallacious reasoning and poor interpersonal
relations account for more failed or belabored
troubleshooting efforts than any other impediments. With
this in mind, the aspiring troubleshooter needs to be
familiar with a few common troubleshooting mistakes.
Trusting that a brand-new component will
always be good. While it is generally true that a new
component will be in good condition, it is not always
true. It is also possible that a component has been mis-labeled
and may have the wrong value (usually this mis-labeling is a
mistake made at the point of distribution or warehousing and
not at the manufacturer, but again, not always!).
Not periodically checking your test
equipment. This is especially true with battery-powered
meters, as weak batteries may give spurious readings. When
using meters to safety-check for dangerous voltage, remember
to test the meter on a known source of voltage both
before and after checking the circuit to be
serviced, to make sure the meter is in proper operating
condition.
Assuming there is only one failure to
account for the problem. Single-failure system problems
are ideal for troubleshooting, but sometimes failures come
in multiple numbers. In some instances, the failure of one
component may lead to a system condition that damages other
components. Sometimes a component in marginal condition goes
undetected for a long time, then when another component
fails the system suffers from problems with both
components.
Mistaking coincidence for causality.
Just because two events occurred at nearly the same time
does not necessarily mean one event caused the
other! They may be both consequences of a common cause, or
they may be totally unrelated! If possible, try to duplicate
the same condition suspected to be the cause and see if the
event suspected to be the coincidence happens again. If not,
then there is either no causal relationship as assumed. This
may mean there is no causal relationship between the two
events whatsoever, or that there is a causal relationship,
but just not the one you expected.
Self-induced blindness. After a long
effort at troubleshooting a difficult problem, you may
become tired and begin to overlook crucial clues to the
problem. Take a break and let someone else look at it for a
while. You will be amazed at what a difference this can
make. On the other hand, it is generally a bad idea to
solicit help at the start of the troubleshooting process.
Effective troubleshooting involves complex, multi-level
thinking, which is not easily communicated with others. More
often than not, "team troubleshooting" takes more time and
causes more frustration than doing it yourself. An exception
to this rule is when the knowledge of the troubleshooters is
complementary: for example, a technician who knows
electronics but not machine operation, teamed with an
operator who knows machine function but not electronics.
Failing to question the troubleshooting
work of others on the same job. This may sound rather
cynical and misanthropic, but it is sound scientific
practice. Because it is easy to overlook important details,
troubleshooting data received from another troubleshooter
should be personally verified before proceeding. This is a
common situation when troubleshooters "change shifts" and a
technician takes over for another technician who is leaving
before the job is done. It is important to exchange
information, but do not assume the prior technician checked
everything they said they did, or checked it perfectly. I've
been hindered in my troubleshooting efforts on many
occasions by failing to verify what someone else told me
they checked.
Being pressured to "hurry up." When
an important system fails, there will be pressure from other
people to fix the problem as quickly as possible. As they
say in business, "time is money." Having been on the
receiving end of this pressure many times, I can understand
the need for expedience. However, in many cases there is a
higher priority: caution. If the system in question harbors
great danger to life and limb, the pressure to "hurry up"
may result in injury or death. At the very least, hasty
repairs may result in further damage when the system is
restarted. Most failures can be recovered or at least
temporarily repaired in short time if approached
intelligently. Improper "fixes" resulting in haste often
lead to damage that cannot be recovered in short
time, if ever. If the potential for greater harm is present,
the troubleshooter needs to politely address the pressure
received from others, and maintain their perspective in the
midst of chaos. Interpersonal skills are just as important
in this realm as technical ability!
Finger-pointing. It is all too easy
to blame a problem on someone else, for reasons of
ignorance, pride, laziness, or some other unfortunate facet
of human nature. When the responsibility for system
maintenance is divided into departments or work crews,
troubleshooting efforts are often hindered by blame cast
between groups. "It's a mechanical problem . . . it's an
electrical problem . . . it's an instrument problem . . ."
ad infinitum, ad nauseum, is all too common in the
workplace. I have found that a positive attitude does more
to quench the fires of blame than anything else.
On one particular job, I was summoned to fix
a problem in a hydraulic system assumed to be related to the
electronic metering and controls. My troubleshooting
isolated the source of trouble to a faulty control valve,
which was the domain of the millwright (mechanical) crew. I
knew that the millwright on shift was a contentious person,
so I expected trouble if I simply passed the problem on to
his department. Instead, I politely explained to him and his
supervisor the nature of the problem as well as a brief
synopsis of my reasoning, then proceeded to help him replace
the faulty valve, even though it wasn't "my" responsibility
to do so. As a result, the problem was fixed very quickly,
and I gained the respect of the millwright. |