"Do you have any clue about what you're asking us to do?" is not a question you would want to ask your customer without some very careful thought. Actually, you wouldn't want to ask it even after LOTS of careful thought. Trust me, it never gets a good response. Besides, there are more subtle (and job-preserving) ways of getting a grasp on your assignment.

Many times we Tech Writers find ourselves being assigned to do a job without being given clear and definitive direction. In the realm of technical documentation, this happens more frequently than we would like to acknowledge or may realize. Alas, the topic of today's newsletter is about one possible way to get the clear direction that you so richly deserve. And, of course, that you will need to deliver what they expect.

The first step in doing a good job, ANY good job, is to possess an understanding of the task at hand, or, in engineering terms, understand the problem to be solved. It's common sense that we cannot fully understand our task until we have been given clear direction or guidance. And getting the guidance and understanding we need might hinge upon our own ability to ASK THE RIGHT QUESTIONS.

In previous newsletters, we've discussed some of the perils of not asking questions before beginning your task. Here we're going to take a more advanced look at structuring those questions using some simple rules of thumb. You are correct in thinking that this is not a complicated process, but it does deserve some honest regard for those of us wishing to advance.

Before we delve into this enthralling matter, let's take a moment to review the points we brought up in the DocuDr's first newsletter of this series, "Understand The Problem: Know What The Customer Wants."

Taking a best guess at what the customer wants is often not the best approach to accomplishing a documentation task. Whatever your reasons for not asking questions: shyness, fear, arrogance - get over them. Great minds accomplish great things by asking great questions.

All you need to worry about is delivering the type of document that will have your customer smiling from ear-to-ear and requesting YOU by name for the next project. We don't need to go into the "bad" things that can happen should your document not meet the customer's expectations, but we'll list them for convenience: (1) the document needs to be re-written, (2) you/your company is viewed as non-responsive, or (3) your reputation as the tech writer is obliterated (or at least heavily tarnished). Don't be the "Fall Guy." Look what it did for Lee Majors.

It is somewhat common in our profession to be ignored by our customers, corporate managers, and system developers that don't wish to get mired down with the details of our developing document. But they will all agree that it is OUR problem. Don't let them intimidate you. If they have information that is key to your document's success and acceptance, then they should set aside some interrogation time for your questions.

The Solution:

So, they've agreed to give you some time. Great! Now what? You've got a million questions and now must pare them down to fit in the 20 minutes they've offered you. Right? No problem!

There are some basic steps that you can follow for developing your now-critical and necessarily concise questions for clarification. Remember you are working with engineers and other technical people, so let's use some of the same engineering principles they use.

It is clearly a case of common sense when asking a question - the answer you receive is based on the question you ask. Before we wrap up, let's look at a simple example where a very broad requirement is presented in the statement of work (SOW) to develop a user manual.

REQUIREMENT: A User Manual shall be developed for System X to provide users with operation procedures. The User Manual shall include a troubleshooting Section describing all error messages.

Now following our four simple steps, let's assemble some good relevant questions addressing what we know, what we think we know, and what we don't know. Perhaps you can apply your own experience or your knowledge of your customer to improve upon these examples.

As you can see, each one of these questions makes it apparent that there is more than one possible design for the document. But in each case, the recipient of the question is forced to think about possible variations of the outcome and consider new aspects of the document.

But it is terribly easy to make assumptions about what our customers may have in mind. We must always be careful not to apply our own understandings and experiences to answer questions that should only be answered by those in responsible for the project. Misinterpreting a single idea or making an assumption as to what is being requested can be very costly and time-consuming. The success of your task depends just as heavily as YOU being responsive. Effective technical documentation is derived from knowing your customer and understanding your assignment. So, don't be shy. Asking the right questions now will save you from having to make excuses later.