Găsiți următorul dvs. carte preferat

Deveniți un membru astăzi și citiți gratuit pentru 30 zile
Technical Writing for Engineering Professionals

Technical Writing for Engineering Professionals

Citiți previzualizarea

Technical Writing for Engineering Professionals

503 pages
5 hours
Jul 6, 2016


Technical Writing for Engineering Professionals provides a toolkit for developing technical reports quickly and efficiently. The book offers clear, specific guidelines for developing each of the sections (abstract, conclusions, introduction, and discussion) and designing and using graphics that illustrate your results. Weatherford's approach can be applied in all types of writing, from email and letters to project proposals and final reports. The book also includes tips for using English that will help keep your writing crisp and clear. Anyone in a technical profession, from intern to management, who wants to implement a better, faster, and more consistent approach to writing will benefit from reading this book. Key Features -Understand the process of writing a technical report, from the time you know your conclusions until you present it to your supervisor, client, or professional organization. -Get a quick overview of each chapter in the "short form" summary at the beginning, and use the handy checklist at the end to critique each part of your report as you write. -Learn to read literature efficiently and critically and take notes that will help you write your own reports as well as how to cite material that will lend strength to your work.
Jul 6, 2016

Legat de Technical Writing for Engineering Professionals

Cărți conex
Articole conexe

Previzualizare carte

Technical Writing for Engineering Professionals - Darla-Jean Weatherford



Here’s the short form: Writing is fundamental to engineering, but it’s often burdensome and frustrating. Having a roadmap can make it easier.

The secrets of engineering report writing have been handed down for decades much like folklore: One writer or group of writers developed a pattern for writing their papers, and they taught that pattern to their understudies, who passed it on to the next generation, and so on and on and on. In the process, the pattern may have changed a bit, but out of reverence to the masters, each generation held tightly to the basic guidelines from the one before.

The problem tends to be that one group doesn’t necessarily look at what others are doing and question whether their own approach might be improved by borrowing strategies from the other groups. So they all wind up using a formulaic set of sections in their papers, but they may not agree on what each section actually represents:

Titles may be brief labels, long strings of keywords, or statements of the main achievements of the work.

Papers themselves may begin or end with the Summary section, which may be an Abstract at the beginning or the Conclusions at the end. Either way, it may or may not really summarize the content of the paper.

The Summary or Abstract at the beginning of the paper may summarize, provide introductory background material, or simply describe the general content of the paper.

The Introduction may be the first section or it may follow the Abstract or Summary. It may contain a literature review, background material on the project, descriptions of the worksite (such as the geological characteristics of a field or reservoir), a description of the paper (listing the coming content), a summary of the work, justification for the project, or all of these.

A Literature Review section may be called the Introduction or it may stand alone, usually following the Introduction. Citations may appear just about anywhere in the paper, so discussions of the current project may wander off into the history or theory of earlier efforts to solve the problem, distracting readers from the project at hand.

The Methods may be a stand-alone section or combined with the Results. It may go into great detail about the way the project was conducted, documenting the model number and manufacturer of every piece of equipment, or it may briefly name a test and skip all the other details.

The Results may be a stand-alone section or combined with the Methods or the Discussion. It usually provides the most graphics in the paper, providing graphs and tables that claim to illustrate the outcomes of the project, although their design may make them difficult to interpret.

The Discussion may be a stand-alone section or combined with the Results or Conclusions. It may or may not explain what the results show or what they mean in ways that really help readers grasp the significance of the work.

The Conclusions may be a stand-alone section that lists the significant outcomes of the project, sometimes commenting on the importance or value of those outcomes. Or it may be combined with the Discussion, reflecting on the project, its outcomes, its potential significance, or future direction for the work. It may be called a Summary, and when it is, it may or may not summarize the project or the paper.

The Trusty IMRD Template

Many writers attempt to follow an old template widely known as IMRD: Introduction, Methods, Results, Discussion—but as we can see, those terms are not very helpful if we don’t know what they mean.

