7.4 Technical Reports

• • • INTRODUCTION:  The introduction should clearly indicate the document’s purpose. Your introduction should discuss the “unsatisfactory situation” that has given rise to this report (in other words, the reason(s) for the report), and the requirements that must be met. Your reader may also need some background. Finally, provide an overview of the contents of the report. The following section provides additional information on writing report introductions.

• • • TECHNICAL BACKGROUND:  Some recommendation or feasibility reports may require technical discussion in order to make the rest of the report meaningful. The dilemma with this kind of information is whether to put it in a section of its own or to fit it into the comparison sections where it is relevant. For example, a discussion of power and speed of tablet computers is going to necessitate some discussion of RAM, megahertz, and processors. Should you put that in a section that compares the tablets according to power and speed? Should you keep the comparison neat and clean, limited strictly to the comparison and the conclusion? Maybe all the technical background can be pitched in its own section—either toward the front of the report or in an appendix.

• • • REQUIREMENTS AND CRITERIA:  A critical part of feasibility and recommendation reports is the discussion of the requirements (objectives and constraints) you’ll use to reach the final decision or recommendation. Here are some examples:

• • • • If you’re trying to recommend a tablet computer for use by employees, your requirements are likely to involve size, cost, hard-disk storage, display quality, durability, and battery function.
      • If you’re looking into the feasibility of providing every student at Linn-Benton Community College with a free transportation pass, you’d need define the basic requirements of such a program—what it would be expected to accomplish, problems that it would have to avoid, how much it would cost, and so on.
      • If you’re evaluating the recent implementation of a public transit system in your area, you’d need to know what was originally expected of the program and then compare (see “Comparative Analysis” below) its actual results to those requirements.

Requirements can be defined in several ways:

Numerical Values:  many requirements are stated as maximum or minimum numerical values. For example, there may be a cost requirement—the tablet should cost no more than $900.

Yes/No Values:  some requirements are simply a yes-no question. Does the tablet come equipped with Bluetooth? Is the car equipped with voice recognition?

Ratings Values:  in some cases, key considerations cannot be handled either with numerical values or yes/no values. For example, your organization might want a tablet that has an ease-of-use rating of at least “good” by some nationally accepted ratings group. Or you may have to assign ratings yourself.

The requirements section should also discuss how important the individual requirements are in relation to each other. Picture the typical situation where no one option is best in all categories of comparison. One option is cheaper; another has more functions; one has better ease-of-use ratings; another is known to be more durable. Set up your requirements so that they dictate a “winner” from a situation where there is no obvious winner.

• • • DISCUSSION OF SOLUTION OPTIONS:  In certain kinds of feasibility or recommendation reports, you’ll need to explain how you narrowed the field of choices down to the ones your report focuses on. Often, this follows right after the discussion of the requirements. Your basic requirements may well narrow the field down for you. But there may be other considerations that disqualify other options—explain these as well.

Additionally, you may need to provide brief technical descriptions of the options themselves. In this description section, you provide a general discussion of the options so that readers will know something about them. The discussion at this stage is not comparative. It’s just a general orientation to the options. In the tablets example, you might want to give some brief, general specifications on each model about to be compared (see below).

• • • COMPARATIVE ANALYSIS: One of the most important parts of a feasibility or recommendation report is the comparison of the options. Remember that you include this section so that readers can follow the logic of your analysis and come up with different conclusions if they desire. This comparison can be structured using a “block” (whole-to-whole) approach, or an “alternating” (point-by-point) approach.

The comparative section should end with a conclusion that sums up the relative strengths and weaknesses of each option and indicates which option is the best choice in that particular category of comparison. Of course, it won’t always be easy to state a clear winner—you may have to qualify the conclusions in various ways, providing multiple conclusions for different conditions. *NOTE: If you were writing an evaluative report, you wouldn’t be comparing options so much as you’d be comparing the thing being evaluated against the requirements placed upon it and/or the expectations people had of it. For example, if you were evaluating your town’s new public transit system, you might compare what the initiative’s original expectations were with how effectively it has met those expectations.

• • • SUMMARY TABLE: After the individual comparisons, include a summary table that summarizes the conclusions from the comparative analysis section. Some readers are more likely to pay attention to details in a table (like the one above) than in paragraphs; however, you still have to write up a clear summary paragraph of your findings.

• • • CONCLUSIONS: the conclusions section of a feasibility or recommendation report ties together all of the conclusions you have already reached in each section. In other words, in this section, you restate the individual conclusions. For example, you might note which model had the best price, which had the best battery function, which was most user-friendly, and so on. You could also give a summary of the relative strengths and weakness of each option based on how well they meet the criteria.

The conclusions section must untangle all the conflicting conclusions and somehow reach the final conclusion, which is the one that states the best choice. Thus, the conclusion section first lists the primary conclusions—the simple, single-category ones. Then it must state secondary conclusions—the ones that balance conflicting primary conclusions. For example, if one tablet is the least inexpensive but has poor battery function, but another is the most expensive but has good battery function, which do you choose and why? The secondary conclusion would state the answer to this dilemma.

• • • RECOMMENDATIONS: the final section states recommendations and directly address the problem outlined in the introduction. These may at times seem repetitive, but remember that some readers may skip right to the recommendation section. Also, there will be some cases where there may be a best choice but you wouldn’t want to recommend it. Early in their history, laptop computers were heavy and unreliable—there may have been one model that was better than the rest, but even it was not worth having. You may want to recommend further research, a pilot project, or a re-design of one of the options discussed.

The recommendation section should outline what further work needs to be done, based solidly on the information presented previously in the report and responding directly to the needs outlined in the beginning. In some cases, you may need to recommend several ranked options based on different possibilities.

For more information on what technical reports are and how to write them, watch “Technical Report Meaning and Explanation” from The Audiopedia:

https://www.youtube.com/watch?v=LzvhBAQeWOE

Additional Resources

• “How to Write A Technical Paper” by Michael Ernst, University of Washington

• “Report Design,” from Online Technical Writing

• “Engineering Report Guidelines” (PDF example of a style guide for engineers from Technical Writing Essentials )

"Long Reports." Technical Writing Essentials. [License: CC BY 4.0]
"What is a Technical Report?" Uploaded by The Audiopedia,  GCFLearnFree.org, 21 Mar. 2018, Youtube.com.