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 write one of your own.
Be sure to check out the example reports.
Some 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:
- 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"—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. Here's a video on a feasibility study concerning the Missouri Hyperloop (opens in a separate browser).
- 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.
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:
- 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 Austin Community College 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 transportation 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 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 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" even in situations 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.
Point-by-point 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 comparative point by comparative point, rather than option by option.
Schematic view of the whole-to-whole and the point-by-point 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—probably by the poor reader. (See above for a schematic illustration of these two approaches to comparisons.)
With the point-by-point approach, each of these comparative sections should end with a conclusion that states which option is the best choice in that particular point 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: When would you ever use the whole-to-whole approach? It might be that the comparisons don't break down logically into points—categories. The options being compared might have different advantages and disadvantages that are not comparable. Two products being compared might have different but overlapping sets of features. So which do you prefer—an apple or an orange?
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 expensive 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, 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.
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:
- 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 expectations.
- Or, it was both a success and a flop—it did live up to some of its expectations, 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.
Organizational Plans for Feasibility and Recommendation Reports
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 requirements, then move to comparisons, 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, requirements, 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. 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, be mindful of the following:
- Write a good introduction in which you indicate the situation and the audience and provide an overview of the contents.
- 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.
- State requirements—those factors that influence the decision or the choice of options. (And remember to state how important the 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 unless there is a strong, obvious reason to do so.
- 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.
- 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.
I would appreciate your thoughts, reactions, criticism regarding this chapter: your response—David McMurrey.