Furthermore, engineering reports seem to have evolved to include two additional parts: the Abstract and Conclusions (perhaps including Recommendations). Even though the literature doesn’t clearly define what either of these is, a fuzzy comprehension of them seems to be common:

The Abstract seems to be a sort of starting point for the paper that eventually works its way around to telling readers something about what to expect as the outcome.

The Conclusion tends to be a succinct interpretation of the most significant outcomes of the project, although it may be perverted into a summary of the tasks or its results, a sort of closing observations on the project, or a projection of future work.

Recommendations may be included with the Conclusions or may stand alone. They generally propose a course of action for dealing with problems addressed in the paper.

Those aren’t strong statements because there is so little standardization from one paper to another, one workgroup to another, or one professional organization to another, but they do seem to be somewhat consistent across a fairly broad range of papers.

Writing from Conclusions

The Conclusions section is especially important as we consider report writing in engineering. In other disciplines, the Conclusions often represent the authors’ reflection on their work, sometimes including commentary on parts they did well or could have done better, parts that appear to hold greater significance to the professional understanding of the problem, lengthy explanations of why the work as a whole is worthy of consideration, and potential directions for future research.

Engineers may just not be terribly interested in reflective writing, or maybe they are too busy with new projects to spend their time musing over the project they’ve just done. Regardless the reason, they mostly tend not to spend great amounts of time on reflective Conclusions, but instead use them to get to the point of what they have accomplished and why it matters. And that’s probably a good thing. Since the readers of engineering reports are also hugely busy people (and many of them don’t like reading any more than they like writing), delivering the critical message quickly and efficiently works better for them, too. Engineers can deliver the conclusions and get on with the next project, readers can get what they need and determine whether they can apply the outcomes to their own situations, and everybody wins.

The next problem, though, is what to do with all the other sections. If we can’t agree on what goes in them, how can we write efficiently?

For the purposes of this book (and for writing in situations where we have some control over how we put papers together), we can define the sections of technical project reports in terms of simple tools that help us know what to put in each section and how to make a whole report work. These are strategies developed over more than 20 years of teaching and studying technical report writing; reading, writing, and editing technical documents; and coaching students in technical presentation skills. Using them in developing technical project reports can make your writing and presentation tasks easier. Although the focus of this book is on technical project report writing, you may find that the strategies can also help you improve other writing projects as well.

Sections of a Project Report

If you are writing on ACID, you’ll organize all of the report into four broad categories: Abstract, Conclusion, Introduction, and Discussion. Since you need to have the conclusions at hand before you start to write the report, let’s start the discussion of these sections with them.


Conclusions are the reason to write a report. Until you know the conclusions, you really don’t know what the report needs to say. The Conclusions should include short interpretations of results, which will help your readers understand the meaning of those results. It will also help them decide whether the work is useful to them and whether they trust your engineering approach. After you have finished the project (or a part of it), you can write brief statements of the outcomes and use them as an outline to guide the rest of your writing.


Abstracts are by definition summaries of essential parts of papers, so the Abstract should be a short statement of the essence of the report: what did the project achieve and why does it matter? Mark Twain is credited with explaining that something he wrote was long because he didn’t have time to make it shorter. Many long abstracts appear to have been written by folks who either didn’t have (or didn’t bother to take) the time to make them shorter. But if you focus on presenting only the major accomplishment(s) of the project and why it matters, you can save yourself a great deal of time and effort in writing. (Check your cell phone. If you had to deliver the report to your boss on it, what would you have space to say?) And if you have finished the project and know your conclusions, the Abstract can be easy and fast to write.


Introductions set up the context for your readers to win their trust. You want to give them some local context; that is, help them understand why you got involved with this project and how your circumstances may relate to some problem they’re also trying to solve.

