Feature
by Kit Brown-Hoekstra
I judged technical reports and other documents for many years in the STC Publications Competitions. There was one report that stood out for me as an exemplar of what a technical report should be.
The report on the Columbia Disaster was truly impressive, not only for its thoroughness and sensitivity, but for its attention to effective information design, and the fact that the writers/editors had a difficult subject, a very tight schedule, and a huge number of people to coordinate with.
While technical reports vary significantly in length, based on the complexity of the topic and the needs of the audience, their primary purpose is to provide in-depth information to the reader about a particular project/investigation/research experiment, often one that is outside the reader's technical bailiwick.
In some cases, as with disaster reports, some of the audience might have a particular political agenda or bias regarding the findings. In this situation, it is especially important that the writer presents the topic objectively and clearly, while clearly stating assumptions and limitations.
Components of a Technical Report
Regardless of length, an effective technical report contains the following elements:
- Title/Cover Page
- Table of Contents
- Forward by the Project Sponsor (optional)
- Executive Summary
- Introduction
- Description of the Subject
- Methods
- Assumptions/Limitations
- Results
- Analysis/Discussion
- Cost/Schedule (if applicable)
- Recommendations
- Glossary
- Index (if it's more than 50 pages)
- Appendices of Supporting Information (optional)
Front/Back Matter
The Title Page/Cover Page, Table of Contents (TOC), and Index help readers navigate to the portions of the report that they are most interested in. The TOC and Index should contain at least two, but not more than three levels of headings.
The Forward, which is usually written by the project sponsor or lead executive helps the reader understand why the project/investigation/etc. was important and puts the project into the larger context of the organization or industry.
Executive Summary
Busy executives need to know the gist of what's going on, but don't have time (and often lack the technical expertise) to read through the details. An executive summary provides the important information about the project, including issues, costs, recommendations, and requests for action, but is typically about 5-10% of the size of the report.
For example, if the main part of the report is 10 pages, the executive summary will typically be 1 page, but a 100-page report will likely have an executive summary of no more than 5-6 pages. (If you can't explain your report or project in less than 10 pages, you need to rethink your explanations.) Though the executive summary typically appears at the beginning of the report, it is written last.
Introduction
The introduction provides the answers to the who, what, when, where, and why questions, sets the framework for the report, and provides context for the project. The introduction is usually 1-3 pages long and includes the following sub-sections:
- Background
- Purpose
- Scope
The first paragraph of the introduction should explain the context of the project, and grab the reader's attention. For example, the introduction to the Columbia report says:
The Columbia Accident Investigation Board's independent investigation into the tragic February 1, 2003, loss of the Space Shuttle Columbia and its seven-member crew lasted nearly seven months and involved 13 Board members, approximately 120 Board investigators, and thousands of NASA and support personnel. Because the events that initiated the accident were not apparent for some time, the investigation's depth and breadth were unprecedented in NASA history.
In these 2 sentences, you find out who was involved in the investigation, how long it took, and get a hint at the complexity of the subject matter.
The Background section places the project into the larger context. For complex reports, you can create side bars that provide the background for a particular area as you are discussing it. The Columbia report does this very effectively by briefly explaining the components of the shuttle and giving an overview of NASA, immediately before talking about the accident itself. This technique familiarizes the reader with the technical and political aspects of the program before delving into the details of the accident.
Purpose and Scope provide the reasons for the project and the limitations that the project has.
Description of the Subject
In the case of the Columbia report, Part 1: The Accident is devoted to describing the subject matter in detail, so that the reader completely understands the context and events leading up to the accident. For shorter reports, this section might be several paragraphs, rather than the several chapters needed in the Columbia report.
Methods, Assumptions/Limitations, and Results
In the Columbia report, this information is primarily found in Chapters 3 and 4. Though Chapter 3 is called Accident Analysis, it is primarily a report of how the investigation was conducted and what was found. The true analysis and discussion happens in Part 2: Why the Accident Occurred.
Like any research report, it is important to identify how you approached the problem, and to be precise and accurate in reporting your findings. Graphics and tables can help the reader understand complex data more easily. Assumptions/Limitations are important for ensuring the reader understands how you approached the issue and what constraints you had in conducting the project. You want to be as objective as possible.
Analysis/Discussion
This section is where you can start giving your own opinion about the investigation/project, based on your interpretation of the results. It is important to back up your assertions with specific examples from the results.
Recommendations
Recommendations should provide the reader with a course of action, and be backed up by the results. For short reports, a brief, 1-2 sentence explanation at the beginning of the section, followed by a set of bulleted lists (I like to sort them topically and by priority) might be sufficient.
For complex investigations, such as the Columbia report, you need to provide more information. In the Columbia example, Chapters 9 and 10 summarized the significant observations, making detailed recommendations for each one. In addition, Chapter 11 provided a coded list of the recommendations, so that the reader could review all the recommendations and then refer to the sections where they were discussed in detail.
Writing Style
The principles of good technical communication apply:
- Keep it simple
- Be clear
- Be concise
- Use active voice
- Minimize the use of jargon
- Know your audience
Jargon, if it must be used to preserve the technical integrity of the topic, should be defined in a glossary.
Conclusion
An effective technical report provides information in such a way that it clarifies a complex topic, and makes the recommendations and reasons behind them understandable to the audience. Since decision makers often use technical reports to determine an appropriate course of action, it is important to provide enough detail so that the decision path is clear.
****************
Kit Brown-Hoekstra is Principal of Comgenesis, LLC, editor of this newsletter, an Associate Fellow in the Society for Technical Communication, and a former manager and judge for the STC publications competitions at both a local and international level.