I can't count the number of times I've gotten calls from clients that begin with the question, “Do you know how to do…?” My customers are wondering if I have some specific skill that may solve their current problem. Whether the answer is yes or no, I shouldn't answer that question. Here's why.
Self-diagnosis and self-treatment
There's a saying among lawyers that “a man who is his own attorney has a fool for a client.” The medical profession has similar (and even less flattering) ways of referring to self-diagnosis or self-treatment and how it's ill-advised.
Our IT customers do it every day. They determine what they need without seeking a professional’s opinion. If they can't get to the Internet, for example, they may pick up the phone and ask, “Can you help us with our Check Point firewall?” Of course, it's certainly possible that the problem is with the firewall, but it's equally possible that there's some other cause.
I often get calls asking for a specific skill set that's not appropriate for resolving the problem. I've been asked to come in and be prepared to use my experience in troubleshooting Microsoft Commerce Server; unfortunately, the problems were related to performance and reliability, not Microsoft Commerce Server. They were problems with the underlying network infrastructure that, when resolved, caused the problems in Commerce Server to disappear.
The first step in finding the right solution for a customer is to understand all of the symptoms that the customer is experiencing and how the environment functions.
In the IT industry, we often work with issues that are not the root problem. If we're asked to take a look at a software bug that's causing undesirable results, we don't ask why the software is being used in the first place.
I was once called in to fix an Access report. The report was generating numbers that didn't match those found in the mainframe system reports. It looked like a problem of extraneous data being included in the Access report. However, the real question was why there was a redundancy; the Access and mainframe reports reflected the same data. The answer was that the customer wanted to be able to export the data to Excel.
There are tools designed to scrape mainframe reports and put the data in Excel for further analysis. These tools would have been a better solution and would have negated the need for report generation in Access.
However, on further exploration, I learned that Excel was only partially effective at addressing the customer's need; the customer wanted to look at the data in a format that was different from that which was generated by the mainframe. Instead of breaking it down by territory by salesperson, the customer wanted to be able to look at the data by salesperson. It turns out that the goal was to put together a ranking of salespeople to create competition within the sales force. (I don't necessarily advocate this for your organization—or theirs.)
This story illustrates how important it is to delve into the problem, see how it affects the organization, and see who is involved, thereby gaining a better understanding of the problem. By following this formula, you'll be able to offer customers a better solution to their root problem. By addressing the root problem(s), you'll do away with the symptoms that manifest themselves throughout the system.
Failure to communicate
One of the biggest challenges in trying to determine the problem is communication. Unfortunately, that's largely the fault of the consultant. Many consultants don't take enough time to listen to what the customer is saying. One sentence into a description of the problem, and we're already trying to solve it—without the whole picture. We want to solve problems so quickly that we forget we probably don't even understand what's wrong.
So as not to lay the blame completely on the consultant, at times the customers aren't taking the time to explain the problem in detail; they may be unable or unwilling to do so before you address their most immediate need. In cases like this, you should consider first resolving the customer’s perceived problem and then, after it's resolved, seek out more information about how the solution is used. Even if you can't recover the time you spent resolving the problem—without necessarily getting to the root problem—you can file the extra information away for the next time you receive a call for a similar situation.
One word of caution about solving customer issues: We all have biases. We tend to gravitate toward solutions that we know and understand—solutions that are comfortable for us. A consultant who is intimately familiar with the Cisco PIX-based firewall will recommend it over a Check Point solution. I will propose a Microsoft solution over a Linux one. Of course, the biases we have may be right or wrong, important or trivial.
There's little that we can do to completely eliminate all of our biases. However, we can be aware that we have biases and bear them in mind when trying to solve a customer’s problem. For instance, I have both Linux and Windows systems in my test network. I still know the Windows servers better, but I do know enough about Linux to know when it may be the best choice. I'll still recommend a Windows server over Linux in many environments, but at least I'm trying to make sure that this is based on customers’ needs and not personal bias.
Undue bias—bias that is most certainly harmful—can occur for two reasons. The first reason is a lack of breadth in technological knowledge. You may know one, and only one, technology. It follows that you can't solve a problem with anything but the technology you know. The second reason is that you've become too wrapped up in the company. If a company starts giving you sizable gifts, you may risk developing an undue bias. A stress ball may not unduly influence you to solve a customer’s problem with a particular solution. However, getting a free trip to the Bahamas, a new computer, or some other major gift may unduly influence you to choose one solution over another.
Several factors can get in the way of ferreting out the real problem a customer is having. You have to get down to the bottom of the situation before you can diagnose the problem and recommend a solution.