You may also give some global context; show that you know something about what others have done to try to solve similar problems, although their solutions may not be adequate to solve the parts your work has addressed. (Or if you adopted their solutions exactly to solve your problem, give those other authors credit for guiding you.) With the global context, you show the gap (or lack of one, if you were able to adopt other solutions) between existing approaches and your needs.

Finally, you will give the readers closure; that is, assure them that you resolved your initial problem and closed the gap between existing technology and the need you identified.


Discussion can include anything else you need in the report, which makes it the most ambiguous of all the sections. A good way to think about it is simply to show your readers what you did. The difficult part, actually, is filtering the details of the project for inclusion or elimination from this section. It is probably simplest to write every detail of your methods, adjustments, and solutions, but it’s smarter to define your audience and decide what details they’re interested in. And to cut through the ambiguity of the word Discussion, you can use individual headings for each part instead of buckets of text under just one heading—helping the readers know exactly what to expect.

Here’s the catch for the Discussion: Focus on what you did. This is not the place to drag your readers back through the literature to show how your approach was derived from another project. Nor is it the place to wander off into what others are doing in similar projects. The Discussion is one place where the paper is all about you and your work, what you observed, and how you interpreted those results.

Often, writers start the Discussion with a Methods section, setting up the process by which they did the work. This is frequently the best place to start. But like everything else in life, it depends: If your project depends on understanding a petroleum reservoir, you may want to begin your Discussion with a subsection that introduces the known reservoir characteristics. If it depends on intense mathematical theory, you may want to take that theory out of the Introduction and wedge it into the beginning of the Discussion. If you thought the full literature review related to your project was too detailed to include in the global context of your Introduction, you may want to insert a deeper review of literature before your Methods.

You may have other good reasons not to start your Discussion with a Methods section, too. If your project had a single test or workflow, you can introduce your methods briefly and use the rest of the Discussion section to display and discuss your results. But if your project had multiple steps with different methods, you may want to break the Discussion into subsections of Methods and Discussion (and probably even Conclusions) for each different test or process. This information chunking allows the reader to scan your paper, read it more quickly, read it more purposefully, or refer back to its meaningful parts.

Let’s say you developed a new alloy to use in the company’s new flowmeter. Your Discussion might cover three major tests: materials evaluation, pressure testing the tool, and heat testing the tool. After all the tests, you derived a mathematical model to estimate performance downhole. Instead of having a single Methods section at the beginning of your discussion, you would have sections named Materials Evaluation, Pressure Testing, Heat Testing, and Model for Estimating Performance Downhole. Now your readers can find and review each important element in its own succinct subsection of your report.

Some reports include Results as a subsection of a Discussion section, but as seen above, the IMRD model considers Results and Discussion equally important, which doesn’t make much sense. In many ways, separating them from one another doesn’t make much sense, either. The Results are much more meaningful to most readers if they are accompanied by the Discussion. Some writers separate the Results (which are usually graphical) from the Discussion on the assumption that their readers will be able to understand the graphs without being slowed down by the text. Others format the graphs separately because they don’t want the hassle of embedding them within the text. But in most cases, a Results heading is unnecessary, especially if the paper is divided into sections by process instead of IMRD. The same thing holds true for the Discussion heading: if the paper is divided by processes, the heading is likely unnecessary. (If the process sections are long, you may want to provide subheadings for Methods and Discussion within each process section.)

The Discussion section also explains the graphics and helps the readers understand not only what you think they show (others could interpret your graphs differently from the way you do), but also why they matter. Sometimes the why of a graphic seems self-evident: if your new alloy withstands substantially higher pressure and temperature than existing materials do, your graph comparing them will suggest to most readers that yours is better. But if you went into the project with a goal of finding an alloy that will hold up under greater water depths than current ones do, your interpretation should remind readers that the improved performance in higher pressure and temperature makes the material appropriate for the deepwater applications you are trying to address.

Just stop

