Chapter 16: Guidelines for Technical Reports

Objectives

Upon completion of this chapter, readers will be able to do the following:

1. Differentiate among feasibility, recommendation, and evaluation reports, identifying their unique purposes, typical structures, and appropriate use cases in professional contexts.
2. Apply standard design principles (e.g. use of headings, lists, graphics, and cross-references) to create well-organized and reader-friendly technical reports.
3. Analyze and implement appropriate organizational plans—traditional or executive—for a given reporting situation based on audience needs and communication goals.
4. Develop a pre-writing strategy for technical reports, including audience analysis, formulation of research questions, identification of criteria and options, and planning for effective visual elements.

Introduction to Recommendation and Feasibility Reports

This chapter addresses a loosely defined group of report types that examine a situation, evaluate the evidence, and render a judgment.

The reports in this loosely defined category are variously called feasibility reports, recommendation reports, evaluation reports, assessment reports, etc. They all do roughly the same thing: provide carefully studied opinions and, sometimes, recommendations. There are some subtle differences among some these types.

Feasibility Report

This type of report 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, etc. The feasibility report answers the question "Should we implement Plan X?" by stating "yes" or "no," but more often, "maybe." Not only does it give a recommendation, but it also provides the data and the reasoning behind that recommendation.

Recommendation Report

A recommendation report begins with a stated need, and/or a selection of choices, makes a recommendation. For example, a company might be looking at grammar-checking software and want a recommendation for the best one. As the report writer on this project, you could study the market for this type of application and recommend one 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

An evaluation report provides an opinion or judgment rather than a clear yes-no-maybe answer or a recommendation. An evaluation report provides a studied opinion on the value or worth of something. For example, for over a year the city of Austin provided free bus transportation 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.

Report Design

Specifications for reports involve layout, organization and content, format of headings and lists, the design of the graphics, etc. The advantage of a required structure and format for reports is that you or anyone else can expect them to be designed in a familiar way: you know what to look for and where to look for it. Reports are usually read in a hurry. People are in a rush to get to the information they need, the key facts, the conclusions, and other essentials. A standard report format is like a familiar neighborhood.

When you analyze the design of a technical report, notice how repetitive some sections are. This duplication has to do with how people read reports. They don't read reports straight through: They may start with the executive summary, skip around, and probably do not read every page. Your challenge is to design reports so that these readers encounter your key facts and conclusions, no matter how much of the report they read or in what order they read it.

The standard components of the typical technical report are discussed in this chapter. The following sections guide you through each of these components, pointing out the key features. As you read and use these guidelines, remember that these are guidelines, not commandments. Different companies, professions, and organizations have their own varied guidelines for reports—you'll need to adapt your practice to those as well as the ones presented here.

Major Design Considerations

Consider the following design standards for reports.

Headings

In all but the shortest reports (two pages or less), use headings to mark off the different topics and subtopics covered. Headings enable readers to skim your report and dip down at those points where you present information that they want.

Bulleted and Numbered Lists

In the body of a report, also use bulleted, numbered, and two-column lists where appropriate. Lists help by emphasizing key points, by making information easier to follow, and by breaking up solid walls of text.

Symbols, Numbers, and Abbreviations

Technical discussions ordinarily contain symbols, numbers, and abbreviations. Remember that the rules for using numerals as opposed to words are different in the technical world. The old rule of thumb about writing out all numbers below 10 does not always apply in technical reports.

Graphics and Figure Titles

In a technical report, you're likely to need drawings, diagrams, tables, and charts. These not only convey certain kinds of information more efficiently but also give your report an added look of professionalism and authority. If you've never put these types of graphics into a report, you need not be a professional graphic artist. Some relatively easy ways to create graphics are available—Canva and Piktochart are excellent tools.

Figure 1: Excerpt from the body of a technical report

Cross-References

You may need to point readers to closely related information within your report, or to other books and reports that have useful information. These are called cross-references. For example, you can point readers from the discussion of a mechanism to an illustration of it. You can point readers to an appendix where background on a topic appears (information that just does not fit in the text of the report), and you can point readers outside your report to other sources of information (e.g., articles, reports, and books).

Page Numbering

All pages in the report (excluding the front and back covers, title page, and ToC) are numbered. Use lower-case roman numerals to paginate material that appears before the ToC. Don't number the ToC; it's page zero. Use Arabic numerals to paginate material that appears after the ToC.

Longer reports often use the page-numbering style known as folio-by-chapter or double-enumeration (for example, pages in Chapter 2 would be numbered 2-1, 2-2, 2-3, and so on, and pages in Appendix B would be numbered B-1, B-2, and so on). Similarly, tables and figures would use this numbering style. This style eases the process of adding and deleting pages.

If page numbers appear in a running header, don't display numbers on pages where a heading or title is at the top of the page (such as chapter or section openers).

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 Organization

This layout corresponds to the order that the sections have just been presented in this chapter. You start with background and decision-making criteria, define the options, then move to comparisons, and end with conclusions and recommendations.

Executive Plan

This layout moves the conclusions and recommendations to the front of the report and pitches the full discussion of background, criteria, options, and the comparisons into appendices. That way, the "busy executive" can see the most important information right away and turn to the detailed discussion only if there are questions. (In a large report printed in hard copy, there would be tabs for each major section and appendix.)

Report Pre-Writing Strategy

When you develop a recommendation, feasibility, or evaluation report, go through this checklist and think about these issues. Make a list of your thoughts on them so you (and if you are working in a group, all your coworkers) have a master document you can refer back to.

• Audience. Describe the report's intended audience in terms of the organization they work for, their titles and jobs, their technical background, and their ability to understand the report.
• Situation. Describe the situation and subject that the report will address. What problems or needs are there? Who has them? Where are they located? What will the report discuss?
• Deliverable type. Describe the report that you are writing. Is it a recommendation, feasibility, or evaluation report?
• Research subject. Develop a research question. What, exactly, will you investigate? (Be specific!)
• Available options. Identify and describe the things you will be comparing. What are these things? Are you going to determine yes or no? Choose from multiple options? Decide if something is good or bad?
• Criteria. Identify specific features, values, or ideas you can use to compare the various options or make an informed decision. Which of those criteria is most important? Least important?
• Information sources. Identify places where you can get information about your research subject. List specific books, articles, reference works, interview subjects, field observations, and other kinds of sources that you think will contribute to your report.
• Graphics. List the graphics you think your report will need according to their type and their content. Odds are, you'll need at least one table.

Attribution

This chapter is revised from the first edition of Open Technical Communication, Chapter 2.9: “Recommendation and Feasibility Reports” by David McMurrey and Jonathan Arnett and Chapter 4.1: “Report Design” by David McMurrey and Jonathan Arnett, which are both openly available under a Creative Commons Attribution license.

The content in Chapters 2.9 and 4.1 of the first edition of Open TC were originally sourced and revised from David McMurrey’s Online Technical Writing, sections titled “Recommendation and Feasibility Reports” and “Techdoc Design,” which are both openly available under a Creative Commons Attribution license.

AI Assistance Notice

Some parts of this chapter were brainstormed, drafted, and/or revised in conversation with ChatGPT 4o and Google Gemini 2.5 Flash. All AI-generated content was reviewed and revised as needed by a human author.