\nPart of solving the problem is making sure that the solution is available to other people. This is\nespecially important if it took you a long time to find the answer or if you are the expert and you\nrealize that it is not that likely that someone else will know this answer. These problems and their\nsolutions need to be documented and accessible to everyone.<\/p>
Experience has taught me that\nneither well-documented solutions nor accessibility alone can make the solution useful. I\u2019ve worked\nin places where half of the documentation was on-line, butmuch of it was incomplete, and the other\nhalf existed in people\u2019s heads or buried in their personal directories and therefore not accessible\nto the rest of the help desk staff.<\/p>
Although it may seem painfully obvious to say that the\nfirst step in solving a problem is finding the cause,<\/i> many help desk analysts tend to forget\nthis. Instead they try to cure <\/i>specific symptoms of the problem without looking for the\nunderlying cause. This manifests itself quite often when users ask for help in implementing a\nspecific solution. They have decided that a specific solution is best for their problem, and it is\nup to the help desk to give them the necessary assistance in implementing that solution. The issue\nis that in many cases, the solution they have chosen is not the best one for the problem.<\/p>
I\nhave received many calls from users wanting to implement a particular function within their word\nprocessing program (such as MS Word) and have them get annoyed when I tell them it isn\u2019t possible.\nIt turns out that what they are trying to accomplish is much better done from MS Excel. One of the\nreasons to thatthis happening to it is the help desk analyst often looks for and tries to solve the\nsymptoms rather than the underlying cause. For example, the symptom and not the problem itself is\nthat they are having difficulty implementing something in MS Word. It is therefore extremely\nimportant that the help desk analyst understand what the goal of the user is.<\/p>
One technique\nI find extremely useful is making sure you know what the user\u2019s problem really is. This might seem\nlike an obvious statement, but I have worked on problems myself where I discovered that the problem\nI was trying to solve was not the same as the one the user had. As in the case of the user who tried\nto solve a problem with MS Word that was best done in MS Excel, not knowing what the problem really\nis leads you to the wrong answer. Here, the simplest approach is just to ask the user what they are\ntrying to accomplish. <\/p>
I have often found that if the description of their problem also\nincludes the solution, you may not have reached the core problem. Try to get the user to describe\nthe problem without specifying the program or any other part of the solution. For example, in the\ncase of using MS Word to create a complicated table, the user cannot use the phrase "MS\nWord." Instead, the user would have to describe what they are trying to accomplish with the\ntable. In other words, you need to press the user for more specifics.<\/p>
Part of this is having\nthe user describe what the goal<\/i> is, what the behavior is, and what theexpected behavior\nshould be. This helps you to quickly get to those problems that are a result of eithermisconception\nor misunderstandings on the part of users. This also helps to clarify those issues where the user\nclaims the software has a bug or just isn\u2019t working right. <\/p>
When the user is done describing\nwhat is happening, repeat it back to them and asked them to confirm that this is what is actually\nhappening. It may also be useful to modify the statements slightly (such as changing the order of\nphrases) so that you\u2019re not simply repeating word-for-word what the user said. This helps to ensure\nthat you do not end up solving the wrong problem.<\/p>
The goal here is to understand what the\nuser needs. This means understanding what the problem is. I have worked on help desks myself where\nthe first thing users do is give you a detailed list of their hardware and configuration or going\ninto nauseating detail about a similar problem they had on another system. Although this is useful\nin many cases, it may become a burden when it is not relevant to the actual problem. It is up to you\nto guide<\/i> the user to ensure they do not get too far offtrack.<\/p>
The analyst needs to\ntake control of the conversation to ensure that the user provides enough information without\nproviding too much. Yes, as in the previous example, you can get too much information. First, too\nmuch information means you are getting things that are unrelated to the problem, and it is a waste\nof time to have the user provide it. Second, there is sometimes information that may <\/i>be\nrelated, but you don\u2019t yet need it. Getting it too early in the conversation may mean you either\nstart thinking about it prematurely or you lose track of things because of "information\noverload."<\/p>
When you are sure you have a clearer understanding of what the problem is,\nyou begin to seeif it fits any known pattern. For example, if this problem has the exact same\nsymptoms assomething that you have encountered before, the logical approach is to try the solution\nthatworked with the other problem. If the problems are not identical, can you find a problem that is\nsimilar? In essence, that is exactly what mechanics, doctors, physicist, or anyone else do who is\ntrying to solve a problem or prove a theory that has a number of pieces and may have multiple\nsolutions. Based on the evidence, you devise a theory and then investigate the system to see how\nwell it matches your theory. If it doesn\u2019t, you revise your theory.<\/p>
For those problems to\nwhich there is no easy solution, you\u2019ll have to apply a number ofrules of thumb (heuristics) as well\nas step-by-step instructions (algorithms). For example, therules of thumb may be to start with a\nsimpler task and build yourself up to a more-complicated task in order to see where the behavior\nbegins to change. Another rule of thumb may be to start with the default configuration and make\nchanges one by one.<\/p>
In dealing with problems with obvious causes or for which there is no\nstep-by-step procedureto follow, you may need to dig for more information. The lead-off question can\nbe something as simple as, "Just exactly what is happening?" This helps to clarify what\nyou know about the user\u2019s understanding of the problem and at the same time gives you an idea of the\ntechnical skills of the user. This is part of ensuring that both you and the user know exactly what\nthe problem is.<\/p>
In my experience, the more accurate this description, the more technically\ncompetentthe user is. Knowing the technical level of the user serves as a guide for all subsequent\nquestions. For example, you can ask the more-detailed technical questions earlier in theconversation\nif the user as a stronger background in the product. For example, it is a great time-saver to be\nable to say, "Start the network applet in the Control Panel" versus "Click on the\nStart button. You now see a menu. Click on the entry labeled Settings. Now find the icon labeled\nNetworking,\u2026" and so forth. <\/p>
The next step is to determine whether or not the system\never <\/i>behaved as intended. I must admit that I have worked on number of calls where I assumed\nthat the product was working correctly and then stopped for some reason. The emphasis on my approach\nwas in determining what would cause this aspect of the system to stop working. This led me down the\nwrong path, because it never had work correctly at all. Needless to say, this wasted a lot of my\ntime.<\/p>
If the product was working before and stopped for some reason, the most likely cause\nis thatsomething in the system was changed, despite what many users may try to convince you; it is\nunlikely that something "just stops working." Therefore, you need to find out what changes\nhave been made in the system. <\/p>
One change that is often overlooked is the physical location\nof the computer. How could the physical location have anything to do with the behavior of a piece of\nsoftware? Well, when you moved the computer you simply forgot to plug the printer back in! <\/p>
\nThis may seem a rather mundane issue, but you would be amazed at how many hotline calls are\ngenerated because of such problems. To avoid these kind of problems, you should run through a number\nof "quick fixes" before you begin looking at the mo-complicated solutions. Despite the\nsimplicity of the problem, loose cables generate more than their share of headaches. Loose cables\nseem to be the last thing that anyone checks. However, itis extremely annoying, if not embarrassing,\nwhen that is actually the cause. <\/p>
If you are running an internal help desk, checking cables\nmay be something that you can require<\/i> of the users prior to them calling the help desk. This\nmay require some additional training to ensure the users know how to seek the cables properly, but\nit is definitely worth the time in the long run. When you ask the user whether or not they have\nchecked the cables and they say "yes," you have already saved two or to three minutes on\nthe call. (Assuming they actually did check the cables. <\/p>
Despite the claims of Microsoft on\nthe stability of Windows NT, I have found that sometimes the best solution is to simply reboot the\nmachine. My success rate with using this in "solving" the problem is high enough that it\nhas become part of my standard palette of solutions. However, keep in mind that rebooting the system\nlike this may solve the symptoms,<\/i> but not the problem.<\/i> <\/p>
Often just knowing\nwhat has changed is sufficient to determine the solution, particularly if what was changed was done\nimproperly. However, it is sometimes necessary to repeat the steps on an existing, working system to\nsee if you can recreate the problem. In order to do this, you have to be able to recreate the user\u2019s\nenvironment as closely as possible. It is therefore extremely useful to have a test environment\nwhere you can try to recreate problems. <\/p>
How many different kinds of machines and different\nhardware are available in your test laboratory will depend on your company. The more standardized\nyour hardware and software, the fewer different kinds of both you\u2019ll need to maintain. However, you\nneed to remember that the purpose of the lab is to help you solve users\u2019 problems in order that they\nwork more efficiently. If users cannot work efficiently because you cannot solve their problem due\nto lack of resources, then you may end up losing more money than the cost of the equipment. <\/p>
\nIf you are dealing with mostly hardware problems, you may find it almost unavoidable to have spare\ncopies of all the different types of hardware you use. These not only can be used for test purposes\nbut also for emergencies should the hardware break down on production machines.<\/p>
One thing\nyou may want to consider is using some kind of removable media like the SyQuest drives we discussed\nin the chapter on sharing resources (Chapter xx). This allows you to create an extremely large\nnumber of hardware and software combinations with substantially less real investment in hardware. In\naddition, this saves you on licensing fees for the software that must be licensed for each installed\ncopy regardless of whether it used productive use or not (such as from Microsoft). <\/p>
The cost\nof a single SyQuest hard disk is much higher than the equivalent hard disk. However, you can install\nthe system on the SyQuest drive, configure it to one of your standards, replace it with a different\nSyQuest disk, install a different standard system and so forth. Whenever you need to test a specific\nsystem, all you need to do is switch the SyQuest disk. <\/p>
You might want to look into two\nproducts from KeyLabs (www.keylabs.com<\/i>):<\/font> RapidDeploy and\nLabExpert. RapiDeploy is used to automatically install and configure multiple machines. It addition,\nit creates "libraries" of standard configurations that you can use at any time. These\nlibraries can be used to switch back and forth between configuration or for easy disaster recovery.\nLabExpert is intended for use in a lab or classroom environment, where changes are made to a lot of\nmachines, and you want to return them to their original state. <\/p> Sometimes you\u2019ll find that\nyou can actually think too hard about the problem. That is, you spend too much time analyzing the\nproblem and the possible solutions before eventually deciding on a possible solution. I have found\nin many cases that the best course of action is to simply start with a number of possible solutions\nand see if they solve the problem. Even if the solution you try does not solve the problem, you have\neliminated it from consideration, and how it fails may give you valuable insight into the cause of\nthe problem.<\/p> One of the most common quick fixes is user error. In a way, this is similar to\nthe user having a misconception about how the program should function. However, identifying user\nerror is usually not as simple, as you may have to go step-by-step and examine everything the user\nis doing. In such cases, it is often useful to have the documentation in front of you so you can\nfollow along as the user performs each step. The reason I say you should have the documentation in\nfront of you is that you may know a faster way of doing something than is described in the\ndocumentation. Therefore, having the documentation in front of you helps you to ensure that you do\nthe same steps the user is doing and that the user is doing the steps correctly.<\/p> To some\nextent, going through the procedure step-by-step could be considered "hand-holding." You\nneed to know where hand holding stops and troubleshooting begins. I know many users who will call\nthe help desk and claim they followed everything exactly as it is in the manual just so they can get\nsomeone to walk them through the procedure. It is impossible to completely avoid people like this,\nbut with a little practice, it\u2019s easy to detect them, particularly if they keep calling with the\nsame kinds of problems.<\/p> As I mentioned above, one of the heuristics that you can apply is\ngetting back to basics. That is, getting the system back to use a state where you know what should\nwork. In some cases, I\u2019ve had to completely remove every card and every controller in the system and\nadd them back one by one. Software and hardware conflicts are common causes of problems. In many\ncases, the simplest solution is actually to start from scratch and work your way back up. This is\nparticularly important if you have mixed environments of Plug-and-Play, PCI, or anything else that\nsets the configuration automatically, plus ISA cards. Sometimes setting the cards manually is the\neasiest way to avoid conflicts.<\/p> Keep in mind that pulling every card out of the system may\nnot be necessary to identifyconflicts. Often you can easily identify conflicts by examining the\nmachine\u2019s configuration. <\/p> Most users are not proficient enough to be able to provide you\nwith the details of their system. This is where hardware inventory products such as NetSense come in\nextremely handy. Such products gather configuration information and store it in a central database.\nThey can then easily be accessed by your help desk.<\/p> One stumbling block in determining the\nproblem can often be the users themselves. If users knew everything there was to know about\ncomputers, there would probably been no need for them to be calling the help desk in the first\nplace. This often results in users\u2019 description of the problem or their system being done in\nambiguous and often inappropriate terms. For example, I regularly get calls from users who say they\ncannot "get into the screen" when they mean to say the computer will not boot.<\/p> In\nmany cases, what the user means is obvious. However, there will definitely be a number of calls\nwhere you cannot be sure. For example, I\u2019ve had calls from users who tell me how big their hard disk\nis when asked how much memory they have. Others may confusingly call the taskbar the toolbar.<\/p>\n One tool that I have found extremely useful in solving problems (not just troubleshooting help\ndesk calls) is MindManager from MindJet, LLC (www.mindjet.com<\/i>). Mind Manager is a tool that\nhelps you "map your mind." In essence, you start with a central idea and map out all of\nthe related issues. Any number of branches can lead off from that central idea, and each of these\nbranches in turn can have any number of branches. I talked in detail about Mind Manager in the\nchapter on System Administration (Chapter xx).<\/p> Another tool that I find extreme useful is a\nflow chart software, such as Visio Standard. Although less useful than MindManager during the actual\nproblem resolution, I find flow charts that have been included in existing problem\/solutions to be\nextremely useful. By following the flow chart as the computer or software goes about its business,\nyou know what it should be doing at each step and can quickly identify those places where the system\nis misbehaving.<\/p> Another important aspect I refer to as the "Tao of Tech Support."\nIt cannot be taught. It is notlearned. There are no words to describe it. It just is. This is the\nability to go beyond thedescription of the physical manifestations of the problem and seek the\n"motivation" behind the problem. What "forces" are coming into play to make the\nproblem manifest itself in this fashion.<\/p> You could run through a checklist of all related\nissues and examine each one by one, whichwould take an incredibe amount of time. Or you could\n"feel" the answer and solve theproblem very quickly. This ability is obviously hard to\ndescribe and it is something that not every analyst has or even will have. However, in my\nexperience, this ability is far more useful than an encyclopedic knowledge of the system. There are\nplaces to look for the knowledge, but the Tao of Tech Support is something you just\n"have." <\/p>\n","protected":false},"excerpt":{"rendered":" Part of solving the problem is making sure that the solution is available to other people. This is especially important if it took you a long time to find the answer or if you are the expert and you realize … Continue reading