Project Management optimize

Telling clients 'I don't know' is acceptable

Consultants should market themselves to clients as providing the right answers rather than having all the answers. This is why it's beneficial to know how to conduct reasoned research.

Clients usually call in the consultant because they expect us to possess knowledge and experience that they lack. Due to choice-supportive bias, the client may inflate their assessment of how much the consultant actually knows -- which can lead to disappointment if they find out they were wrong. That's just one more reason why consultants need to present themselves honestly, to avoid as much as possible creating these unrealistic expectations.

But how much knowledge of our field should clients reasonably expect us to possess? Technology advances at such a rapid pace these days that unless you're in a dying niche, trying to keep up with even a reasonable subset of new information could be a full-time job. You can be the expert in one narrow field, but in everything else you'll find it difficult to stay moderately well informed. Nevertheless, you can't practice your specialty in a vacuum, whether you're in software development, networking, security, or some other focus. You'll regularly have to know something about all the others, and even within your focus it's impossible to cover all the territory.

Ben Franklin said, "The doorstep to the temple of wisdom is a knowledge of our own ignorance." We can't even begin to deal with the problem until we know what we don't know. When I first started out as a consultant 20 years ago, I had already worked for 12 years in the field, both in programming and in management, and I thought I knew almost everything. I quickly found that expecting yourself to know everything wastes a lot of energy trying to maintain that image by covering your ignorance. The more I learn, the more I realize how little I know and how little I should be expected to know. This isn't an excuse for not educating myself -- it's recognizing that no matter how much I learn, there will always be vast tracts of relevant knowledge that I'll never get around to learning.

Where does that leave our clients? If they don't know it already, we need to educate them that "I don't know" is an acceptable answer -- as long as it's followed by "but I can find out." No matter what subject you studied in college, unless you just graduated you can bet that a fair share of the details you learned are already obsolete. Hopefully, though, they taught you something much more relevant: how to research, and how to reason.

Even the knowledge of how to research is changing. When I was in college, the Internet was not available to us for research. It would be another decade before Tim Berners-Lee invented the web, and Larry and Sergey were in elementary school. Back then, you went to the library and started with the card catalog or the Bibliography of Bibliographies and you ultimately gleaned all your information from dead trees, microfilm, or microfiche. Just finding the sources you needed consumed most of your time. That process has become vastly easier since Google, especially if you know how to use it well. Google even automates to some degree the evaluation of relevance and authority, though you always need to apply your own evaluation as well. The art of appropriating the knowledge you find and applying it to your specific problem, though, hasn't really changed.

You don't want to have to start with Google always, however. For specific fields of inquiry that repeatedly require your research, you want to have reliable resources bookmarked. For example, if I have a question about FreeBSD, I always go to the FreeBSD Handbook first. For Ruby, my first stop is Ruby-doc.org. And despite all its deficiencies, the most comprehensive source for Microsoft information is the MSDN Library. However, if you need to search one of these sites, it's often better to use Google with a "site:" qualifier than to use the site's search engine.

After you've found what you think is the answer, you need to prove it. You don't just stick it into the production server and hope for the best. A good researcher has his or her own set of test systems for doing this sort of work. Virtualization has made that extremely affordable (as in $0), so you really don't have an excuse for not testing your solutions in an isolated environment most of the time. If you find that the project is too tightly coupled to external resources to be able to isolate it, then that probably indicates a design flaw. You should at least be able to stub out those services for testing purposes.

The ability to conduct reasoned research is just as much, if not more, of a benefit as prior knowledge of the subject. The main reason for learning the details of our field turns out to be so that we will do better at researching what we don't know. Background knowledge informs us so we can know what to look for, evaluate the relevance and authority of what we find, and appropriately apply what it tells us. When we market ourselves to clients, we shouldn't present ourselves as having all the answers. It's far more beneficial to have the right questions.

Thanks to Bob Eisenhardt (reisen55) for suggesting this topic.

More IT Consultant resources on TechRepublic

About

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

20 comments
bobp
bobp

Chip is on target with this article. I usually tell clients that any consultant who says he knows everything necessary to fix all computer problems is a liar. I then state that it is impossible to keep up with everything, but that I know enough to know what to look for, to accurately interpret what I find, and to apply it my customer's situation. I also know a couple people at my church who know way more than I do and can point me in the right direction when I need that. Since I got a job in a non-computer related field (other than being a computer user and doing usual maintenance), I am getting even farther behind in my knowledge. I do some computer support work outside that job for a few long term clients. I still use the same searches and checking with my friends at church when necessary to get the job done. Just keeping all the boot CDs and other materials up to date takes time.

gotCmp10c
gotCmp10c

Nice topic. Was hoping to read more about the right questions to ask.

pkesel
pkesel

