Online Technical Writing: Recommendation and Feasibility Reports

In this chapter, you study a loosely defined group of report types that provide a studied opinion or recommendation, and then you either write one of your own or format and finish one from text that your instructor makes available to you.

Be sure to check out the example feasibility reports available with this chapter:

Example 1: Sport Utility Vehicles	Frames	Nonframes	Plain
Example 2: Laptop Computers	Frames	Nonframes	Plain
Example 3: Fire Ant Control	Frames	Nonframes	Plain
Example 4: Blood Glucose Monitoring Systems	Frames	Nonframes	Plain
Example 5: Uninterruptible Power Supply (UPS) Systems	Frames	Nonframes	Plain
Example 6: First Telescope Purchase	Frames	Nonframes	Plain
Example 7: Voice Recognition Software	Frames	Nonframes	Plain

There is a loosely defined category of reports that is very important in technical writing. These reports are variously called feasibility reports, recommendation reports, evaluation reports, assessment reports, and who knows what else. They all do roughly the same thing—provide carefully studied opinions and, sometimes, recommendations. There are some subtle differences among some these types, but there are absolutely no universally agreed-upon names for them:

• Feasibility report: This type studies a situation (for example, a problem or opportunity) and a plan for doing something about it and then determines whether that plan is "feasible"—which means determining whether it technologically possible and whether it is practical (in terms of current technology, economics, social needs, and so on). The feasibility report answers the question "Should we implement Plan X?" by stating "yes," "no," but more often "maybe." Not only does it give a recommendation, it also provides the data and the reasoning behind that recommendation.
• Recommendation report: This type starts from a stated need, a selection of choices, or both and then recommends one, some, or none. For example, a company might be looking at grammar-checking software and want a recommendation on which product is the best. As the report writer on this project, you could study the market for this type of application and recommend one particular product, a couple of products (differing perhaps in their strengths and their weaknesses), or none (maybe none of them are any good). The recommendation report answers the question "Which option should we choose?" (or in some cases "Which are the best options?) by recommending Product B, or maybe both Products B and C, or none of the products.
• Evaluation report: This type provides an opinion or judgment rather than a yes-no-maybe answer or a recommendation. It provides a studied opinion on the value or worth of something. For example, for over a year the city of Austin had free bus transportation in an attempt to increase ridership and reduce automobile traffic. Did it work? Was it worthwhile?—These are questions an evaluation report would attempt to answer. This type of report compares a thing to a set of requirements (or criteria) and determines how well it meets those requirements. (And of course there may be a recommendation—continue the project, scrap it, change it, or other possibilities.)

As you can see, these distinctions are rather fine; and they overlap. In real-world writing, these types often combine—you might see elements of the recommendation report combine with the feasibility report, for example. Of course, the writers of these reports don't care which type they are writing—and well they shouldn't! They're trying to get a job done.

Whatever shade of feasibility or recommendation report you write, whatever name people call it—most of the sections and the organization of those sections are roughly the same. Now remember! Your specific writing project may not require all of these sections, nor in the order shown here—plus you may need other sections not mentioned here.

The structural principle fundamental to this type of report is this: you provide not only your recommendation, choice, or judgment, but also the data and the conclusions leading up to it. That way, readers can check your findings, your logic, and your conclusions and come up with a completely different view. But, more likely, they will be convinced by all your careful research and documentation.

Introduction. In the introduction, indicate that the document that follows is a feasibility report (or whatever it is called). Instead of calling the report by name (which might not mean anything to most readers), you can indicate its purpose. Also, provide an overview of the contents of the report.

For some feasibility reports, you'll also be able to discuss the situation and the requirements in the introductions. If there is little to say about them, you can merge them with the introduction, or make the introduction two paragraphs long.

Technical Background. Some feasibility reports may require some technical discussion in order to make the rest of the report meaningful to readers. 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 laptop computers is going to necessitate some discussion of RAM, megahertz, and processors. Should you put that in a section that compares the laptops 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.

Schematic view of recommendation and feasibility reports. Remember that this is a typical or common model for the contents and organization—many others are possible.

Schematic view of recommendation and feasibility reports—continued. Remember also that these sections need not all be included; they can be combined; and they can appear in varying orders.

Background on the Situation. For many feasibility reports, you'll need to discuss the problem, need, or opportunity that has brought about this report. If there is little that needs to be said about it, this information can go in the introduction.

Requirements and Criteria. A critical part of feasibility and recommendation reports is the discussion of the requirements you'll use to reach the final decision or recommendation. If you're trying to recommend a laptop computer for use by employees, there are likely to be requirements concerning size, cost, hard-disk storage, display quality, durability, and battery function. If you're looking into the feasibility of providing every ACC student with an ID on the ACC computer network, 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, and so on. If you're evaluating the recent program of free bus transporation in Austin, you'd need to know what was expected of the program and then compare its actual results to those requirements.

Requirements can be defined in several basic ways:

• Numerical values: Many requirements are stated as maximum or minimum numerical values. For example, there may be a cost requirement—the laptop should cost no more than $900.
• Yes/no values: Some requirements are simply a yes-no question. Does the laptop come equipped with a modem? Is the car equipped with air conditioning?
• Ratings values: In some cases, key considerations cannot be handled either with numerical values or yes/no values. For example, we might want a laptop that has an ease-of-use rating of at least "good" by some nationally accepted ratings group. Or we may have to assign a rating ourselves.

The term "requirements" is used here instead of "criteria." A certain amount of ambiguity hangs around this word; plus most people are not sure whether it is singular or plural. (Technically, it is plural; "criterion" is singular, although "criteria" is commonly used for both the singular and plural. Try using "criterion" in public—you'll get weird looks. "Criterias" is not a word and should never be used.)

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. Devise a method by which you can pick a "winner" from situation where there is no clear winner.

Discussion of the 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 descriptions of the options themselves. Don't get this mixed up with the comparison that comes up in the next section. 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 laptops example, you might want to give some brief, general specifications on each model about to be compared.

Category-by-Category Comparisons. 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 check your thinking and come up with different conclusions if they desire. This should be handled category by category, rather than option by option. If you were comparing laptops, you'd have a section that compared them on cost, another section that compared them on battery function, and so on. You wouldn't have a section that discussed everything about option A, another that discussed everything about option B, and so on. That would not be effective at all, because the comparisons must still be made somewhere. (See below for a schematic illustration of these two approaches to comparisons.)

Each of these comparative sections should end with a conclusion that states 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.

If you were doing an evaluation report, you obviously wouldn't be comparing options. Instead, you'd be comparing the thing being evaluated against the requirements placed upon it, the expectations people had of it. For example, Capital Metro had a program of more than a year of free bus transportation—what was expected of that program? did the program meet those expectations?

Schematic view of the whole-to-whole and the part-by-part approaches to organizing a comparison. Unless you have a very unusual topic, use the part-by-part approach.

Conclusions. The conclusions section of a feasibility or recommendation report is in part a summary or restatement of the conclusions you have already reached in the comparison sections. In this section, you restate the individual conclusions, for example, which model had the best price, which had the best battery function, and so on.

But this section has to go further. It must untangle all the conflicting conclusions and somehow reach the final conclusion, which is the one that states which is the best choice. Thus, the conclusion section first lists the primary conclusions—the simple, single-category ones. But then it must state secondary conclusions—the ones that balance conflicting primary conclusions. For example, if one laptop is very inexpensive and has poor battery function, but another is rather expensive but has good or even excellent battery function, which do you choose, and why? The secondary conclusion would state the answer to this dilemma.

And of course as already mentioned, the conclusions section ends with the final conclusion—the one that states which option is the best choice.

Recommendation or Final Opinion. The final section of feasibility and recommendation reports states the recommendation. You'd think that that ought to be obvious by now. Ordinarily it is, but remember that some readers may skip right to the recommendation section and bypass all your hard work! 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, laptops were heavy and unreliable—there may have been one model that was better than the rest, but even it was not worth having.

The recommendation section should echo the most important conclusions leading to the recommendation and then state the recommendation emphatically. Ordinarily, you may need to recommend several options based on different possibilities. This can be handled, as shown in the examples, with bulleted lists.

In an evaluation report, this final section would state a final opinion or judgement. Yes, the free-bus-transportation program was successful, or at least it was, based on its initial expectations. No, it was a miserable flop—it lived up to none of its minimal requirements. Or, it was both a success and a flop—it did live up to some of its requirements, but did not do so in others. But in this case you're still on the hook—what's your overall evaluation? Once again, the basis for that judgment has to be stated somewhere in the requirements section.

This is a good point to discuss the two basic organizational plans for this type of report:

• Traditional plan: This one corresponds to the order that the sections have just been presented in this chapter. You start with background and criteria, then move to comparison, and end with conclusions and recommendations.
• Executive plan: This one moves the conclusions and recommendations to the front of the report and pitches the full discussion of background, criteria, and the comparisons into appendixes. That way, the "busy executive" can see the most important information right away, and turn to the detailed discussion only if there are questions.

Example outlines of the same report. One using the standard approach; the other, the executive approach. Notice in the executive approach that all the key facts, conclusions, and recommendations are "up front" so that the reader can get to them quickly. In large reports, there are tabs for each appendix.

As you reread and revise your feasibility or recommendation report, watch out for problems such as the following:

• Write a good introduction in which you indicate the situation and the audience and provide an overview of the contents.
• State requirements—those factors that influence the decision or the choice of options. (And remember to state how important requirements are in relation to each other.)
• Indicate how the field of options was narrowed to the ones being compared.
• Organize the comparison of the options using the point-by-point approach. Don't use the whole-to-whole approach.
• At the end of each comparative section, state the best choice in terms that point of comparison.
• Include a summary table, if possible, in which you summarize all the key data in table form. (For example, see the summary table in the laptop computer recommendation.)
• Provide technical background, if necessary for understanding the comparative discussion.
• Discuss the background on the problem or opportunity—what brought about the need for the report.
• Include strong sections of definition, description, or both, as necessary, using the guidelines on content, organization, and format in the chapters on definition and description.
• Include a conclusions section where you restate all the key conclusions from the comparison section.
• State secondary conclusions in the conclusions section—and based them on requirements that you state in the requirements section of the report.
• State a final conclusion in the conclusions section—one that states which is the best choice.
• Include a recommendation section where you make the recommendation. Briefly mention the key factors influencing the recommendation.

Information and programs provided by hcexres@io.com.