One of the hardest things for writers to learn is that technical reports don’t have denouements—that final part of the story that tells readers how everything turned out. They often want to think back over the work and give the readers some parting words that give the report a happy ending so that everyone can go away from it feeling good. But that’s just silly. If you have done your job of staking a claim, providing the evidence, and explaining what you see, your readers already know the happy ending, so that kind of writing just isn’t necessary. Instead, when you have done what you set out to do, just stop—and your report will be all the better for it.

You may have a few relevant items to include at the end of the paper, though. If you have cited literature, you will need a References List; if you have included equations, you may need a Nomenclature section. You may want to acknowledge contributors to the work, especially if your project was funded by an outside organization, and you may have Appendices that give greater detail about certain topics within the paper. You may slip in a section discussing future work that may interest your readers either before or after your Conclusions.

But as far as tying it all up is concerned, in a technical report that just isn’t necessary; when you get to the end, just stop.

Chapter 1

The Models

Here’s the short form: Engineers who need to explain a concept often use analogies to similar concepts by way of illustration. This book uses three increasingly complex model projects to illustrate possible ways to handle report writing.

This chapter outlines these model projects for illustrations of ways to handle writing strategies and problems. None of these models is a true representation of any known project, although all of them have been derived from real projects.

Archimedes’s Law

Long before entering engineering programs, engineers may have become familiar with Archimedes’s law that an object displaces its own weight. Some have heard the story about the law that has grown up through science folklore: The king of Syracuse at the time of Archimedes (probably Hiero II in the middle of the third century BCE) provided gold to a court jeweler to make into a crown. When the crown came back, Hiero suspected that the jeweler had not used the full measure of gold provided to him. He called Archimedes (who, for our purposes, was equivalent to the director of the Syracuse Research Center) and charged him with determining whether the crown contained the correct amount of gold. If it did not, the king would assume the jeweler was guilty of theft and sentence him to death.

Of course, science wasn’t nearly as advanced in 250 BCE as it is today, so this problem would have been much more challenging for Archimedes to solve than it would be for a modern engineer—or even for students in modern primary schools. As the story goes, the biggest problem facing Archimedes was that he had no way to determine whether the volume of rectangular gold bricks given to the jeweler was the same as the volume of the irregularly shaped crown.

Like many engineers facing a new problem, Archimedes mulled it over for a time and then had a eureka moment (that’s what he is supposed to have shouted when the idea hit him, and he is now credited with coining the term). The eureka moment itself came when Archimedes was at a local bath, where he realized that the water rose as he lowered himself into the tub, which must mean, of course, that a body displaces water in some relationship to the volume and/or weight of the object. That being the case, all he needed to do was submerge the crown in water, determine how much water it displaced, and then determine whether that value would correspond with the known volume of gold.

According to the story, the leap from that thinking to the determination of the amount of gold in the crown was straightforward enough for Archimedes to make his report to the king. (It’s not our job to report whether the jeweler was guilty.)

That’s the story this book discusses for the first and simplest project model.

Obviously, the story is full of holes, which gives us room to mold it to our purposes. For example, we don’t know what tool Archimedes used to measure volume; he may not have had even a graduated cylinder, and certainly he would not have had a calibrated pycnometer. And if the jeweler were really astute, he might have realized that replacing gold in the crown with silver (which is the usual accusation) would have made the crown lighter, but replacing it with a combination of light and heavy metals might have made it just about the right weight. So Archimedes’s only test of the crown’s weight against gold wouldn’t be real assurance of the jeweler’s honesty.

Furthermore, Archimedes would most certainly have had to make some report to the king, but chances are that his verbal evaluation was all the king needed to sever the jeweler’s head. The report might have been captured in legal documents to hand down through the centuries, but they would have been simple and direct statements, not including much detail about the bathtub discovery or any other possibilities for why the crown weighed what it did. And while we have plenty of evidence of early writing that covers Archimedes’s time, he certainly didn’t have access to letterhead stationery, much less typewriters or computers or other ways of jotting off a quick document to leave a paper trail for the king.

