Many professionals struggle to write engineering reports for clients.* Most engineering schools provide some instruction in report writing, but students’ reports tend to be formulaic and stilted. However, once students graduate they will need to write reports for their clients, not their professors. What clients want may be very different from what young engineers are used to writing.
The key to writing engineering reports for clients is to focus on the client. That is, think of it from the reader’s point of view. Who are they and what do they want from your report? Are you conducting a forensic investigation for an attorney? Are you developing concrete mixture proportions for a construction project? Both the format and the language of these reports will be distinctly different—or at least they should be.
Who are the readers?
You may be working for one client, but your report will likely have multiple readers, just as the audience for a technical presentation may have a range of backgrounds and interests. Just as you need to know your audience, you need to know your readers. If you are working for an attorney, every attorney and expert witness involved in the case will read your report. The expert witnesses will, of course, understand the technical terms, and they will scrutinize your report for errors, omissions, and inconsistencies. The attorneys, on the other hand, may have little or no technical background. For them you may need to define your terms and explain some basic concepts so they don’t get lost.
In addition to the terminology you use and what you need to explain or define, the readers’ educational background also tells you something about how to present your information. For example, scientists often prefer tables of data, while engineers prefer graphical presentations of data. Architects tend to be even more visually-oriented than engineers; for them you’ll want plenty of photographs and drawings.
If your readers are not native-born Americans, they may not understand the numerous sports analogies that can pepper even formal writing. In this situation you should avoid expressions such as “touch base” or “drop the ball”. One of my students, in writing a report to a client with offices in the US and Germany, described something as being “about the size of a football”. I had to point out that his German readers would most likely picture what Americans call a soccer ball.
What do they want from the report?
Determine what your reader wants from your report. Is he a busy executive who just wants a quick overview of the project? Is she an attorney defending her client against a lawsuit? A contractor who wants to know what went wrong and how to fix it quickly? A laboratory technician who needs to conduct the test the same way you did? Whoever they are, you need to make sure the information they want is in the report, easy to find, understandable, objective, complete but not too detailed, and in a form they can use.
To make sure your report addresses all of the client’s needs, you need to talk with your client. Indeed, good engineering reports for clients are even more about good client relationships than they are about good writing.
What your client wants from the report will influence how you organize it. There are many ways to organize the information, so don’t feel attached to the chronological narrative. Your client may even want you to start with the findings and follow with the data to back them up.
While it may not be obvious, how you organize the material in your report has ethical implications as well as practical ones. The reader will notice what you put first and naturally infer that it’s more important than what doesn’t come up until much later. Putting things together in a table encourages the reader to compare them. Plotting them on the same graph suggests that they’re related–even if they’re not.
Short forms
An engineering report may be just a one-page memo or a short email, or a letter a few pages in length. It should at least briefly cover the core content: introduction, what you did, results, discussion, and conclusion. Additional report sections are usually not necessary. If you cite a reference or two, you can use footnotes in lieu of a reference section.
If it’s an interim or progress report, you’ll have a “next steps” section rather than a conclusion. Your client may also want information about how much of the budget you’ve spent, how much you anticipate spending in the next reporting period, and when you expect to complete the work.
Long forms
Some projects call for extensive reports. Research and development projects and forensic investigations typically require lengthy reports. These will include not only the core content, but also several of the additional report sections.
The longer the report, the more you have to do to help the reader navigate it. Hardly anyone reads a long technical report from beginning to end, so you need to make it easy for them to find what they want.
You can help your reader navigate a long report by summarizing what you’ve just covered or what you’re about to cover. At the beginning of each main section, have a structural paragraph summarizing the main points of that section. You can also set the context of what you’re about to discuss by summarizing relevant information from previous sections. That way your reader doesn’t have to read the whole report to get the information they need.
The scientific method
It should come as no surprise that the core content of any technical report closely parallels the steps of the scientific method:
- Anecdotal observations lead you to formulate a hypothesis.
- The hypothesis may be in the form of a question or a statement. Either way, it must be falsifiable. That is, certain data and/or observations could logically prove it to be false.
- Experiments are designed to test the hypothesis. In keeping with the idea of the falsifiable hypothesis, certain potential outcomes of the experiments would prove the hypothesis false. There is no such thing as proving a hypothesis true.
- As you conduct the experiments, you collect data and observations that either falsify the hypothesis or not.
- Once you have your data, you may do some graphing, number crunching, or other processing to help you understand what you’ve observed.
- Based on the preceding steps, you draw one or more conclusions.
The core content
Similarly, the core content is as follows:
- The introduction incorporates the first two steps of the scientific method. That is, it provides whatever background information led you to formulate the hypothesis. The hypothesis itself may or may not be explicitly stated, but the reader could easily infer it if it’s not. In client reports you may not have a hypothesis per se; in that case, state the purpose of the work.
The “Results” section reports the data and observations you collected. Illustration by John Tenniel. Shutterstock image. - The experimental section describes the experiments, procedures, or observations you performed. Depending on the nature of your investigation, you may prefer another title for this section. You might call it “Methods,” “Procedures,” or “Test program,” for example. If you conducted standardized tests, just refer to them by number and title. A brief summary may be helpful to your client, but they probably don’t need step-by-step procedures.
- The results section reports your data and observations.
- The discussion may include processed data, comparisons between your data and other results in the literature, graphics, error analysis, statistical analysis, and outliers. You may make this a separate section or combine it with the results section.
- The conclusion includes any conclusions you draw from the data you presented.
Report sections that may precede the core content
Longer engineering reports to clients usually contain abstracts or executive summaries. Both briefly summarize the report, but they have different purposes. An abstract is primarily for the technically literate reader who may read the rest of the report. As such, it focuses on the scientific content of the report. An executive summary is primarily for the high-level executive who will not read anything further. Accordingly, it focuses on the business aspects of the report, briefly describes the technical content in nontechnical terms, and ends with the recommended actions the executive should take. Everything the executive needs to take the recommended action(s) with confidence must be in the executive summary. A report may have both an abstract and an executive summary if you anticipate that, say, the company president and the marketing director will read the executive summary and the engineering staff will read the abstract.
If you use a lot of technical terms or have a lot of equations in your report, you may want a terminology, notation, or glossary section. Some writers put this at the end of the report, but I prefer to see it near the beginning–just after the introduction, say. Readers won’t read it immediately after reading the introduction, but knowing it’s there will save them a lot of grief.
Sections that may follow the core content
Engineering reports to clients differ from student reports in that they’re intended to solve a problem for the client. For this reason it’s often not enough to draw conclusions from the data. You also need to answer the question, “Now what?” That is, you need to make some recommendations. What should the client do with the information you’ve provided? If you have several recommendations, start with whichever one will give them the most “bang for the buck” and put the rest in descending order. You may combine this section with the conclusion, but it’s usually better to keep them separate.
If you have an extensive literature review, you’ll need to list your references at the end of the report. There are several appropriate ways to format them. Either use your favorite technical journal as a guide or follow The Chicago Manual of Style. The important thing is to include sufficient information for the reader to obtain the reference. Consistency of style matters because you want to look professional. Be sure to include the date of publication. If it’s a website, include the date you accessed it, as websites should be updated as new information becomes available.
In a long report with multiple readers, you may want to put optional information in one or more appendices. For example, if you anticipate that only a few readers will want to know the details of your test procedures, you can include them in an appendix. Just make sure that you refer to the contents of every appendix somewhere in the report so the reader knows to look for it.
Writing style
Technical writing is usually formal and impersonal. It focuses on the facts, not on the personalities. It should never cross the line between science and advocacy.
In writing engineering reports for clients, you should stay away from using the first person and just stick to the subject matter. This is why many technical writers use the passive voice. While there’s nothing incorrect about passive voice, it can come across as stuffy and is difficult to read. Use active voice where you can and passive voice if you must.
Many organizations have their own style sheets, which set forth everything from which type font to use to the common terminology of the field. If your organization has one, be sure to use it. It’s not that type font matters per se; it’s just that if everyone in the organization chooses their own font you all look less than professional. For matters not covered in your organization’s style sheet, consult the current edition of The Chicago Manual of Style, which is the preferred style for scientific writing.
Once you’ve written the draft report, let it sit for a day–or at least a few hours. Then read it with fresh eyes, editing as you go. Be sure to have at least one of your colleagues review it before you send it to the client.
Beton provides technical writing training and technical editing services. To learn more, contact Rachel Detwiler.
*For tips on overcoming writer’s block, check out our blog post.