Technical Report Writing

Your dual role as technical writer requires that you be able to formulate two kinds of problem statements. You need first to define the technical problem to be solved and outline your proposed solution to it. Of equal importance, the rhetorical purposes of your report must be clear. Is the report intended merely to describe some factual situation or, as is more likely, is it intended to influence someone to do something? Both kinds of purposes are discussed in this Chapter and some good and bad examples are offered.

B. Technical Problem Statements

In your role as technical problem solver, your first task will usually be to define the problem to be solved. It has been said that a clear, unambiguous problem statement is three quarters of the solution. Technical reports are written to address both technical and organizational problems. Early in the report you must let your reader know what those problems are.

The Organizational or Client problem is the central focus of your report. How you define and express it determines in large part your ability to solve it. It is also important to let your reader know why the problem matters. In other words, why should the reader care about this problem? What are the consequences of failing to address it? And how do you propose to go about solving it?

Often the simplest way to begin is with the lowly list. On a piece of paper begin listing the problems to be solved as you understand them. Don't be too critical at this stage of the process. Your aim here is to simply get these ideas down on paper so you can refine them later. List all the problems you think might need to be addressed in your report but don't worry about how, or even if, you can solve them.

Once you're out of ideas and satisfied that you've identified most of the problems, begin editing them. See if you can eliminate some first. Are some of the things you've listed unimportant? Are some beyond what you were originally asked to do? Are some so difficult that you can't hope to solve them within the budget and time constraints of this project? If so, eliminate those and see what you're left with.

Now prioritize the remaining problems putting the most important first and secondary or minor problems last. The last, and most difficult step comes now. Try to state each problem as precisely, but as generally as you can. It is important that you state the problem in the broadest possible terms at this early stage in the process so that you don't cut yourself off from possible solutions or fail to investigate promising, though unlikely, alternatives.

As an aid in doing this, I have included the Tip & Trick at the end of this chapter. Very few technical/engineering problems, no matter how complicated, cannot be analyzed using the three part problem statement presented below.

You, as technical writer, have a second equally, important job in defining the rhetorical purpose of your report, and each of its parts.

Ask your self first, Why Write This Report? The reasons will usually fall into the following general categories:

From these, select the one that best describes the most important reason you are writing. That will be the basis of your rhetorical problem statement which should appear early in your report and in any cover document you use to transmit it. Remember that your reader wants to know first, Why Should I take My Valuable Time to Read this Report? Unless you give him/her an acceptable answer your report will not be read, period.

Unless, and until, you have defined both the technical problems to be solved and the rhetorical reason you are writing the report you can't answer such questions as; what am I doing, why am I doing this, how am I going to do this, and how will I convince others that what I have done is worthwhile ?

Chapter 1 * Chapter 2 * Chapter 4 * Chapter 5 * Chapter 6 * Chapter 7 * Chapter 8 * Chapter 9 * Chapter 10