General discussion

Locked

Best Practice for field technicians

By jason ·
I run a small company that supports several small businesses as a help desk. The client calls with a troubleshooting need and we dispatch a technician. Usually the need is based on some part of their computer or network or OS that is not working. It can be anything really.

What I am interested in doing is refining the practices of the field technicians so that we waste less time spinning our wheels trying to fix some problems. Sometimes the tshoot goes easy according to a Microsoft known issue, but other times the solution is elusive and a technician spends several hours (of which he cannot fully invoice) before he finally gives up and says the only solution is to reformat/reinstall. Of course, that takes awhile too.

Is there a book/manual of best practices for determining how to rule out solutions quickly and determine when it is appropriate to reformat instead of continued troubleshooting? Mainly I was hoping for a Microsoft resource that has best practices for troubleshooting.

This conversation is currently closed to new comments.

8 total posts (Page 1 of 1)  
| Thread display: Collapse - | Expand +

All Comments

Collapse -

by BFilmFan In reply to Best Practice for field t ...

as a software or hardware problem?
Step 2. Perform diagnosis. Separate symptom from cause. Is the system acting out for some underlying fundamental reason? Will addressing the symptoms do nothing for resolving the cause of those symptoms?
Step 3. Develop and implement the solution. Not surprisingly, this step is often repeated again and again.
Step 4. Verify that the solution worked. This is the proverbial feedback loop that assures us of success. Solutions typically need to be tested several times and under different conditions. Fixing a Windows NT Server?specific problem might break a Novell NetWare connection in a mixed server environment.
Step 5. Document the solution. Too often, IT professionals (including myself) will successfully implement a wonderful solution only to ?forget? the finer problem solving points at a future date when confronting the same scenario. In effect, we have to relearn the solution. Obviously taking a few extra minutes to document each and every solution from our troubleshooting exploits could return huge dividends posthaste!

Due to length of this response, it is continued in the next message...

Collapse -

by BFilmFan In reply to

First part of that should read:

Step 1. Identify the problem. Can you successfully identify the problem as a software or hardware problem?

Collapse -

by jason In reply to

I like your ideas, but what I need to award points is a specific book or Microsoft resource that covers these ideas in depth. Is there one? Another way to say that is , Where did you hear about what you suggested?

Collapse -

by BFilmFan In reply to Best Practice for field t ...

There is a well known system called DETECT.

D Discover the problem
E Explore the boundaries
T Track possible approaches
E Execute the approach
C Check for success
T Tie up loose ends

To enlarge on this sequence:

D Discover the problem. Speak with users at the ?user level,? not the technical level. Try to find out what software they are using (release versions if possible) and is their hardware on the Hardware Compatibility List (HCL)? What are the symptoms that the problem is displaying?
E Explore the boundaries. Can you and/or the user identify what changes have occurred since the system was last reported to work correctly? Can you identify what software was running when the problem occurred?

Tip: Here is an important dimension: Is the problem reproducible? Being able to reproduce the problem is an essential step in troubleshooting those tough ones that defy easy explanations and solutions. If you can?t reproduce the problem, you are in for a long haul (typically). Can you get lucky and apply a quick fix to the problem?

T Track possible approaches. This is just the documentation argument in sheep?s clothing. You can both learn from this incident and avoid the old inefficient trial-and-error approach by tracking the troubleshooting steps that you undertake.
E Execute an approach. Aside from managing expectations so that the different parties involved are not bothered if the first resolution attempt fails, you should already be thinking about plan ?B? if the first approach fails. Don?t forget that critical system and application files should be backed up prior to executing a task (or series of tasks) to solve your problem.
C Check for success. Assuming you solved the problem, can the user be taught to correct the problem if it should reappear?
T Tie up loose ends. Share the results with My method for troubleshooting is:

I am sure that others will want to weigh in here with commentary.

Collapse -

by jason In reply to

I like your ideas, but what I need to award points is a specific book or Microsoft resource that covers these ideas in depth. Is there one? Another way to say that is , Where did you hear about what you suggested?

Collapse -

by JamesRL In reply to Best Practice for field t ...

Its a process - not a Microsoft resource.

You probably won't find a magic book. ITIL(IT Infrastructure Library - a process methodology and approach) is a good resource, but thats a long journey, not quick fix.

I learned how to troubleshoot a few years ago. Let me define some best practises in addition to what you have already been given. And I don't really care that you won't award me points - I have had 20 desktop techs working for me, so I have some experience, in addition to the fact that I was a desktop tech myself for many years.

1) Build up a knowledge base. Document common fixes in a place available to all. Keep it up to date. Make sure your techs search it thoroughly.

2) Have your techs communicate with each other - by phone or MSN messenger or something. I find when I hit a wall I need to bounce around a few ideas with other techs - even ones who are less experienced can shed light on issues as they have a different perspective.

3) Develop specialties. Get to know who is good at what and encourage them to specialise, and share their expertise with others.

4) Give them the tools they need. Software, hardware whatever. Create a common toolset for everyone. Insist they become profiecient with their tools.

5) Get them together on a regular basis to explore common problems and issues. You as the owner can then try and identify common themes and tackle them.

The best way to get to the quickest solutions is by sharing the knowledge - your group is undoubtably stronger as a team than as a bunch of individuals - harness that.

James

Collapse -

by jason In reply to

OK, I see what you are all getting at and they are all great ideas. I'm surprised that no one has published a help desk manual that comprises the great ideas everyone has but I guess I'll make my own. You make some key points and they are all things we are doing now, I just haven't put them all together in a written format process that can be referred to. The thinktank approach is always a strong tool and so is the knowledgebase (any good ideas for a software that does that)

I will try to figure a way to divide points after the responses are done. It turns out I may have asked a question without an answer...

Collapse -

by Choppit In reply to Best Practice for field t ...

The best source of this knowledge is personal experience. The second best source of this knowledge is someone elses experience. For me the best source of secondhand knowledge is the internet. Heres my approach

1) Troubleshoot with personal knowledge
2) Reinforce understanding by reading manuals.(I find this useful for picking search terms for 3)
3) Search the web (get yourself a good search tool. I prefer Copernic Agent Pro)
4) Post on TR

This allows me to solve about 98% of my issues.

Back to IT Employment Forum
8 total posts (Page 1 of 1)  

Related Discussions

Related Forums