Discussion on:

Six tips for solving tough client problems

It's the new ones where this comes up. I'm honest with them. I'm a unix specialist but I support many Windows desktops. I will probably be able to get you a solution or solve your problems, but my rates are the same whether I'm doing something generally routine...aka malware removal...or I'm doing something I haven't specifically done before.

I might discount the bill a bit if I think this is something I'll do again and I'll benefit from the research and digging; however, the client knows they're hiring me to solve a problem I may not have seen before. In fact, how do you get around solving problems you haven't seen before in IT?

Nah. I'm a problem solver...not a "know-it-all"...if that's not what they want, they need to hire someone else. There's no shortage of people who will tell them the lies the want to hear.

I often use Google as the first plan of attack. It's fast and it's free. But if I don't find a good lead on the answer pretty quickly, then I look at more time-consuming alternatives.

even if you are a sole entity. You know how long a project should take and you probably know at what time you will reach a certain stage. If you are getting behind schedule, escalate to the owner, the vendor, a colleague, someone. The longer you take, the more frustrated you become and the less you can think straight. Get help.

Keep a log as you work including every action taken, whether it was right or wrong. If the action was not the right one, learned from it. What did the action do, how did you recover from it, etc.

It isn't just a case of knowing what to do, it's also a case of knowing what not to do - and WHY not to do it.

Use a digital recorder from the oment you get onsite or start a project. If you work to a script or procedure, you only need record deviations from the procedure.

I did this for twenty years in corporate BCP/DRP and continue to do so a consultant. It makes life so much easier when billing the client and creates a record for your database.

Greetings;

Nice article. I would like to add something please. A good consultant must be able to tell the client at a minimum what the problem is, even if they do not know how to fix it. However as you say, at least knowing what the problem is, someone somewhere out there will either have had this problem before, OR will be the one that has to physically fix it. All it takes is some dedicated research and a lot of reading.

This makes the skills of isolating and identifying a problem a top priority in the skill box. Without methodical and thorough analysis of each unique situation, a solution would be impossible to find except for dumb luck.

In a wrap, I would like to add a seventh item to your list: Isolate/Identify. Even if its placing it down to a particular application, module or card. At least you can save face and possibly earn competency points with your client by being able to tell them what the problem is.

Between your honesty and the problems identity, a client is more prone to keep you heading up the project to its conclusion instead of bringing in the replacements.

6th step should be 1st

Document everything: troubleshoot steps, results and resolution for future references.