Your client should always be aware of the assumptions under which you are working. As your engagement starts you should explain the architecture, techniques, patterns, etc. that you anticipate using during the engagement. If you cannot do that you're not prepared to be in the client environment. If you're prepared to do that, then any circumstance in which you find yourself needing to say, "I don't know," you can then explain to them that their need is a departure from the common implementation pattern. Explain that you were prepared to meet their need in a particular fashion based on best practices and common solution patterns, that their need is peculiar, and that you will need to prepare otherwise to meet satisfy that peculiarity. Of course, this all assumes that you are prepared and know what the industry recognized solutions are. This approach maintains your credibility and may give you an opportunity to bring the client back to industry conventions and to a solution path with which you and the client may be more comfortable.

biancaluna
biancaluna

I agree, you do not need to know everything, in fact, you can't. But I have some caveats around this. I believe consultants should have a core skill set and a core set of capabilities and organisations such as SFIA and in Australia, the ACS agree with me on that one. Phew, someone does. There are different consultants, some are very technical, some, like me, operate on a business and system level. I do not need to know technology to the nth degree but I do need to be soaked to the bone in discipline and industry disciplines. I need to be able to recognise patterns, as that is what we do right? Then we need to be able to draw on either our own knowledge or our network or the industry itself to come up with a solution to a client's business problem. That is how I approach my work, even if I implement nuts and bolts level, IT has and will always be, the enabler of business process. You need to be able to recognise frameworks and research what fits into that. I do not know is not something I would say, I would reframe it slightly and to be honest, after 20+ years in teh business I see things quack like a duck, walk like a duck and I can see the duck pattern emerge. Everything old is new again. Recently, I started working for a small consulting company as I wanted some time off the paperwork and pressure treadmill and spend some more time on self development. To my great surprise, I got blank stares from some of the "senior consultants" when I asked for someone with ITIL skills to help me with an assessment. They did not know what it was, had never heard of it. That was the moment when I let rip somewhat - if you sell senior consultancy skills, you better dang well know about service delivery frameworks that are as old as my grandfather. To me, there was no excuse. I have seen this a lot though, some of the consultants I work with don't have a good grasp on the whole animal, they have a very narrow view and forget about anything else. For example, the fluffy consultants who create fantastic magic quadrants and value chain structures and forget that their pie in the sky lives on technology platforms. Or the highly technical consultants who have their head in code and forget the owner level process flows and that IT systems hardly ever replace good business process. So yeah, honesty and integrity is key, continuous improvement and learning but also, understanding that technologies change very rapidly but some of the underlying disciplines and frameworks are pretty similar and do not change that much. Silo thinking versus system and strategic thinking. It comes back to your core competencies as a consultant.

bergenfx
bergenfx

Huckleberry Finn says in from Life on the Mississippi, "I was gratified to answer so promptly. I said I didn't know."

reisen55
reisen55

Whenever we go into a book store or computer super store, like MicroCenter, and glance at all of those huge 1,000 plus page books, it is useful to keep in mind that we truly do not know a fraction of the detailed data with which we work, and as independent consultants we work with a wide variety of networks, all totally different save for a FEW common traits. If you tell a customer " I do not know that one YET" then it indicates you ARE going hunting to dig out the answer. And when you find the answer, DOCUMENT IT and show the client that you did that too. Heaven forbid you solve an issue and six months later to have to solve it somewhere else and...egad, that solution is a lost, floating brain cell.

JohnMcGrew
JohnMcGrew

..."I don't know, but I know someone who does" or "I don't know, but I will find out." The trick is to be confident, even when you honestly don't have the answer at the tip of your tounge. That confidence reassures the client that even if you don't have the answer on the spot, that you still have their best interests as a priority, and that you will find the correct answer one way or another. Few people expect everyone to know everything about everything. But they'll more than likely respect your integrity in being honest, and your enthusiasm for getting the right answer. When I started out in IT, it was nearly possible to know everything about everything. There were only so many platforms, OSs, languages, and applications to know about. And I prided myself about knowing something about all of it. But by the latter half of the '80s with the explosion of IT, it was no longer possible to even know even very much about "everything", and impossible to know enough about much of it. You had to prepare to be humble.

SecurityFrst
SecurityFrst

As a security compliance consultant, I am not sure if I agree with using the statement " I don't Know. I am selling myself as an expert in the field of government security clearance processing and telling a client " I dont' know, might not go over to well. Security First & Associates www.securityfirstassociates.com Play it forward and Tell someone about Security First & Associates

donstrayer
donstrayer

A good consultant needs a network of people who can provide answers or point to resources where the answers can be learned. A wise consultant will utilize this network to recommend or sub-contract someone who can better serve the client. It's okay to say you don't know but you'll find out. But if it's outside your area of expertise it's better to say, "I can refer you to someone who can help you with that."

Tony Hopkinson
Tony Hopkinson

But I can find out. and the first thing we need to find out is whether what I think I know, and what you think I need to know are in fact the same animal. It's the classic when talking to a client we both know something about football, but I know soccer... More errors come from assuming you know and not making sure, than not knowing. Know it alls know very little, only a know it all would emply another one. Feel free to rephrase that when talking to a client. :p

colleyryan
colleyryan