But for our purposes, Archimedes of course does need to provide both oral and written documentation, perhaps also needing to include a slide presentation for the king and follow it up with a presentation at the annual meeting of the Greek Academy of Science (GAS). The scientists’ interest, of course, would have been less on the assessment of the gold in the crown than on the scientific principles involved: Displacement had been around forever, and they may have recognized it, but they may never have thought to name it or quantify it or use it for scientific purposes. They would have wanted to know how Archimedes determined the relationships among displacement, density, and volume.

For this book, we can assume that he tested his hypothesis with regularly shaped objects that would allow him to calculate volume easily and relate the volume to their weight. If he submerged those objects in water, he could determine how much water the objects replaced, which would show how displacement relates to volume and weight, and then he could have done the same thing with sample irregular objects.

Displacement might have had other implications for the citizens of Syracuse too: since it would give people a way to measure items that they might not have been able to measure before, it might affect economics. With that in mind, Archimedes might need to present his work to community groups, like the Syracuse Chamber of Commerce, who would want to know how this work might affect their ability to do business better.

So while the concept of displacement is truly elementary and the story is mostly folklore, it gives us a model for writing engineering reports about relatively simple projects.

Redesigning a Flowmeter

For a more complex example, this book will reference a project at a small tool manufacturing plant, where engineers attempted to improve the quality of the company’s most popular flowmeter so that it could measure rates as low as 5 ft/min. As a part of the project as it appears here, the engineers also designed an on-site test facility that maintained the reliability and accuracy of the standard facility, which is several hours from the tool plant.

In our project, the need for the tool was brought up by a customer who was seeing flow rates drop in their operations. While the existing flowmeter appeared to capture current flow rates, the customer was concerned that rates could fall too low to be measured accurately and suggested that a new meter could be worth the cost to develop and manufacture.

The new design required consideration of the materials used to build the tool (especially the hub, which must be smooth enough to allow the axle to turn freely; the axle that carries the impeller, or spinner, blades; and the blades themselves) and the angle of the impeller blades.

For the purposes of this book, the project was only partially successful. The flowmeter was improved from its initial ability to measure flow through a broad range of fluid viscosities and temperatures at 10 ft/min to excellent performance at 7 ft/min, but it was not reliably successful at the target rate of 5 ft/min. That means that reports about it could include both the good news that it had had some success along with the bad news that it had not reached the proposed target, which must both be reported in some but not all cases.

Since this project is much more complex than Archimedes’s simpler work on displacement, it entails a good deal more detail in its reports. It also would entail more challenges for writing and presentation. For example, it might have started with a proposal to management or a funding agency (possibly the customer’s company) to approve the expense of designing and creating the prototype; progress reports to the funders and supervisors at regular intervals; communication with the customer; notes for future reference as the company considers other modifications to its flowmeter line; a final report for the funders; possibly multiple professional papers for meetings or publication (and the accompanying presentations); and presentations to funders, collaborators, and supervisors and possibly to community organizations, schools, or governing bodies.

As you’ll see, these documents will turn out to be more complex than the ones for Archimedes’s work with displacement, but they will follow the same basic structure; once you learn the ground rules with simple projects, you can build to bigger and more complex projects fairly simply.

Mooring System Design

The third (and most complex) model project here has its origins in the proposal for a long-term university research project. Most simply, the idea was to develop a new design for mooring systems for offshore facilities, such as those used by the oil and gas industry. One of the justifications for the project was to improve stability and safety on these facilities.

Part of the project was to evaluate and recommend improvements to the mooring lines themselves. For the purposes of this book, the project was much larger and more complex and was housed in a corporation rather than a university. It includes several related components: evaluation of the subsea environment where the facility would be built and of mooring lines themselves; evaluation of a collection of standalone models for performing those evaluations and for designing mooring systems; development of a new simulator comprising all the models into a single, faster program; and the design (and possibly testing) of the new mooring system.

