Recommendation, feasibility, and evaluation reports study a situation or problem, and offer researched, reasoned solutions. There are some subtle differences among these types, and they may sometimes blend (e.g., an evaluation or feasibility report may make a recommendation). However, they all have a general problem-solution structure, based on careful analysis, comparison, and presentation of data.

Recommendation Reports

A recommendation reports starts from a stated need or problem that needs to be solved, one for which no solution has yet been recommended. It offers a selection of solution options, presents a detailed comparative analysis of the options, 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 fit for them. As the report writer on this project, you could study the market for this type of application and recommend one particular product, a few possible products (differing perhaps in their strengths and their weaknesses), or none (maybe none of them is appropriate for the client’s specific needs). The recommendation report answers the question “Which option should we choose?” or, in some cases, “Which are the best options?” Recommendations might arise from questions such as the following:

• What should we do about Problem X?
• What is the best way to provide Function or Service A?
• Should we use Technology X or Technology Y to perform Function Z?

Feasibility Reports

A feasibility report studies a situation (for example, a problem or opportunity) and an already-proposed plan for doing something about it, and then determines whether that plan is feasible or practical in terms of current technology, economics, time frame, social needs and preferences, or other criteria. The feasibility report answers the question “Should we implement Plan X?” by stating “yes,” “no,” “maybe,” or “under certain conditions.” Not only does it indicate whether the idea is feasible, it also provides the data and the reasoning behind that determination. Conversely, a feasibility report might outline the reasons why the idea cannot or should not be implemented, or what obstacles must be overcome before the idea can become feasible. Typical questions addressed in these reports include the following:

• Is it possible? Can this be done within the allotted budget, time frame, legal and regulatory conditions, and technical capabilities?
• Is it financially viable? Even if it falls within our budget, should we do it? Will it have long term benefits that outweigh costs? Is there a less expensive or financially risky way to achieving the same result? How does it compare to the cost of doing nothing about this situation?
• Will it be accepted by the community?  Will people be in favor of this idea? Will anyone be opposed to it? How much public support is necessary to make this successful? (What kind of stakeholder consultation might be necessary to determine this?)

Evaluation Reports

An evaluation report provides an opinion or judgment about something that has already been implemented, to determine its worth. 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 attempts to answer. Evaluation reports analyze the thing or experience against a set of criteria to determine how well it met those requirements. Evaluation reports may end in a recommendation—continue the project, discontinue it, change it, or other possibilities.

Typical Content and Structure of Recommendation, Feasibility, & Evaluation Reports

Whatever variety of report you write, most of the sections and the organization of those sections are roughly the same.

There’s a structural principle fundamental to this type of report: you provide not only your recommendation, choice, or judgment, but also the data, analysis, discussion, and the conclusions leading to it. That way, readers can check your findings, your logic, and your conclusions to make sure your methodology was sound and that they can agree with your recommendation. Your goal is to convince the reader to agree with you by using careful research, detailed analysis, rhetorical style, and documentation.

The general problem-solving approach for a recommendation report involves the steps shown in the example below.

These steps generally coincide with how you organize your information. Your report will be divided into several sections that will likely include most or all of the following elements.

Introduction

The introduction identifies the situation or problem that has given rise to the report, and provides any background that your audience may need to understand the situation, your data, and your analysis. The introduction should be comprehensive enough to allow your readers to understand the problem or situation clearly and immediately. In some cases, if the initial discussion of the situation is too lengthy, you can create a more general introduction that identifies the situation and provides general background, and then create additional problem and technical background sections.

Problem Description – as needed

If the problem is complex, expand on the situation you mentioned in the Introduction. The existence and length of a problem description section ultimately depends on your audience’s needs.

Background – as needed

If the readers are not familiar with the issues, objects, or techniques discussed in the report, then you may need to include a separate section in which you explain any relevant background information or anything that requires specialized skills or knowledge. The dilemma with this kind of information is whether to put it in a section of its own toward the start of the report, to fit it into the comparison sections where it is relevant, or to include it in an appendix. 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 its own technical background or appendix section, or in the body section of the report that compares the tablets according to power and speed?

Requirements/Decision-Making Criteria

If your report requires you to make a judgment of some sort—is the project feasible? what is the best option? did the item pass or fail a test? —define and describe the factors that guide your decision. Common examples of decision-making criteria include costs, schedules, popular opinions, demonstrated needs, and degrees of quality. 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 a college with an ID on the college’s computer network, you’d need to 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 free bus transportation program 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.

Criteria may need to be defined on a fairly granular level. For example, “chocolate flavor” may be a criterion for choosing among brands of chocolate truffles, but what defines a desirable chocolate flavor? Do you want a milk chocolate flavor? A dark chocolate flavor? White chocolate? A high or low percentage of cacao? Sweet, bitter, or spicy? Single-origin cacao beans or a blend? If single-origin, do you want Ghanian, Venezuelan, Honduran, Ecuadorian, or Filipino?

The criteria 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, another has better ease-of-use rating, another has been proven to be more durable. Prioritize certain criteria over others a so that they dictate a “winner” from 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 section follows right after the discussion of the criteria. Your basic requirements may well narrow the field down for you. But there may be other considerations that disqualify other options, which you need to explain as well. Additionally, you may need to provide brief technical descriptions or general specifications for each option.

Important Note

Do not actually compare the options in this section. Simply describe them 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. The Discussion of Solution Options is a lead-in to the next report section, which does offer your comparative analysis.

Comparative Analysis

One of the most important parts of a feasibility or recommendation report is the comparative analysis of criterion to criterion. 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. In many cases, an alternating approach is the best option.

To use the example of comparing tablets in a recommendation report, you’d likely use the point-by-point approach, with a section comparing all three options based on cost (criterion A), another section that compared them on battery function, and so on. For efficiency’s sake, you most likely would not have a section that discussed everything about option 1, another that discussed everything about option 2, and so on, since you’d still have to make direct comparisons somewhere near the end of your discussion,

Each of these comparative sections 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, for example, providing multiple conclusions for different conditions.

If you were writing an evaluation report, you 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, Austin 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 such that summarizes the conclusions from the comparative analysis section. Some readers are more likely to pay attention to details in a table than in paragraphs.

You may fill in the table with precise, concise phrases or with ratings. If you use ratings, make sure to provide a key (e.g., 1 = excellent, 2 = good, or 1 = completely fulfills needs, 2 = partially fulfills needs, etc.).

Conclusions

The conclusions section of a recommendation, feasibility, or evaluation report contains two types of conclusions, primary and secondary. Primary conclusions are the simple, single-category conclusions you reached in each of the comparison sections, for example, which tablet model had the best price, which had the best battery function, and so on. Summarize the relative strengths and weakness of each option based on how well it meets the criteria. Secondary conclusions untangle and answer any dilemmas evoked by conflicting primary conclusions, and offer a final conclusion. 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?

Recommendations

The recommendations section offers recommendations which flow directly from your conclusions and directly address the problem outlined in the introduction. Recommendations may sometimes be repetitive, but remember that some readers may skip right to the recommendation section. Also, there may be cases in which there is a good choice that you don’t want to recommend, e.g. a well-performing, cost-effective tablet that is simply too heavy and large for easy portability. 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.