This article is not dissimilar to many of my posts about customer service. I disagree somewhat as I just don't like to hear the words "I don't know". It immediately triggers a defensive reaction in your client/user that I feel is unwarranted. I would leave that part out and go with a "I can help you research that issue" type response that doesn't immediately trigger a defensive response. I did an article a bit ago about never using the word "Can't" with a client/vendor a long these same lines. http://itisrad.com/2011/08/things-support-staff-should-never-say-to-their-users-%E2%80%94-can%E2%80%99t/

gechurch
gechurch

Your two stock answers pretty much cover every situation. It helps a lot if you already have a good repoire with a customer. I think saying "I don't know" is only a problem if you do it too often.

gechurch
gechurch

The field of "government security clearance processing" sounds very specific to me. If you publicise yourself as an expert in this field and you get a related question then yeah - they'd reasonably expect you to know the answer. If, however, they asked you why their PC crashes every time it comes out of hibernation then it'd be completely understandable for you not to know.

metalcoholik
metalcoholik

In an IT Help Desk team you should have software developers, network specialists, computer engineers to printers specialists and when someone don't know something then consultant should refer client to the right person. Not to mention that the relationship of the Help Desk and the Infracstructure team should be excellent.

gechurch
gechurch

When I was younger I never said "I don't know", but now I am older and more confident in my abilities and I say it quite frequently. I very occassionally have a client look surprised, but I can't remember a single time a client has been defensive.

tbmay
tbmay

I've heard the customer service spill before. I can think of no better service to my customers than honesty. I'm with Chip on this. Obviously, one needs to choose one's words carefully; however, one also needs to move on if someone is wasting their time. (BTW...I have, and still do use your "research" wording.) I hate to say it, but a huge percentage of calls I've taken weren't from serious requests. A typical example: "Customer": Can you make my doo-hickey do action A. Me: Almost certainly. "Customer": How do I do that? Me: I'll have to research it and get you an estimate. Customer: Oh. I was hoping you could just tell me how to do it on the phone. I don't want to spend any money. At this point, it's pretty obvious the "customer" is just trying to get free help. I have had them go on and argue with me, and try to fish more out of me, and not a single one actually payed for anything when the conversation started like the one above. A quick "can't" would have ended it a lot earlier. Maybe it's the difference between owning a business, and working for one, that makes Chip and I agree here. In an organizational environment, it's not much different. The end users consistently call for things that are against the organizations policy, or to ask for features that require much more work than they think. ANYTHING can be done with enough time and money. It's typically not up to either the consultant, or the internal IT guy, whether those resources are going to be allocated. I understand the cs perspective; however, I.T. can not always follow those principles because it's too easy for people to take advantage of them. If a customer is willing to pay for the time...super. But they have to make that judgement.

colleyryan
colleyryan

I hear your point but feel you can never have greater success than a happy customer. I want my support staff to go out of their way to help users in any way possible. If that means they need to spend extra time and effort to help a user with a problem they should have figured out on their own, I have no issue with that. Also, if you continue to have users question a policy, it is time to think about changing your policy. The reward that my team/company will get back from that one happy customer will more than make up for any extra time spent assisting. And my support staff will find new meaning and value in their jobs as they get to have freedom, be creative and flexible instead of attempting to meet some criteria of closing tickets as quickly as possible. I don't feel like a user ever wastes any of my staffs time. We are there to help, so that is what we will do no matter how trivial we feel the call may be. Now, if you support cars and a user calls you about bicycles, that is a different story... I talked more about this in another blog post too. http://itisrad.com/2011/07/5-support-tips-to-make-your-users-not-hate-you/

tbmay
tbmay

They never hired me for that though. In fact, in my quarter century career I've found most organizational leadership is not even slightly interested in how a sysadmin, IT Manager, support tech, or developer thinks the company should be run. And very often your own paycheck depends on you remembering who the boss is. We're getting off topic. Sorry Chip.

colleyryan
colleyryan

It's too bad to hear someone that has not experienced a truly passonate and engaged support team. A job in support is exactly that, a job, but it should be approached with eagerness to succeed and advance. I hope you get to experience a better type of support team at some point in your career because it will change your outlook and most importantly provide your users an experience that will make them true champions of your team/product. Polices do have a place, but they get changed by the people that fight for change with creative and passionate solutions, not by those that say it is someone else's decision and go about their, as you put it, work. Here is a great example of what it means to go above and beyond for your users. http://shankman.com/the-best-customer-service-story-ever-told-starring-mortons-steakhouse/

tbmay
tbmay

Don't want to say "head in the clouds" but it did cross my mind. ;) "Creativity" and "Passion" are the latest organizational buzzwords. I've lived through a lot of them. Happy customers are great. If I gave away everything I had, I'd have a lot of happy customers, and a real unhappy me. If you have the pull to change policies because users don't like them, go for it. It's for sure I've had to work within, and enforce, policies I didn't particularly agree with. They call it work for a reason. Of course, quite a few of those unpopular policies exist for good reason.