That collection of objectives would entail a great deal of work for an engineering research team:

Finding as many correlations as possible that are already used in the industry to evaluate the subsea foundation, mooring line, and stake components, and comparing them in a way that identifies their strengths and weaknesses. This would mean understanding such essentials as site evaluation, including rock properties for the foundation, and line strength and elasticity.

Finding a way to combine the necessary standard commercial models to reduce the amount of time required to complete modeling of large datasets without reducing accuracy or reliability.

Determining the factors that most affect the stability of mooring lines and determining the best configuration to ensure safety in a given subsea environment.

Validating the efficacy of the new simulator by installing and testing mooring line configurations onsite.

All this activity would require not only a good deal of time, but also quite likely a moderately large research group. In our interpretation of it, the multiple models in current use are run by engineers and geologists from several parts of the design group, so we might have each team assess the models available to accomplish their usual tasks. Or we might hire a contingency of university students with some software experience to assess them.

Once we had summaries of what the programs do, what input they require, how and how well they work, and what kind of information they provide, our smaller research team would need to determine whether any of them are redundant with the others, what parts we would need to preserve in our simulator, and how we could make them all work together.

One of the factors in mooring system design is the configuration of guy lines around the facility. For our purposes, we assumed the most common configuration was 12 or more lines spaced evenly around the facility, like the numbers on a clock face. As an alternative, we tried moving the lines to different patterns, such as X and Y shapes, to determine whether grouping the lines would improve stability on the facility. For our purposes, the Y-shaped configuration (using the strength of a triangle), appears to be the most stable.

For this book, this is as far as the work has gone—it has not yet been applied to a real facility. That gives us the opportunity to provide a number of progress reports to our management as we complete the earlier steps of the project, and we can turn these progress reports into separate papers for professional organization meetings. It also allows us to include recommendations for the next steps in our documentation for management or other funders. And, of course, it also provides opportunities for all the writing needs of the earlier projects.

Be aware that although this project is much more complex and involves input from a much larger group of researchers than the others, it still can follow the same basic writing principles as our little project with Archimedes and the intermediate flowmeter project—once you understand the concepts, you can apply them to bigger and bigger projects.

Chapter 2

Writing for Real People to Read

Here’s the short form: Everything you write is shaped by the audience, the purpose, and the context. Keep all of these in mind as you plan content and style for busy readers.

Most of what you write probably has a very short shelf life: your grocery list, the email you write to invite a friend to lunch, the address of a client’s office—all may be in the trash bin by the end of the day. They all need to be accurate and readable, but beyond that, not much else matters.

Some writing stays around for much longer, but it may not require much writing skill to produce: an application for a loan, the results of routine tests, and the list of parts for a piece of equipment. Other writing may be more complex: the steps you took to conduct an experiment, the notes you recorded from a team meeting, or the design changes you are recommending for a new tool. These must be written carefully enough for you or others to use if you need to retrieve the information later.

Some fraction of what you write will likely need to go beyond all these examples and persuade readers—your work group, your company’s management, or your clients—to accept an analysis, take an action, or consider a new alternative. These documents may include internal or external project reports, papers you submit to meetings or publications, or presentations you make to legal or civic groups. They represent your organization as powerfully as many of its expensive public relations efforts, so you want them to demonstrate that you do good work, you understand what you are doing, and you understand what your readers need. But they won’t matter if your readers don’t read them.

Audience, Purpose, and Context

Most people today are really busy, and most don’t spend much time reading details or

Ați ajuns la sfârșitul acestei previzualizări. Înscrieți-vă pentru a citi mai multe!
Pagina 1 din 1


Ce părere au oamenii despre Technical Writing for Engineering Professionals

0 evaluări / 0 Recenzii
Ce părere aveți?
Evaluare: 0 din 5 stele

Recenziile cititorilor