Be sure to check out the example feasibility reports available with this chapter:
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.
Figure 9-1. 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.
Figure 9-2. 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:
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 Figure 9-3 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?
Figure 9-3. 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.
