M i X ,

As obvious as it sounds, nothing does more to prevent problems than knowing the subject you are discussing. The more you know, and the more insight you can provide based on your own experience, the less likelihood that you will misspeak or state an incorrect position. Even more important, knowing the material will give you confidence, and that confidence will show in the tone of your voice and in your body language. Do you know how to reduce the chances of being burned while working with a particular product? Don’t be afraid to share that knowledge.

This point relates to the first one. Not only must you know what you’re talking about, you also must anticipate the most likely questions you will get and prepare answers. In other words, you must do more than simply repeat information. You must be able to analyze it and show how it relates to the objectives and concerns of your listeners. If you are talking about a software implementation, what are the most likely areas where a problem will occur? What combination of hardware and software will be the most difficult to troubleshoot? If you have these answers, your listeners will appreciate your information more.

No matter how much you prepare, you might get a question for which you don’t know the answer. In such a case, resist the urge to guess. You might be right, but the chances are greater that you will be wrong, and an initial wrong answer followed by a correction will be worse than stating that you do not know the answer. Of course, if the question involves a complicated situation, people will be more understanding of your inability to answer than if you lack an answer to a basic question.

At the same time, try to answer what you can. If the question involves the interaction of multiple software products, for example, answer what you can about the individual products, then simply state that explaining the way they interact would take additional analysis.

Even though you might not know the answer, try to avoid saying so. Instead, try the old standard “That’s a good question.” Then explain the issues involved. If the answer will vary depending on different sets of circumstances or system configurations, you could talk about one specific circumstance or configuration and explain that one in detail. Then caution your listener that the results might be different in other circumstances.

Let’s say that you are a level one help desk analyst and you are escalating an issue to level two or beyond. When discussing the issue with the next analyst, make it clear what initial troubleshooting steps you already took and that they failed to work. If you don’t, that level two person might think that you neglected those steps and will think that you are incompetent. Better to be in front of the situation and explain what you already did than to have to react to the other analyst’s questions.

If you are unclear about something you heard, incorporate into your question the possible alternatives. The person who is explaining might not be aware of those other alternatives and mistakenly believe your question is stupid.

For instance, suppose someone is explaining that a supplier is based in Arlington, and that person is aware of only the Arlington in Virginia. If you were to ask, “Do you mean Arlington, VA?” that person, and possibly others, might consider it a stupid question. If you instead ask, “Do you mean Arlington, Virginia, Texas, or Massachusetts?” you subtly make it clear that your question is not stupid at all. In the same way, rather than asking, “Do we need PowerPoint to run the presentation?” consider instead “Do we really need PowerPoint or just the viewer?”

Any answer you give will depend on specific facts and circumstances. Therefore, be clear about them, because in other cases the answer might be different.

For example, let’s say that you are vendor management person for your IT organization, and an issue has arisen with a vendor. Suppose someone in the organization asks you about the timeframe your company has in which to sue a vendor, and you know the answer. In giving it, you probably would want to qualify your answer to say, “In state X, the time limit to sue is y years, but in other states it might be different.”

As soon as you say something “definitely” will or won’t happen, events will prove you wrong. As a result, you will end up with the proverbial egg on your face. A better alternative to “definitely will happen” is a response such as, “It might not happen, but the chances of that are really small.” An alternative to “definitely won’t happen,” might be, “It’s possible but extremely unlikely.”

In the immortal movie Casablanca, Captain Renault declared that he was, “shocked, shocked I tell you” to find that gambling was occurring at Rick’s Café. You can use this dialog yourself to avoid looking foolish.

While the previous answers of “possible but unlikely” are better than the “definitely” or “definitely not,” they still carry an element of uncertainty. For that reason, my own preference is to answer so that the answer does have certainty. However, the certainty is not about the result, but about my reaction if the result is different. It also lets people know that you’re already aware that you might get egg on your face, so if you’re wrong, you don’t look quite as foolish.

So, for example, in response to the question “Does this Microsoft product have security issues?” I might answer, “If it doesn’t, I would be shocked.” If I am positive that a project will be late, I might say, “If this project comes in on time, I will be shocked.”

If you are using data to support your points, have that data with you in writing or least have a citation to it. That way, you are not seen as making up numbers. Furthermore, people who disagree with you also have to disagree with data that came from someone other than you. Having the data and the citations gives you added credibility.