Technical Report Writing

Report design is a process which can be learned. In this Chapter basic report formats are described and ways to use them effectively are offered. Cloning reports from other reports is a way to save time while improving report design in the process. The usefulness of "generic" report elements, to both the reader and the writer, is also covered.

There are a number of report formats available to you as you begin to think about how to organize your report. Except for very short reports, the chronological format is almost useless when dealing with complex, multilevel audiences. No one wants to read this:

"I arrived at the project site at 8:00 am, first investigated the construction completed yesterday, then spoke to the superintendent regarding Change Order No. 7. I then left to view the work under construction that day and while there noticed that the concrete being delivered appeared to have excessive slump, .............. etc. etc.".

This format works well for daily, short reports of 1 to 4 pages but you, and your readers, simply cannot take the time to wade through this kind of detail for reports of greater length or complexity.

A somewhat better format, which works well for short to medium length reports of about ten to twelve pages is the Problem, Analysis, Solution approach. This can be effective when there is only one technical problem to be discussed and the number of possible solutions is also limited. More complex problems with multiple solutions do not fit well into this format because the length of the report will grow rapidly as the number of alternatives increases.

Some organizations have developed standardized report formats to which you may be required to conform. When this is the case, there are still many things you can do to make your report readable, concise and useful. Here are three suggestions for accomplishing that.

1. The Outside - In Approach

In Chapter 4 the principle of writing the report by moving the discussion from the general to the specific was mentioned. This means, simply, that the discussion is more readable and easily scanned if you make certain that the most important ideas in each section, subsection, and paragraph appear first rather than last. Here are two sample (made up) paragraphs which illustrate this principle.

"Three tests of the system were performed. In the first, the system was subjected to average loading conditions while disabling the emergency by-pass line. No problems were encountered except during simulated power failure. Without the availability of the emergency bypass, water could not reach the secondary cooling coil and overheating rapidly developed. In the second test, the emergency by-pass line was reactivated and the system subjected to a 50 percent overload. Although efficiency dropped from 63 percent to 52 percent, no other problems were encountered over the 6 hour test duration. Test three increased the overload to 100 percent for 6 hours. Serious overheating developed despite the emergency bypass working properly. Efficiency fell to 28 percent and complete system failure appeared likely had the test continued beyond 6 hours. From these tests we conclude that the emergency bypass is essential to ensure continuous, unattended operation and should be increased in size from 4 to 6-inch. It is also recommended that a backup to the bypass line be installed which will automatically augment cooling at system operating temperatures in excess of 100 degrees F."

A better way to write this is to reverse the discussion by stating the conclusion and recommendation first, rather than last, For example;

"A larger bypass line with automatic, temperature controlled backup is recommended. Such a system will protect against overheating and lowered efficiencies under extreme load conditions and permit safe, unattended operation of the system. Tests performed to verify this are detailed in Appendix D."

Compare these two paragraphs. Not only is paragraph B much shorter, it tells the reader immediately the most important results and conclusions drawn from the tests. Many readers will not even need to read the rest of the paragraph. If they do, they'll also find out why the recommendation is being made. This is probably the second most important thing most readers will want to know. If the reader still would like more detail, the last sentence tells where that can be found. The specific details of the tests are of interest to some readers presumably, but not to all. They shouldn't be left out of the report but they are best placed out of the way of the main ideas.

This leads to a second principle of report writing which can do wonders for improving readability.

In general, the more data, facts, test results and similar detail you have the more likely it is that you will overwhelm your reader and yourself with it. It may be very good data and you may be justly proud of it, but it will swamp the most attentive reader if you let it. To avoid this problem, many writers summarize their data in the main report as succinctly as possible, and then present it in full in a large, often separately bound appendix.

During World War II, Winston Churchill ran the British war effort with what most historians concede was consummate skill. Churchill had a rule for all subordinates who reported to him. It was that he would not read anything from them which ran over two pages. He made no exceptions to this and those who worked for him soon learned that their ideas would not even reach him if they broke that rule. Forced to state their case in this short span soon taught them to say what was really important first, and very clearly. If the idea had merit they were invited to submit more detail, but only if they had really presented their ideas well.

The Executive Summary serves the same function. In it, only the most important information can be presented. The size of an executive summary is not defined but they typically run only a few pages. To cram as much useful information as possible into it, the writer must distill his entire report into some graphs, maps or other figures, tables, and some text. Every trick of concise data presentation must be used. When well done however, an executive summary presented at the beginning of your report will get your message to the most readers in the smallest possible space.

Discussed presents an orderly way to write a technical report. It is an excellent guide and recommended. But report writing, in fact, is not nearly so neat and tidy.

Outlines are very useful tools. With a good outline you have the advantage of knowing where you are going with this report. You have a place to put the data as it is developed and you have a kind of plan for not only writing the report but for solving the technical problems as well. This syllabus is written from an outline. The finished report is little more than the original outline expanded again and again adding detail each time. To be really useful though, outlines need to be thought out carefully and checked for completeness. Even then, permit yourself to modify your outline as you write to account for new, unforeseen facts or results or questions arising from the technical problem solving process.

Another humble, but very useful tool is the check list. Several generic examples are included in this syllabus but you should develop some of your own if you do much writing.

Sometimes technical report writing requires that you somehow organize large quantities of data from many different sources. This task may seem very daunting at first but a stack of three by five cards can be a great aid. On them you might jot notes describing the data you have. Simple notes are best; what it is, where it came from, how reliable you consider it, and where you think it might fit into your report. Now, find a large table, like a conference table, and spread the cards out on it. No particular order is needed; just get them out there where you can see and read them all as you walk around the table. As you wander, think about each card and how or where it might fit into your report. Think too about the importance of each card to the objective or purpose of the report. Try grouping the cards in various ways; by subject or in chronological order, for example. As you do this, perhaps several times, usually some pattern will emerge from the groupings. This won't always happen but often, surprisingly, it does.

Word processors have made cloning, that is, the production of several reports out of one basic report, into a fine art. Use this technique whenever you can, but especially if you produced a very good, well organized report of some particular type. Apart from the hours saved by not having to retype pages of more or less interchangeable text, the great advantage of cloning lies in the fact that the report organization, its design, is already provided for you. Sometimes you have to make modifications but if you’ve chosen your parent report well, these will be few and simple and you can begin your writing knowing you have a good plan to work within.

Many technical reports have elements in common with others. As an example, this syllabus begins each chapter with a Chapter Summary. Other reports typically end each section with a list of conclusions reached based upon the facts , data and analyses presented in that section. Look for these in the reports you read and look for opportunities to create them in the reports you write. They help your reader by giving him a consistent and recognizable pattern he can use to reduce his reading time while increasing his understanding of your report. They help you by reminding you to do certain essential writer's tasks like bringing each part of the report to a logical conclusion, bridging to the next section of the report, repeating important information to reinforce it in the reader's mind, etc.

Make it a practice to find and save the best examples of reports, graphs, maps, tables and formats that you can find. These can be your own work or the work of others.

Chapter 1 * Chapter 2 * Chapter 3 * Chapter 4 * Chapter 6 * Chapter 7 * Chapter 8 * Chapter 9 * Chapter 10