In this chapter, you study a loosely defined group of report types that provide a studied opinion or recommendation, and then, if you are in a technical writing course, you either write one of your own.

Be sure to check out the example reports.

Some Rather Fine Distinctions...

The reports in this loosely defined category 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, and there are absolutely no universally agreed-upon names for them:

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.

Typical Contents: Recommendation and Feasibility Reports

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.

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 recommendation or 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 of these 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 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.

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

Background on the Situation. For many of these reports, you'll need to discuss the problem, need, or opportunity that has brought them about. 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. Here are some examples:

Requirements can be defined in several basic ways:

The term "requirements" is used here instead of "criteria." A certain amount of ambiguity hangs around the latter 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. Set up your requirements so that they dictate a "winner" from situation where there is no obvious 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 tablets 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.

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 point-by-point approach.

If you were comparing tablets, 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.

Individual comparative section. Notice that this section compares only one point and ends with an overtly stated conclusion regarding that one point.

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?

Summary table. After the individual comparisons, include a summary table that summarizes the conclusions from the comparison section. Some readers are prone to pay attention to details in a table rather than in paragraphs. That does not get you off the hook from writing the paragraphs!

Summary table. Some readers prefer table data to data contained in paragraphs.

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 tablet is the least inexpensive but has poor battery function, but another is the most expensive and has good battery function, which do you choose, and why? The secondary conclusion would state the answer to this dilemma.

And of course, 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, labtop computers 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.

Primary, secondary, and final conclusions. Notice that in conclusion 6 two categories of comparison are weighed against each other, with more options winning out over lower cost—a secondary conclusion.

In an evaluation report, this final section would state a final opinion or judgement. Here are some possibilities:

Organizational Plans for Feasibility and Recommendation Reports

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

Example outlines of the same report. 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.

Revision Checklist for Feasibility and Recommendation Reports

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