05.05.2015 Views

Green Book Fall 2013 Version - Web Access for Home - Manhattan ...

Green Book Fall 2013 Version - Web Access for Home - Manhattan ...

Green Book Fall 2013 Version - Web Access for Home - Manhattan ...

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

MANHATTAN COLLEGE<br />

MECHANICAL ENGINEERING DEPARTMENT<br />

A GUIDE TO TECHNICAL COMMUNICATION<br />

(FORMERLY THE REPORT AND PRESENTATION<br />

PREPARATION MANUAL)<br />

FALL <strong>2013</strong>


A Guide to Technical Communication<br />

Copyright © 2011-<strong>2013</strong> by the Mechanical Engineering Department<br />

of <strong>Manhattan</strong> College.<br />

All Rights Reserved.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page i


A Guide to Technical Communication<br />

Cite as: A Guide to Technical Communication, <strong>Fall</strong> <strong>2013</strong>. Mechanical Engineering<br />

Department, <strong>Manhattan</strong> College, Riverdale, NY. Downloaded on [DD Month YYYY].<br />

Last Updated 8/22/<strong>2013</strong><br />

Page ii


A Guide to Technical Communication<br />

Table of Contents<br />

Acknowledgments............................................................................................................... v<br />

Preface to the <strong>Fall</strong> <strong>2013</strong> Edition......................................................................................... vi<br />

Preface to the <strong>Fall</strong> 2011 Edition........................................................................................ vii<br />

Introduction ......................................................................................................................... 1<br />

What Makes Technical Writing Different? ......................................................................... 2<br />

How to Communicate Effectively ...................................................................................... 3<br />

Structure of an Effective Report ..................................................................................... 3<br />

Report Preparation .......................................................................................................... 4<br />

Layout, Grammar, and Usage ......................................................................................... 4<br />

Making a Report “Read Well” ........................................................................................ 4<br />

Numbers, Calculations, Units, and Equations ................................................................ 5<br />

Figures and Tables .......................................................................................................... 7<br />

Proofreading: You Still Need To Do It! ......................................................................... 7<br />

Organization and Archival .............................................................................................. 8<br />

Presentation of Graphical and Tabulated Data ................................................................... 9<br />

Placement ........................................................................................................................ 9<br />

Captions .......................................................................................................................... 9<br />

Photographs..................................................................................................................... 9<br />

Drawings ....................................................................................................................... 10<br />

Graphs ........................................................................................................................... 10<br />

Tables ............................................................................................................................ 15<br />

Guidelines <strong>for</strong> References ................................................................................................. 17<br />

Referencing of Works in a Document .......................................................................... 17<br />

Formats <strong>for</strong> References ................................................................................................. 17<br />

Laboratory and Technical Reports .................................................................................... 21<br />

Cover Page .................................................................................................................... 21<br />

Abstract ......................................................................................................................... 21<br />

Table of Contents .......................................................................................................... 22<br />

Introduction and Analysis ............................................................................................. 22<br />

Experimental Apparatus and Procedure ........................................................................ 23<br />

Results and Discussion ................................................................................................. 24<br />

Conclusions ................................................................................................................... 25<br />

References ..................................................................................................................... 25<br />

Appendices .................................................................................................................... 25<br />

Optional Sections .......................................................................................................... 26<br />

Format <strong>for</strong> Short Laboratory Reports ............................................................................... 28<br />

Design Project Reports - General Instructions .................................................................. 29<br />

Format <strong>for</strong> Design Project Proposals ................................................................................ 30<br />

Cover Page .................................................................................................................... 30<br />

Table of Contents .......................................................................................................... 30<br />

Introduction ................................................................................................................... 30<br />

Proposal......................................................................................................................... 30<br />

Schedule ........................................................................................................................ 30<br />

Format <strong>for</strong> Design Project Progress Reports .................................................................... 31<br />

Last Updated 8/22/<strong>2013</strong><br />

Page iii


A Guide to Technical Communication<br />

Cover Page .................................................................................................................... 31<br />

Table of Contents .......................................................................................................... 31<br />

Introduction ................................................................................................................... 31<br />

Progress to Date ............................................................................................................ 31<br />

Schedule ........................................................................................................................ 31<br />

Calculations (If necessary) ............................................................................................ 31<br />

Format <strong>for</strong> Design Project Final Reports .......................................................................... 32<br />

Cover Page .................................................................................................................... 32<br />

Table of Contents .......................................................................................................... 32<br />

Executive Summary ...................................................................................................... 32<br />

[Your Project Title] ....................................................................................................... 32<br />

Reflections .................................................................................................................... 32<br />

Calculations................................................................................................................... 32<br />

Acknowledgments......................................................................................................... 32<br />

References ..................................................................................................................... 33<br />

Appendices .................................................................................................................... 33<br />

General Guidelines <strong>for</strong> Oral Presentations ....................................................................... 34<br />

Initial Considerations .................................................................................................... 34<br />

Preparation Guidelines .................................................................................................. 34<br />

Slide Design and Creation ............................................................................................ 35<br />

To Outline or Not to Outline? That is the Question ...................................................... 35<br />

Use of Graphics ............................................................................................................. 36<br />

Presentation Issues ........................................................................................................ 36<br />

General Guidelines <strong>for</strong> Electronic Mail ............................................................................ 38<br />

Just Because It’s Fast Doesn’t Mean It Should Be In<strong>for</strong>mal ........................................ 38<br />

Who Will Be Reading Your Email? ............................................................................. 39<br />

Subject Line .................................................................................................................. 39<br />

Keep the Length Appropriate ........................................................................................ 40<br />

Format ........................................................................................................................... 40<br />

Write an Initial Draft, Then Revise! ............................................................................. 40<br />

Attachments .................................................................................................................. 40<br />

Proofreading, You Still STILL Need to Do It! ............................................................. 40<br />

Don’t Hit Send in Anger ............................................................................................... 41<br />

Closing and Signatures ................................................................................................. 41<br />

Emails versus SMS (Text) Messages ............................................................................ 42<br />

General Guidelines <strong>for</strong> Voicemail .................................................................................... 43<br />

References ......................................................................................................................... 44<br />

Appendix A: Format <strong>for</strong> Cover Sheets ............................................................................. 45<br />

Appendix B: Sample Presentations ................................................................................... 50<br />

Experimental Study Slides ............................................................................................ 51<br />

Design Study Slides ...................................................................................................... 55<br />

Last Updated 8/22/<strong>2013</strong><br />

Page iv


A Guide to Technical Communication<br />

Acknowledgments<br />

A guide like this is not a single-person ef<strong>for</strong>t. While I have been heading up the<br />

updates and revisions to this guide, it would be the height of pretense to claim that I have<br />

done this on my own. Many people, whether they realize it or not, have been instrumental<br />

in making this document what it is. First, the Mechanical Engineering faculty, past and<br />

present, have been responsible <strong>for</strong> putting together the original version of the <strong>Green</strong><br />

<strong>Book</strong>, as well as offering edits and advice <strong>for</strong> this new, enhanced version. Second, other<br />

faculty members outside the department have expressed interest, and conversations with<br />

them have given me ideas on enhancements. Third, the alumni and students of this<br />

department, the ultimate beneficiaries of this work, have been instrumental <strong>for</strong> shaping<br />

this guide. Through watching what aspects of technical communication they find most<br />

challenging and listening to their suggestions, I have attempted to mold this guide to suit<br />

their needs. Finally, I must thank the College administration, which has been generous<br />

with summer grants and stipends to fund this ef<strong>for</strong>t.<br />

John C. Leylegian<br />

June <strong>2013</strong><br />

Last Updated 8/22/<strong>2013</strong><br />

Page v


A Guide to Technical Communication<br />

Preface to the <strong>Fall</strong> <strong>2013</strong> Edition<br />

This manual can improve your career.<br />

This sounds like a far-fetched claim, doesn’t it? Don’t dismiss it outright.<br />

When I first read this manual, it was a guide <strong>for</strong> the correct <strong>for</strong>mat <strong>for</strong> reports to be<br />

written by the students of the Mechanical Engineering Department at <strong>Manhattan</strong> College.<br />

However, after reading my first batch of reports while teaching the Thermal-Fluids<br />

Laboratory, I realized that knowing the correct <strong>for</strong>mat <strong>for</strong> a report means precious little if<br />

a student doesn’t know what constitutes good technical writing.<br />

My path as an engineer has taken me through many different environments in many<br />

different institutions since I began my undergraduate engineering studies. My motivation<br />

<strong>for</strong> the “reboot” of the <strong>Green</strong> <strong>Book</strong> was to take the experiences I have had when it comes<br />

to some of the “soft skills” in engineering, particularly communication, and present them<br />

in a manner which could benefit you by improving your own communication skills<br />

The first edition of this new <strong>Green</strong> <strong>Book</strong> was released <strong>for</strong> the <strong>Fall</strong> 2011 semester, and<br />

thanks to the useful feedback from the faculty and students of this department, I have<br />

fine-tuned this guide, adding more new material wherever possible without obscuring the<br />

main idea of the guide: that a good, organized story is all you need to be able to<br />

communicate your ideas to your peers, managers, customers, the public, or anyone else<br />

who is counting on those ideas.<br />

The <strong>Fall</strong> <strong>2013</strong> Edition features new sections on email communications and voicemails.<br />

Based on my own experiences, as well as comments made by recent graduates, it is my<br />

belief that in<strong>for</strong>mation like this would be useful, and my hope is that students will agree.<br />

So back to my grandiose claim. Why do I think that this pdf can improve your career?<br />

When I listen to the Consultors Committee at their semi-annual meetings, I rarely hear<br />

them say, “I wish students here got more Heat Transfer,” or “Why don’t your graduates<br />

know the difference between Pappas’ Theorem and Stokes’ Theorem?” What I do hear<br />

them say is, “New hires need to work on their writing skills,” or “Our newest engineers<br />

have to work on their presentation skills.” Just like any other skill, communication takes<br />

time and practice to cultivate. If you work on it be<strong>for</strong>e you finish your studies, you will<br />

have an advantage when looking <strong>for</strong> a job. If you continue to work on it after you leave<br />

here, you will have an advantage as you try to advance your career.<br />

Take this guide, read it, apply the lessons it provides, and give feedback on it. It will<br />

be worth it.<br />

John C. Leylegian<br />

June <strong>2013</strong><br />

Last Updated 8/22/<strong>2013</strong><br />

Page vi


A Guide to Technical Communication<br />

Preface to the <strong>Fall</strong> 2011 Edition<br />

In my two decades in the engineering field, I have learned that there is an “engineer’s<br />

myth.” This myth is that engineers are these people who sit in cubicles day in and day<br />

out, and don’t do much beyond crunching numbers, writing code, and running<br />

experiments. I quickly learned (even be<strong>for</strong>e I completed my bachelor’s degree) that a<br />

huge part of an engineer’s time is spent in communication. Whether it is in writing<br />

reports, assembling and delivering presentations, or even crafting proper e-mail<br />

correspondence, if an engineer is unable to communicate what he or she sees on the<br />

screen, in the experimental results, or on the scratch pad, those nuggets of wisdom will<br />

stay there.<br />

I must admit that this scared me a little bit. I never liked writing, and I hated getting in<br />

front of a group of people and speaking. However, I found that when I was writing and<br />

talking about stuff I liked, it wasn’t nearly as difficult. It became easier <strong>for</strong> me to do, but I<br />

still needed work. I got plenty of practice in graduate school, since writing and presenting<br />

are large parts of the graduate experience. It was there that my skills improved markedly,<br />

mostly because I was given the key to effective writing and speaking.<br />

When I started working in industry. I was routinely tasked to write reports, make<br />

presentations, and even proofread others’ work, in addition to my technical duties. I<br />

strongly believe that my ability to communicate, just as much as my technical prowess,<br />

was instrumental to not only my advancement, but also to my ability to take on side<br />

work, and to finally make the transition back to academia.<br />

If all of this doesn’t convince you of the importance of good communication skills, let<br />

me tell you the story of Dr. John Houbolt. Dr. Houbolt was an aerospace engineer<br />

working <strong>for</strong> NASA back in the early days of manned space exploration. He was an expert<br />

in rendezvous, the maneuvering of two spacecraft such that they arrive in the same orbit<br />

and within visual contact. He led committees exploring and studying the different types<br />

of rendezvous, specifically applied to its usefulness in a manned lunar mission. He and<br />

his colleagues determined that Lunar Orbit Rendezvous, or LOR (the meeting of two<br />

spacecraft in lunar orbit) would decrease the required liftoff weight of a lunar mission by<br />

roughly 50 percent.<br />

What did Houbolt do? He talked about his discovery, to anyone who would listen. He<br />

gave several briefings to engineers at NASA and the U. S. Air Force. However, there was<br />

significant resistance. In addition to the skepticism surrounding the weight savings,<br />

rendezvous was an issue. While rendezvous in space is something we take <strong>for</strong> granted<br />

today, in 1960 it had never been done. In fact, the United States had not even launched a<br />

human into space yet! If rendezvous in lunar orbit failed, astronauts could be stranded.<br />

Un<strong>for</strong>tunately, the skeptics were not even going to check the calculations and see if the<br />

concept had any merit. It looked like there was enough prejudice against LOR that it<br />

would be dismissed outright.<br />

Houbolt was determined to let LOR get a fair shake, and he knew that to do it he<br />

would have to share the idea with the NASA leadership. In two letters written to the<br />

NASA Associate Administrator and a two-volume technical report, Houbolt thoroughly<br />

explained the concept and how it would be able to meet the deadline set by President<br />

Last Updated 8/22/<strong>2013</strong><br />

Page vii


A Guide to Technical Communication<br />

Kennedy (they had less than a decade to land a man on the moon). It was risky – Houbolt<br />

knew that going over as many heads as he did could cost him his job. It did pay off<br />

though, and LOR was given a chance to compete against other types of lunar missions.<br />

With further presentations and reports, LOR was chosen as the model <strong>for</strong> the Project<br />

Apollo missions.<br />

In the end, it didn’t matter that LOR was the best way to get men to the moon. It did<br />

matter that the main champion of the concept was able to communicate the idea to the<br />

right people in order <strong>for</strong> it to be considered, even in the face of seemingly impossible<br />

opposition. I hope that this story illustrates the value of good communication skills to all<br />

of you.<br />

John C. Leylegian<br />

August 2011<br />

Last Updated 8/22/<strong>2013</strong><br />

Page viii


A Guide to Technical Communication<br />

Introduction<br />

Written and oral communication skills are very important in our society. In particular,<br />

an engineer is frequently called upon to explain his or her work to an audience. The<br />

audience may be wide-ranging, such as radio or television, a room full of people, or just<br />

the boss. The ability to write and speak well in these situations often accounts <strong>for</strong> who<br />

advances in an organization. Professional presentation needs to be developed in addition<br />

to proper grammar and fluency of style. Development of professional presentation ability<br />

is the purpose of this manual.<br />

In the undergraduate curriculum, instructors regularly require written or oral reports in<br />

a style that is more <strong>for</strong>mal than the typical homework assignments, tests and class<br />

participation <strong>for</strong>mat. This manual serves as a guide <strong>for</strong> the preparation of such reports in<br />

courses offered by the Mechanical Engineering Department. Previous versions of report<br />

writing manuals were developed <strong>for</strong> the types of reports and presentations a student may<br />

be expected to deliver in a given class. However, one important item has been left out:<br />

how does one write or speak in the proper manner <strong>for</strong> technical reports and presentations?<br />

There<strong>for</strong>e, this manual not only addresses the proper structure <strong>for</strong> reports and<br />

presentations, but also how to write and speak properly.<br />

Your instructor will expect you to follow the <strong>for</strong>mat indicated <strong>for</strong> reports in all courses<br />

that require report writing and presentation unless he or she indicates otherwise. Keep<br />

this manual <strong>for</strong> reference throughout your undergraduate program, but note that this<br />

manual is a work in progress (as it should be). Any input, comments or suggestions are<br />

always welcome. Remember that this manual is to serve you, the student, to introduce<br />

you to proper technical communication.<br />

When you commence your working career, pay close attention to the <strong>for</strong>mat expected<br />

of you in a new environment. Know what is expected of you, but hopefully the lessons<br />

learned here will give you an edge.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 1


A Guide to Technical Communication<br />

What Makes Technical Writing Different?<br />

No doubt, by this time you have written many papers, essays and reports <strong>for</strong> different<br />

teachers and professors, both in high school and college. However, this is technical<br />

writing, and technical writing is a VERY different undertaking than what you have<br />

probably done to date. The main difference between what you have done in the past and<br />

good technical writing is that you must be clear, concise, and complete in your reports.<br />

In industry you will often be called upon to give written and oral reports. Employers<br />

of engineering graduates around the country fault graduates not <strong>for</strong> their technical<br />

knowledge, but <strong>for</strong> their poor communication skills. If you opt <strong>for</strong> graduate school and a<br />

possible career in academia, you will definitely need to know how to write and how to<br />

speak. Reports, theses, papers, articles, lectures, talks at conferences… you’ll need to do<br />

them all not to mention a thesis or dissertation and the associated defense.<br />

There are very important reasons <strong>for</strong> this style, which no doubt runs counter to what<br />

you have done in the past. The first reason is that the audience <strong>for</strong> technical reports is<br />

very different. In a literature class, <strong>for</strong> example, the professor is the only one reading your<br />

paper, and he or she will most likely read it from cover to cover, poring over every word.<br />

In an engineering firm, on the other hand, several people may be reading what you write,<br />

and most of them will not read the entire work. 1 Sometimes it is because they only need<br />

to read the parts most essential to their work. Sometimes it is because they just don’t have<br />

the time to read every page of every report they need to review. 2 In any event, the<br />

technical literature reader needs to identify the in<strong>for</strong>mation most important to them as<br />

quickly as possible. They need to be able to understand the point you are trying to get<br />

across, without trying to interpret your data <strong>for</strong> themselves, they need to do so in<br />

language they can readily understand, and they need to find the in<strong>for</strong>mation they need<br />

where they expect it to be in the report. Put simply; don’t make the reader work harder<br />

than necessary to get the story you’re trying to tell. An important item that should be<br />

given a serious consideration in any technical writing is the focus of the report. A<br />

technical report conveys a point or some points to readers, e.g., make conclusions <strong>for</strong> a<br />

lab result or present some analytical model. All arguments in the report should be related<br />

to the point(s) of the report. The author may go a little off track by discussing some<br />

related topic but must be careful not to discuss them to the extent that dominates the<br />

report. For example, if a report is written about results related to the cooling channel in an<br />

engine the author might write some general description of the engine but this description<br />

should not overwhelm the focus of the report, which is cooling channels.<br />

Now think about the textbooks you have read <strong>for</strong> your various science and engineering<br />

courses. Do you read them cover to cover, or do you pick and choose the passages you<br />

need to read? Are the best textbooks written in obscure, obtuse language, or are they<br />

written plainly and simply? Strive <strong>for</strong> that level of clarity in your writing. It’s not easy,<br />

and it takes time, but with ef<strong>for</strong>t it is possible.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 2


A Guide to Technical Communication<br />

How to Communicate Effectively<br />

Here are a few suggestions <strong>for</strong> writing. These tips will help your reports look<br />

professional, and make them easy to read and understand.<br />

Structure of an Effective Report<br />

You must always remember that the key to good technical writing is to tell a good,<br />

coherent story. The different sections of a report just provide a framework, so that a<br />

reader can get to the parts most important to him or her in a hurry. The organization of<br />

these sections grows out of the need to tell a story in order, not the other way around.<br />

Later on in this manual the details of different types of reports will be discussed.<br />

However, regardless of the type of report, the order of the story will not change. The<br />

body of the report (excluding abstract, table of contents, references and appendices – but<br />

more on those later) will follow this order: 2<br />

Introduce the Problem<br />

Your report will most likely address some engineering problem; it can be collection<br />

and analysis of some experimental data, or possibly the generation of a new design based<br />

on an objective subject to some constraints. In either event, describing the problem is the<br />

first thing that needs to be done. Depending on the type of report, you should be<br />

answering one or more of the following questions:<br />

Why are these data useful?<br />

What is your proposed design supposed to do?<br />

What have other researchers/engineers done in the past to try to solve this problem?<br />

Is there any underlying theory to better frame and describe the challenges of the<br />

problem?<br />

Describe Your Solution<br />

Now that the problem is framed, tell the reader how you solved it. If it is an<br />

experimental study, what apparatus did you use? What data did you collect? If it is an<br />

analytical study, what theory did you develop or utilize to describe the phenomenon? If it<br />

is a design project, explain the design you developed.<br />

Tell What You Learned<br />

This section is an interesting part of a report. Now that you have presented your<br />

experimental data, you can talk about what they mean. How do they relate to other<br />

studies per<strong>for</strong>med in the past? Did you see anything unusual? What do you recommend<br />

<strong>for</strong> future work in this field? If it’s a design project, what would you have done<br />

differently based on what you know now?<br />

Don’t Let Your Story “Bleed”<br />

We’ve established the parts of a report. It is important that this order be respected. In<br />

other words, make sure that in<strong>for</strong>mation that should be in one part of a report doesn’t<br />

“bleed” into another part. This will disrupt the flow of the story, and could lose the<br />

reader. In addition, if someone is looking <strong>for</strong> specific in<strong>for</strong>mation, having it in the wrong<br />

part of the report, the reader might not find it.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 3


A Guide to Technical Communication<br />

Report Preparation<br />

All laboratory reports are to be produced using computer software, mainly word<br />

processors and drawing software – no handwriting or hand drawing is permitted. This<br />

shouldn’t be a problem, since everybody has a computer, or access to one. Write your<br />

reports as professional reports (not school exercises); pretend that the work was done to<br />

examine a specific phenomenon <strong>for</strong> a customer and write it accordingly.<br />

When writing any kind of report, unless a style sheet tells you otherwise, start each<br />

section on a new page, with a clear, e.g., bold, heading title.<br />

Layout, Grammar, and Usage<br />

When possible, use templates <strong>for</strong> ease of <strong>for</strong>matting. However, if a template is not<br />

provided, type single spaced, and use an easy-to-read font type and size. Commonly used<br />

fonts are Times New Roman (serif font) and Arial (sans serif font). Font sizes of 10-12<br />

points are most appropriate. Number all pages, except the title page. Pages be<strong>for</strong>e the<br />

body of the report (e.g. Abstract, Table of Contents) should be numbered using Roman<br />

numerals; all other pages should be numbered using Arabic numerals.<br />

Neatness and clarity, as well as the proper use of the English language, are essential.<br />

Reports should be correctly assembled be<strong>for</strong>e submittal, and the entire report should be<br />

identically <strong>for</strong>matted, even though different people may have written different parts.<br />

Correct spelling is important. Read aloud your report when completed. This may help<br />

you to correct a passage that is not as clear as it seemed when you wrote it. Do not use<br />

contractions in a technical report. They are fine in other, less <strong>for</strong>mal documents (e.g.<br />

this guide).<br />

Making a Report “Read Well”<br />

Editing <strong>for</strong> style is something that some authors prefer to do towards the end of the<br />

writing process; others are constantly editing <strong>for</strong> style. Whichever way you prefer,<br />

remember that a large portion of where many students’ reports fall short is <strong>for</strong> style. Style<br />

is one of the things that make a report readable. Here are some things you can do to<br />

improve style: 1<br />

Avoid Unnecessary Words<br />

One of the most common issues seen in technical writing is the use of unnecessary<br />

words. It’s as if people think that more words automatically mean better technical<br />

writing! More often than not, the opposite is true. One way to remove unnecessary words<br />

is to avoid redundancies:<br />

• Change “the woman had a set of twins” to “the woman had twins.”<br />

• Change “the fuel-rich flame was green in color” to “the fuel-rich flame was green.”<br />

• Change “acids tend to be sour tasting” to “acids tend to be sour.”<br />

A second way is to avoid “inflated phrases.” For instance:<br />

• Change “the increase in current is due to the fact that the conductor was heated” to<br />

“the increase in current is because the conductor was heated.”<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 4


A Guide to Technical Communication<br />

• Change “salt air has a corrosive effect on untreated metal” to “salt air corrodes<br />

metal.”<br />

The famous British author George Orwell (1903-1950) had two rules <strong>for</strong> writing:<br />

If it is possible to cut a word out, cut it out.<br />

Never use a long word when a short one will do.<br />

Granted, one can take this too far (cutting out so many words that the point you are trying<br />

to get across becomes obscured), but proofreading should catch this. Albert Einstein<br />

summed it up best:<br />

Everything should be made as simple as possible, but not simpler.<br />

Strive <strong>for</strong> clarity, conciseness and accuracy in your writing.<br />

Voice, Tense, and Use of First Person<br />

The difference between writing in the active and passive voice is whether the writer<br />

wishes to emphasize the agent or the object of a given action. In many cases, this means<br />

that the passive voice is preferred – in an experimental report, <strong>for</strong> instance, you want to<br />

emphasize what you did, not the fact that you did it. You should not slavishly adhere to<br />

this rule though. There are times when a passage is more difficult to read in the passive<br />

voice. At those times, write in the active voice. Remember, readability is paramount.<br />

Be sure to use appropriate verb tenses. In general, your text should flow<br />

chronologically. Remember that you are recounting what was done, not what you are<br />

doing or what you will do. There<strong>for</strong>e, past tense will be used quite extensively. Only use<br />

the present and future tenses where absolutely required.<br />

Once you move from the past to the present, stay in the present unless there is a<br />

compelling reason to use the past tense. First person plural, i.e. “we”, is appropriate in<br />

many sentences – again, it’s all about making yourself understood. If writing in the first<br />

person, active voice is the most effective way to get your point across in a particular<br />

sentence, just go with it.<br />

Avoid the “Gotchas”<br />

One point that often gets glossed over is that when you write something, you must be<br />

prepared to back it up. There are two ways one can back up a statement. The first is by<br />

citing your own current work: “As seen in Fig. 3, the relationship between Seebeck<br />

voltage and temperature is linear.” The second is by citing previous work in the field: “In<br />

Reference 4, dimensional analysis was used to prove that friction factor is a function of<br />

Reynolds number and relative roughness.”<br />

Numbers, Calculations, Units, and Equations<br />

Numbers one through ten are expressed as words; other numbers are expressed as<br />

numbers.<br />

Unless your professor tells you otherwise, a good rule of thumb <strong>for</strong> the number of<br />

significant figures is the following: Experimental uncertainties should be rounded to one<br />

significant figure, unless the leading digit in the uncertainty is a 1. In that case the<br />

uncertainty should be rounded to two significant figures. Then, the last significant figure<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 5


A Guide to Technical Communication<br />

in a stated value should be of the same order of magnitude as the uncertainty. Even when<br />

your results have no stated uncertainties, remember that the number of significant figures<br />

you use is indicative of the uncertainty you expect. In other words, if you state a<br />

temperature of 100.002°C, you are suggesting that your error is on the order of 0.001°C,<br />

whether you realize it or not! 3<br />

Create all equations using an equation editor. Using the Equation button on the Insert<br />

tab of Microsoft Word (versions 2007 and later) can sometimes result in equations that<br />

are “compressed” so that symbols which should be the same size are not always done so.<br />

Here’s an example of an equation created using this tool:<br />

<br />

<br />

(3)<br />

Note that the symbols in the fraction are smaller than the other symbols in the equation.<br />

Look at your textbooks – are the equations in these books laid out that way? An easy way<br />

to get better-looking equations is to use the Object button (it’s just to the left of the<br />

Equation button on the Insert ribbon). On the pop-up window, select “Microsoft Equation<br />

3.0” and create your equation using the pull-down menus. Here is the same equation<br />

created using Microsoft Equation. Note the difference.<br />

<br />

x<br />

<br />

y <br />

2<br />

<br />

max<br />

<br />

xy<br />

2<br />

<br />

(3)<br />

<br />

Equations are typically centered on a line. If you are going to refer to back to<br />

equations you have already provided, these equations should be numbered. Number the<br />

equations with a number in parentheses to the right of the equation. Equations should be<br />

numbered in the order in which they appear. Equation numbers should be right-justified<br />

on the line, as was done in the two examples above. To achieve this effect, you can set up<br />

a style in Microsoft Word with a center tab stop at the center of the line, and a rightjustified<br />

tab stop at the right margin. When you refer to equations in the text, they should<br />

be mentioned by number, e.g., “In Equation (1) we see…”, or “Equations (3)-(5) outline<br />

the iterative method to determine temperature.” However, sample calculations and<br />

uncertainty analyses can be done using a mathematical program, such as Mathcad.<br />

Make sure you <strong>for</strong>mat numbers and equations properly, even when they are in the<br />

body of the text. That means never use the <strong>for</strong>mat 46E-4; this should be 46×10 -4 . (Why<br />

not?) Also, never use the <strong>for</strong>mat x^2; this should be x 2 . Formatting of superscripts and<br />

subscripts, adding italics, etc., in text is relatively easy to do, and finding special<br />

characters (including Greek letters) is also straight<strong>for</strong>ward. If you don’t know how to do<br />

it, ask someone. Here are some basic tips <strong>for</strong> proper <strong>for</strong>matting of mathematical<br />

expressions so that your work looks professional:<br />

Scalar variables indicated by upper and lowercase Latin characters (A, B, C, x, y, z)<br />

should be italicized.<br />

Scalar variables indicated by lower case Greek characters (α, β, γ, δ, ε, ω) should be<br />

italicized. Upper case Greek characters (Δ, Θ, Π, Σ, Φ) are not italicized.<br />

2<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 6


A Guide to Technical Communication<br />

<br />

<br />

<br />

Vectors should either be indicated with an arrow ( x ), or should be bold type without<br />

italics (x).<br />

Multiplication of scalar variables should be written as ab, not ab, a·b, or a*b.<br />

Exponential, logarithmic, and trigonometric functions (exp, ln, sin) should not be<br />

italicized.<br />

Make sure there is sufficient space be<strong>for</strong>e and after the equation, so it doesn’t look<br />

crowded.<br />

It is interesting to note that some of these rules have changed over time, and will<br />

probably continue to do so. For instance, common dimensionless groups such as<br />

Reynolds number (Re), Prandtl number (Pr), etc. were never italicized, just like<br />

functions. However, it has become common to italicize these abbreviations as well.<br />

All numbers should have appropriate units (unless the number is dimensionless, e.g.<br />

Reynolds Number – by the way, note the lack of apostrophe on “Reynolds”). Do not mix<br />

units in a report: select either SI or British units, or provide the secondary unit type in<br />

parentheses (e.g. 1 in (25.4 mm)). Write units in short hand (e.g. “ft” not “feet”)<br />

Figures and Tables<br />

If you provide a figure or table, it MUST be cited in the text. All figures and tables<br />

need captions. Captions should include numbers, e.g., Figure 1, Table 1, etc. These<br />

numbers should be in the order in which they are cited in the text. Figure captions are<br />

below the figures, not above. Table captions, however must be placed above the table.<br />

Figure and table captions should be descriptive, e.g.:<br />

Figure 3: Comparison of experimental and theoretical friction factors as a function<br />

of Reynolds Number.<br />

Note that you may use the cross-reference capability that is available in most word<br />

processing software. This feature is useful in case a new figure, table, equation or<br />

reference is added. The numbers will automatically shift and no manual numbering is<br />

needed.<br />

There will be more in<strong>for</strong>mation about developing effective graphs later in this manual.<br />

Proofreading: You Still Need To Do It!<br />

How does a group make sure that all parts are correctly <strong>for</strong>matted, and that proper use<br />

is assured? By proofreading! Some people think that in the age of spellcheckers that<br />

proofreading is no longer necessary. Spellcheckers will identify words that are not in the<br />

dictionary, not misspelled words. A spellchecker will not be able to tell you when to use<br />

“they’re,” “there,” or “their.” A spellchecker probably doesn’t know the difference<br />

between “it’s” and “its” (do you?). Proofreading will not only spot misspelled words, it<br />

can also correct organizational problems, find unnecessary words, and all of the other<br />

pitfalls identified above.<br />

If you are writing a report as part of a group, proofreading will help spot mistakes<br />

more easily. Getting a fresh set of eyes on the portions of the report you didn’t write can<br />

help detect mistakes that you aren’t able to see.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 7


A Guide to Technical Communication<br />

Proofreading only takes a few minutes, and the payoff is well worth the investment of<br />

time.<br />

Organization and Archival<br />

If you are working on a long-term (one or two semester long) design project, you will<br />

most likely be publishing several documents regarding the same project; <strong>for</strong> example, a<br />

proposal at the outset, periodic progress reports, and culminating with a final report.<br />

Some of the narrative of earlier reports should be useful in subsequent reports. There<strong>for</strong>e,<br />

be sure to save your reports on <strong>for</strong> later use. There are now several different options,<br />

including flash drives, <strong>Manhattan</strong> College’s remote drive (the “<strong>Home</strong> Server”), Google<br />

Docs, Dropbox, and the list goes on. They all have their advantages and disadvantages. If<br />

you have done a good job on your proposal, the task of writing your progress reports will<br />

be easier. Likewise good proposals and progress reports lessen the anguish of writing the<br />

final report, the major written requirement <strong>for</strong> such a project.<br />

There are two other very good reasons <strong>for</strong> organizing and archiving your reports. First,<br />

saving copies of your reports can provide a good source of in<strong>for</strong>mation <strong>for</strong> prospective<br />

employers. As was stated above, employers want engineers who can communicate. What<br />

better way to prove this than showing examples of your work? Second, once you get into<br />

industry, it is very possible that some work you have done will be put on hold <strong>for</strong> an<br />

indeterminate length of time – it can be anywhere from weeks to years. If you properly<br />

document the work you have done via reports, memoranda, etc., and archive those<br />

reports, you will be able to pick up where you left off more easily than if you have to<br />

piece material together from memory and sparse notes.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 8


A Guide to Technical Communication<br />

Presentation of Graphical and Tabulated Data<br />

A report or presentation will typically have several figures and/or tables. Figures and<br />

tables are invaluable, because they can convey in<strong>for</strong>mation or ideas in a compact, easyto-understand<br />

manner. Figures include all photographs, drawings, and graphs. Tables are<br />

data presented in a row/column <strong>for</strong>mat.<br />

Placement<br />

Figures and tables are best placed at the top or bottom of a page. Floating text boxes or<br />

frames in Microsoft Word work well when you want to fix figures or tables in these<br />

positions while avoiding unnecessary white space on pages. Be sure to keep sufficient<br />

space (the equivalent of a single line) between the end of the text on a page and a figure<br />

or table.<br />

Captions<br />

All figures and tables must be numbered consecutively and referenced in the narrative<br />

by that number, i.e. no figure or table should appear without being discussed in the<br />

narrative. Figures and tables should have their own numerical sequences, i.e., if a report<br />

has five figures and two tables, the figures will be named “Figure 1” through “Figure 5,”<br />

and the tables will be named “Table 1” and “Table 2.” Captions should appear below a<br />

figure, but above a table.<br />

Captions should be descriptive. For example: “Figure 1. Design of conical-flowderived<br />

wave rider.” Remember that sometimes figures will be taken out of context, and<br />

writing a descriptive caption will help to insure that the figure is not misused. Part of a<br />

descriptive caption includes describing the symbols/lines used in a graph; sometimes the<br />

legend is insufficient to give all of the in<strong>for</strong>mation clearly, and the caption can be used to<br />

clarify things. Captions are not necessary <strong>for</strong> figures or tables in presentations, since<br />

you’re talking about the figures or tables and can describe them fully.<br />

The caption should be in the same font as the rest of the text, but bold or italicized (or<br />

both) so it stands out from the rest of the text. Captions can be inserted using the Insert<br />

Caption button found in the References ribbon of Microsoft Word. Using this feature<br />

allows you to reference the figures in your text using the Cross-Reference feature, and<br />

automatically updates all figure and table numbers if you insert new figures and/or tables<br />

in a document.<br />

Photographs<br />

Include photographs whenever possible and appropriate. For instance, if you are<br />

documenting an experimental study, photograph the experimental apparatus. If it is a<br />

design study, provide photographs of the finished product (if the design was fabricated).<br />

For clarity, include objects such as rulers or common objects, or people in the photograph<br />

to provide a sense of scale. Photographs of individuals require their approval. Similarly,<br />

secure permission to use photographs that are the property of someone else, or at the very<br />

least cite the source <strong>for</strong> such images.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 9


A Guide to Technical Communication<br />

COMBUSTION-FIRED<br />

AIR HEATER<br />

TEST CABIN<br />

6 FT. DIA.<br />

GASL, INC.<br />

BLOWDOWN LABORATORY<br />

Figure 1: Sample photograph using text boxes to identify important items.<br />

Items in the photograph referenced in the text can be identified using text boxes, as<br />

shown in Figure 1. Remember, the objective is clarity, so anything you can do to explain<br />

things more clearly is useful.<br />

Drawings<br />

Drawings should be computer-generated; they should not be hand drawn. Otherwise,<br />

use the same guidelines <strong>for</strong> photographs. An example of a drawing is shown in Figure 2.<br />

Graphs<br />

There are several different types of graphs: the most common used in engineering are<br />

bar, pie, scatter, surface, and contour. Each is used to handle different types of data. To<br />

understand which types of data belong in different types of graphs, we shall review the<br />

different types of data: 4<br />

Types Of Data<br />

Nominal data are differentiated using some naming system. This naming system could<br />

be anything; e.g., color, country of origin, fabrication technique, pay grade, etc. The<br />

naming system could be numerical, but the numbers would not necessarily imply levels<br />

Figure 2: Sample line drawing.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 10


A Guide to Technical Communication<br />

of importance or any other quantitative property.<br />

Ordinal Data are placed in some order based on a scale. In general, the scale does not<br />

allow <strong>for</strong> any arithmetical operations, but relative relations can be drawn from the scale.<br />

An example of ordinal data would be finishing processes <strong>for</strong> a piece of metal, e.g., sawn,<br />

filed, milled, ground. These processes can be classified, (a sawn surface will be much<br />

rougher than a ground surface), but arithmetic operations could not be per<strong>for</strong>med.<br />

Interval Data are measured along an integer scale, i.e., the classifications on the scale<br />

are equidistant. Certain mathematical operations (addition and subtraction) can be<br />

per<strong>for</strong>med on these data.<br />

Ratio Data or Scalable Data can be compared as ratios of one another. Most physical<br />

measurements fall into this category, e.g. mass, speed and time.<br />

Pie Graphs<br />

Pie graphs are most often used to compare nominal or ordinal data. The emphasis is on<br />

the contribution of each category to a whole; there<strong>for</strong>e, pie graphs are especially good to<br />

describe percentages or fractions. 5 For instance, a pie graph would be well-suited to<br />

display the contributions of different types of energy sources (wind, tidal, coal, oil,<br />

nuclear) utilized over a fixed time. A partially-exploded graph is sometimes used to focus<br />

on one of the categories. An example of a pie graph is shown in Figure 3.<br />

Bar Graphs<br />

Bar graphs, like pie graphs, are most often used to compare nominal or ordinal data,<br />

although they are occasionally used to present interval or ratio data. In the latter cases the<br />

graph is often referred to as a histogram. Bar graphs are often used to plot the frequency<br />

of a certain type of data; <strong>for</strong> instance, the number of students receiving various letter<br />

grades in a course. Bar graphs are more versatile than pie graphs in that several sets of<br />

data can be compared easily side by side, e.g., the differences in the distribution of grades<br />

5, 2%<br />

45, 22%<br />

85, 42%<br />

70, 34%<br />

Gas<br />

Coal<br />

Oil<br />

Trash<br />

Figure 3: Usage of various energy sources.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 11


A Guide to Technical Communication<br />

<strong>for</strong> same class taught in different semesters, or the distribution of material hardness from<br />

samples treated at different facilities. Bar graphs are there<strong>for</strong>e well suited <strong>for</strong> drawing<br />

comparisons. 5 A sample bar graph showing comparisons of different data is shown in<br />

Figure 4.<br />

Scatter Plots<br />

Scatter plots are created by using the abscissa (horizontal axis) to represent an<br />

independent variable, and the ordinate (vertical axis) as the dependent variable. Each<br />

datum is then assigned a location on the plot based in the values <strong>for</strong> the independent and<br />

dependent variables. This type of plot is probably the most common type found in the<br />

reports you will be writing. There are some rules you should follow to make sure these<br />

graphs present the data well.<br />

First, depending on the range and behavior of the data, you should choose the most<br />

appropriate way to present your graphs, e.g. linear or logarithmic axes. If you are not<br />

sure, try them and see which types of scales show the important features of the data best.<br />

Sometimes, if the range of data covers multiple orders of magnitudes, a logarithmic axis<br />

may be preferable. If more than one manner is acceptable, keep it as simple as possible.<br />

In other words, if you can get your point across using either a linear or a logarithmic axis,<br />

use the linear axis.<br />

Second, if you are plotting experimental data, you should plot your data as individual<br />

points. Do NOT connect your data with lines, a spline, or a curve fit; unless there is a<br />

reason to do so, e.g. a trend is to be drawn between the data. In addition, experimental<br />

data should have error bars, corresponding to experimental uncertainties. These<br />

uncertainties should be generated through accepted techniques. Ask your instructor if<br />

he/she has not shown you how to do so. On the other hand, if theoretical data are to be<br />

included on a graph <strong>for</strong> comparison, no points should be shown. Rather, connect the<br />

points with a smooth curve (NOT a curve fit) and remove the points themselves. An<br />

300<br />

Air Auto Train<br />

250<br />

People-Miles (Million))<br />

200<br />

150<br />

100<br />

50<br />

0<br />

1940's '50's '60's '70's '80's '90's<br />

Figure 4: People-miles traveled by various means of transportation from 1940’s<br />

through 1990’s.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 12


A Guide to Technical Communication<br />

Dimensionless Temperature<br />

1.0<br />

0.8<br />

0.6<br />

0.4<br />

0.2<br />

Rectangle<br />

Sphere<br />

Cylinder<br />

Theoretical Rectangle<br />

Theoretical Sphere<br />

Theoretical Cylinder<br />

0.0<br />

0 2 4 6 8 10<br />

Fourier Number<br />

Figure 5: Sample scatter plot showing multiple sets of experimental data (points)<br />

with error bars, and theoretical data (curves) utilizing different line styles.<br />

example of this can be seen in Figure 5. In this graph the dimensionless temperatures in<br />

different hot objects are plotted as a function of Fourier Number (a dimensionless <strong>for</strong>m of<br />

time). The symbols represent measured quantities, while the curves are theoretical<br />

predictions based on the equations of heat transfer relevant to the particular problem.<br />

In some cases theoretical data are developed from some experimental inputs. For<br />

example, the drag on a body is based on the projected area, which is a measured quantity.<br />

In that case, the theoretical data should consist of two curves: a lower bound and an upper<br />

bound based upon the uncertainty in the theoretical value.<br />

Third, when several sets of data are presented on the same set of axes, a legend<br />

describing each set should be included. Each set of data points should be distinguished by<br />

dissimilar symbols on the graph (e.g. squares, diamonds, and so on). If two different<br />

dependent variables are to be shown, it may make sense to show them on different<br />

vertical axes (left and right side), like Figure 6.<br />

Note that the precision of the axes is important <strong>for</strong> readability. All labels on a given<br />

axis should have the same precision (same number of decimal places), and this should be<br />

the minimum necessary to accurately represent all of the labels on that axis.<br />

Surface and Contour Plots<br />

Surface and contour plots are useful to show when a dependent variable is a function<br />

of more than one independent variable. Both plots show a single dependent variable in<br />

terms of two independent variables. The contour plot shows an X-Y plane, with the<br />

dependent variable represented by different colors on that plane. A surface plot, on the<br />

other hand, is a three-dimensional rendering, with the dependent variable represented as a<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 13


A Guide to Technical Communication<br />

700<br />

600<br />

500<br />

Power<br />

Efficiency<br />

80<br />

70<br />

60<br />

Power (kW)<br />

400<br />

300<br />

50<br />

40<br />

30<br />

Efficiency (%)<br />

200<br />

20<br />

100<br />

10<br />

0<br />

0<br />

0 2 4 6 8 10<br />

Engine Speed (1000 rpm)<br />

Figure 6: Scatter plots showing two sets of experimental data on different axes.<br />

projecting in the third (Z) dimension. Examples of these plots are shown in Figure 7 and<br />

Figure 8.<br />

It should be mentioned that while a program like Excel is capable of generating these<br />

5<br />

4<br />

3<br />

y<br />

2<br />

1<br />

0 1 2 3 4 5 0<br />

x<br />

z<br />

0.8-1<br />

0.6-0.8<br />

0.4-0.6<br />

0.2-0.4<br />

0-0.2<br />

-0.2-0<br />

-0.4--0.2<br />

-0.6--0.4<br />

-0.8--0.6<br />

-1--0.8<br />

Figure 7: Sample contour plot of the function f(x, y) = sin (xy/2).<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 14


A Guide to Technical Communication<br />

1.0<br />

0.8<br />

z<br />

0.6<br />

0.4<br />

0.2<br />

0.0<br />

-0.2<br />

-0.4<br />

-0.6<br />

-0.8<br />

3<br />

5<br />

4<br />

0.8-1<br />

0.6-0.8<br />

0.4-0.6<br />

0.2-0.4<br />

0-0.2<br />

-0.2-0<br />

-0.4--0.2<br />

-0.6--0.4<br />

-0.8--0.6<br />

-1--0.8<br />

-1.0<br />

0.0 0.5 1.0 1.5 1<br />

2.0 2.5 3.0 3.5 4.0 4.5 5.0 0<br />

2<br />

y<br />

Figure 8: Sample surface plot of the function from Figure 7.<br />

x<br />

types of plots, it is not ideal. Dedicated graphing packages, such as SigmaPlot and<br />

Tecplot, are much better equipped to produce quality contour and surface plots.<br />

Tables<br />

Tables should be <strong>for</strong>matted and planned as carefully as plots – using a table as a “data<br />

dump” is not advisable, unless the purpose is to document raw data in an appendix of a<br />

report. The first column of a table is most typically an independent variable, or a list of<br />

categories. The first row is typically “headings,” or a list of variables. Headings and<br />

categories are often centered (horizontally and vertically) in their respective cells.<br />

The <strong>for</strong>mat <strong>for</strong> the data in the table can be a matter of personal taste. Some prefer the<br />

data to be centered, while others prefer numbers to be right justified, and others may want<br />

Table 1: Temperature versus time data collected at the center of a brass<br />

rectangular prism submerged in a water bath.<br />

Time (s) Temperature (°C)<br />

0.00.2 301<br />

10.00.2 351<br />

20.00.2 411<br />

30.00.2 451<br />

40.00.2 471<br />

50.00.2 501<br />

60.00.2 521<br />

70.00.2 521<br />

80.00.2 521<br />

90.00.2 521<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 15


A Guide to Technical Communication<br />

the data in a single column to have decimal points aligned. Check with the person who is<br />

evaluating your reports <strong>for</strong> their thoughts, but above all, clarity is key. A relatively simple<br />

table with caption is shown in Table 1.<br />

Avoid using heavy shading in tables whenever possible. While using multiple colors<br />

may look good on the screen, they might not look as nice (or be as easy to read) when<br />

printed in black and white. Reproducibility may also be an issue; if you print out a colorshaded<br />

table, and make a black and white photocopy, you might be left with a completely<br />

unreadable graph or table.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 16


A Guide to Technical Communication<br />

Guidelines <strong>for</strong> References<br />

When writing a report, article, or other technical document, often you will call upon<br />

work done by other groups, or work you have already published in another document.<br />

Whenever you are presenting work that is neither new nor original to the authors of the<br />

document, it MUST be referenced. Note the bold, italic, underlined word in all capital<br />

letters. What is the reason <strong>for</strong> the embellishment? If you present work as your own which<br />

is not yours, you have plagiarized. A new set of rules <strong>for</strong> dealing with plagiarism has just<br />

been established across the College, but regardless of the penalty imposed here,<br />

plagiarism is not tolerated in either industrial or scholarly circles. It is theft, pure and<br />

simple. Please consult the Student Handbook <strong>for</strong> the details on the policy.<br />

The rules are simple: if something you write or present is not your own idea, or your<br />

own data, or your own analysis, it must be referenced, unless it is “common knowledge.”<br />

Since the definition of what is common knowledge can be nebulous at times, it is best to<br />

play it safe and provide a reference.<br />

Whenever possible, go to the original reference. For example, if you are researching<br />

something out of a book, but the passage of interest to you was cited from a journal<br />

article, it is better to acquire the article and reference it in your work.<br />

Many different <strong>for</strong>mats exist <strong>for</strong> referencing, and no particular <strong>for</strong>mat is superior, but<br />

certain types of reference <strong>for</strong>mats are more likely to be used in technical literature. In this<br />

department we will use a particular <strong>for</strong>mat <strong>for</strong> references. There is no excuse <strong>for</strong> using an<br />

improper <strong>for</strong>mat <strong>for</strong> references; in fact, publishers will send manuscripts back to authors<br />

<strong>for</strong> improper referencing practices – it has happened. The <strong>for</strong>mat adopted is that of the<br />

American Institute <strong>for</strong> Aeronautics and Astronautics (AIAA), with some minor<br />

modifications. Their guidelines can be found online at the AIAA ScholarOne<br />

Manuscripts Portal. 6<br />

Referencing of Works in a Document<br />

When you want to reference an outside work, it will be done using a superscripted<br />

number, thusly. 1 The superscript is placed after punctuation, e.g., a period, comma,<br />

semicolon, etc. References are numbered in the order in which they are cited, i.e., the first<br />

reference cited is 1, the second is 2, and so on. If two works are referenced <strong>for</strong> the same<br />

sentence, they should be separated with a comma. 3,4 If three or more sequential works are<br />

referenced, it should be done in this manner. 5-7 An easy way to insert references in a<br />

document is to use the Insert Endnote feature in the References ribbon of Microsoft<br />

Word. You will need to make sure the references are numbers, rather than letters or<br />

symbols, and you will need to make sure the references appear in the right location of the<br />

report. A little practice will teach you how to accomplish this.<br />

If a figure or table contains outside work, the reference is placed in the figure or table<br />

caption.<br />

Formats <strong>for</strong> References<br />

Here are the <strong>for</strong>mats <strong>for</strong> the references, with examples of each:<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 17


A Guide to Technical Communication<br />

Periodicals<br />

1<br />

Vatistas, G. H., Lin, S., and Kwok, C. K., “Reverse Flow Radius in Vortex<br />

Chambers,” AIAA Journal, Vol. 24, No. 11, 1986, pp. 1872, 1873.<br />

doi: 10.2514/3.13046<br />

2<br />

Dornheim, M. A., “Planetary Flight Surge Faces Budget Realities,” Aviation Week and<br />

Space Technology, Vol. 145, No. 24, 9 Dec. 1996, pp. 44–46.<br />

3<br />

Terster, W., “NASA Considers Switch to Delta 2,” Space News, Vol. 8, No. 2, 13–19<br />

Jan. 1997, pp. 1, 18.<br />

All of the preceding in<strong>for</strong>mation is required. The journal issue number (“No. 11” in<br />

Ref. 1) is preferred, but the month (Nov.) can be substituted if the issue number is not<br />

available. Use the complete date <strong>for</strong> daily and weekly publications. Transactions follow<br />

the same style as other journals. The DOI (Digital Object Identifier) should be<br />

incorporated in every reference <strong>for</strong> which it is available (see Ref. 1 sample); <strong>for</strong> more<br />

in<strong>for</strong>mation on DOIs, visit www.doi.org or www.crossref.org.<br />

<strong>Book</strong>s<br />

4<br />

Peyret, R., and Taylor, T. D., Computational Methods in Fluid Flow, 2 nd ed., Springer-<br />

Verlag, New York, 1983, Chaps. 7, 14.<br />

5<br />

Oates, G. C. (ed.), Aerothermodynamics of Gas Turbine and Rocket Propulsion,<br />

AIAA Education Series, AIAA, New York, 1984, pp. 19, 136.<br />

6<br />

Volpe, R., “Techniques <strong>for</strong> Collision Prevention, Impact Stability, and Force Control<br />

by Space Manipulators,” Teleoperation and Robotics in Space, edited by S. B. Skaar<br />

and C. F. Ruoff, Progress in Astronautics and Aeronautics, AIAA, Washington, DC,<br />

1994, pp. 175–212.<br />

Publisher, place, and date of publication are required <strong>for</strong> all books. No state or country<br />

is required <strong>for</strong> major cities: New York, London, Moscow, etc. A differentiation must<br />

always be made between Cambridge, MA, and Cambridge, England, UK. Note that series<br />

titles are in Roman type (not italicized).<br />

Proceedings<br />

7<br />

Thompson, C. M., “Spacecraft Thermal Control, Design, and Operation,” AIAA<br />

Guidance, Navigation, and Control Conference, CP849, Vol. 1, AIAA, Washington,<br />

DC, 1989, pp. 103–115<br />

8<br />

Chi, Y. (ed.), Fluid Mechanics Proceedings, NASA SP-255, 1993.<br />

9<br />

Morris, J. D., “Convective Heat Transfer in Radially Rotating Ducts,” Proceedings of<br />

the Annual Heat Transfer Conference, edited by B. Corbell, Vol. 1, Inst. of<br />

Mechanical Engineering, New York, 1992, pp. 227–234.<br />

Reports, Theses, and Individual Papers<br />

10 Chapman, G. T., and Tobak, M., “Nonlinear Problems in Flight Dynamics,” NASA<br />

TM-85940, 1984.<br />

11 Steger, J. L., Jr., Nietubicz, C. J., and Heavey, J. E., “A General Curvilinear Grid<br />

Generation Program <strong>for</strong> Projectile Configurations,” U.S. Army Ballistic Research<br />

Lab., Rept. ARBRL-MR03142, Aberdeen Proving Ground, MD, Oct. 1981.<br />

12 Tseng, K., “Nonlinear <strong>Green</strong>’s Function Method <strong>for</strong> Transonic Potential Flow,” Ph.D.<br />

Dissertation, Aeronautics and Astronautics Dept., Boston Univ., Cambridge, MA,<br />

1983.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 18


A Guide to Technical Communication<br />

Government agency reports do not require locations. For reports such as NASA TM-<br />

85940, neither insert nor delete dashes; leave them as provided. Place of publication<br />

should be given, although it is not mandatory, <strong>for</strong> military and company reports. Always<br />

include a city and state <strong>for</strong> universities. Papers need only the name of the sponsor; neither<br />

the sponsor’s location nor the conference name and location is required. Do not confuse<br />

proceedings references with conference papers.<br />

Electronic Publications and <strong>Web</strong> Pages<br />

CD-ROM publications and regularly issued, dated electronic journals are permitted as<br />

references. Archived data sets also may be referenced as long as the material is openly<br />

accessible and the repository is committed to archiving the data indefinitely. References<br />

to electronic data available only from personal <strong>Web</strong> sites or commercial, academic, or<br />

government ones where there is no commitment to archiving the data are not permitted in<br />

the reference list.<br />

13<br />

Richard, J. C., and Fralick, G. C., “Use of Drag Probe in Supersonic Flow,” AIAA<br />

Meeting Papers on Disc [CD-ROM], Vol. 1, No. 2, AIAA, Reston, VA, 1996.<br />

14<br />

Atkins, C. P., and Scantelbury, J. D., “The Activity Coefficient of Sodium Chloride<br />

in a Simulated Pore Solution Environment,” Journal of Corrosion Science and<br />

Engineering [online journal], Vol. 1, No. 1, Paper 2, URL:<br />

http://www.cp/umist.ac.uk/JCSE/vol1/vol1.html [cited 13 April 1998].<br />

15<br />

Vickers, A., “10-110 mm/hr Hypodermic Gravity Design A,” Rainfall Simulation<br />

Database [online database], URL: http://www.geog.le.ac.uk/bgrg/lab.htm [cited 15<br />

March 1998].<br />

Always include the citation date <strong>for</strong> online references. Break <strong>Web</strong> site addresses after<br />

punctuation, and do not hyphenate at line breaks.<br />

NEVER CITE WIKIPEDIA FOR ANYTHING. EVER. FOR ANYTHING AT ALL.<br />

Wikipedia, like old book-<strong>for</strong>m encyclopedias, are a starting point <strong>for</strong> research. Look into<br />

the references cited in the articles in Wikipedia, then cite them yourself.<br />

Computer Software<br />

16<br />

TAPP, Thermochemical and Physical Properties, Software Package, Ver. 1.0, E. S.<br />

Microware, Hamilton, OH, 1992.<br />

Include a version number and the company name and location of software packages.<br />

Patents<br />

Patents appear infrequently. Be sure to include the patent number and date.<br />

17<br />

Scherrer, R., Overholster, D., and Watson, K., Lockheed Corp., Burbank, CA, U.S.<br />

Patent Application <strong>for</strong> a “Vehicle,” Docket No. P-01-1532, filed 11 Feb. 1979.<br />

18<br />

Girlea, F. and Leylegian, J. C., “Apparatus, Systems, Methods <strong>for</strong> the Production of<br />

Hydrogen,” U. S. Patent 8,263,027, filed 12 Aug. 2009, granted 11 Sep. 2012.<br />

Private Communications<br />

If you receive in<strong>for</strong>mation directly from a person, which cannot be referenced in an<br />

article, book, or paper, it is a private communication, whether it is in-person, over the<br />

telephone, or via email.<br />

19<br />

Pritchard, P. J., Private communication, 12 November 2012.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 19


A Guide to Technical Communication<br />

Provide the name of the source and the date(s) over which the communication<br />

occurred.<br />

Unpublished Papers and <strong>Book</strong>s<br />

Unpublished works can be used as references as long as they are being considered <strong>for</strong><br />

publication or can be located by the reader (such as papers that are part of an archival<br />

collection). If a journal paper or a book is being considered <strong>for</strong> publication, choose the<br />

<strong>for</strong>mat that reflects the status of the work (depending upon whether it has been accepted<br />

<strong>for</strong> publication):<br />

20<br />

Doe, J., “Title of Paper,” Name of Journal (to be published).<br />

21<br />

Doe, J., “Title of Chapter,” Name of <strong>Book</strong>, edited by…, Publisher’s name and<br />

location (to be published).<br />

22<br />

Doe, J., “Title of Work,” Name of Archive, Univ. (or organization), City, State, Year<br />

(unpublished).<br />

Unpublished works in an archive must include the name of the archive and the name<br />

and location of the university or other organization where the archive is held. Also<br />

include any cataloging in<strong>for</strong>mation that may be provided.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 20


A Guide to Technical Communication<br />

Laboratory and Technical Reports<br />

Now that we have described how a report should flow, and have discussed effective<br />

means of communication through graphics, we will get into the actual organization of<br />

technical documents. There are two main types of technical documents covered in this<br />

manual. The first are laboratory reports and technical reports. These reports document<br />

experimental or analytical studies. The sections of these reports are outlined here, with<br />

the similarities, as well as the differences pointed out.<br />

Remember, as stated in the Introduction, if an instructor provides alternate guidelines<br />

on the <strong>for</strong>mat of a report, those alternate guidelines supersede the <strong>for</strong>mat here.<br />

Cover Page<br />

All reports must have a cover page that contains:<br />

Course and section number.<br />

Group number (if the work is being per<strong>for</strong>med by a group).<br />

Name(s) of the student(s) in the group.<br />

Title.<br />

Instructor’s name.<br />

Date experiment per<strong>for</strong>med (if this is a laboratory report).<br />

Date report handed in.<br />

A sample cover page is shown in Appendix A: Format <strong>for</strong> Cover Sheets, and an<br />

electronic version in Word <strong>for</strong>mat is available <strong>for</strong> your use.<br />

A few words about titles: when someone is reviewing a list of reports or articles <strong>for</strong><br />

documents which need to be read, he or she will start with a list of titles. Make your title<br />

as descriptive as possible, in order to make sure that the widest audience possible reads<br />

your report. For instance, “Aerodynamic Characteristics of Two Waverider-Derived<br />

Hypersonic Cruise Configurations” is a far superior title to “Aerodynamics of High<br />

Speed Aircraft.”<br />

Abstract<br />

Give a brief (only about one paragraph), clear indication of what is in the report along<br />

with the primary results or final design characteristics. It should state, in simple<br />

declarative sentences what was attempted and accomplished, how it was accomplished<br />

only if special techniques were utilized, and what was achieved. That is, it should contain<br />

the main results and the main conclusions based on the results. Since the abstract is a<br />

summary of the entire report, you should write your abstract after you have completed all<br />

other parts of the report.<br />

The abstract should be written with the expectation that it will be printed separately<br />

from the report. In fact, technical journals often publish lists of abstracts so that readers<br />

can quickly determine what articles are of interest to them. There<strong>for</strong>e, there should be no<br />

references to figures or tables in the report, works cited, etc. The abstract should be able<br />

to stand alone as a clear succinct summary of the work per<strong>for</strong>med, and should allow a<br />

reader to decide if the work is of sufficient interest to warrant reading the full report.<br />

Here is an example of a well-written abstract, from the NASA Technical Paper<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 21


A Guide to Technical Communication<br />

“Aerodynamic Characteristics of Two Waverider-Derived Hypersonic Cruise<br />

Configurations:” 7<br />

An evaluation was made of the effects of integrating the required aircraft<br />

components with hypersonic high-lift configurations known as waveriders to<br />

create hypersonic cruise vehicles. Previous studies suggest that waveriders offer<br />

advantages in aerodynamic per<strong>for</strong>mance and propulsion airframe integration<br />

(PAI) characteristics over conventional non-waverider hypersonic shapes. A<br />

wind-tunnel model was developed that integrates vehicle components, including<br />

canopies, engine components, and control surfaces, with two pure waverider<br />

shapes, both conical-flow-derived waveriders <strong>for</strong> a design Mach number of 4.0.<br />

Experimental data and limited computational fluid dynamics (CFD) solutions<br />

were obtained over a Mach number range of 1.6 to 4.63. The experimental data<br />

show the component build-up effects and the aerodynamic characteristics of the<br />

fully integrated configurations, including control surface effectiveness. The<br />

aerodynamic per<strong>for</strong>mance of the fully integrated configurations is not comparable<br />

to that of the pure waverider shapes, but is comparable to previously tested<br />

hypersonic vehicle models. Both configurations exhibit good lateral directional<br />

stability characteristics.<br />

Note the fact that not only does the abstract provide a description of what was done, it<br />

also give the reader some specifics on the range of parameters investigated and the results<br />

obtained.<br />

Table of Contents<br />

This is a list containing the section titles and the page numbers on which the sections<br />

begin. Microsoft Word has a built-in Table of Contents function, which will automatically<br />

generate and update your Table of Contents as you assemble your report. Ask your<br />

instructor about this if you do not know how to use this feature.<br />

Introduction and Analysis<br />

These two sections are sometimes written as one; if the in<strong>for</strong>mation is in a single<br />

section, it is referred to simply as the “Introduction.” The Introduction is used to provide<br />

an overview of the problem, and the context within which the problem exists. It also<br />

gives the reader a background to the problem constraints, and required outcomes. It<br />

should familiarize and orient your readers. 5<br />

Introduction<br />

It is important to realize that the title of this section is totally descriptive of its role. It<br />

is to introduce the reader to the report in the same way that you would “introduce a friend<br />

to a third party.” The first element of in<strong>for</strong>mation is the context of the work, which<br />

should be done in a way that is important to the reader. What are the origins of your<br />

interest in the work, and what is the motivation (purpose) <strong>for</strong> the investigation that has<br />

been executed? Be fair – don’t overstate or understate the importance of the work being<br />

done. 5 Given the motivation, the background in<strong>for</strong>mation can next be developed <strong>for</strong> the<br />

reader. It is in this portion of the report that you will introduce material from texts,<br />

handbooks, journal articles, the laboratory handouts, and other available references. You<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 22


A Guide to Technical Communication<br />

should not copy substantial sections of previously printed material (e.g. equations); these<br />

should be summarized with a reference.<br />

Following the motivation and background, the material to be found in the subsequent<br />

sections should be summarized. This will complete the introduction; the reader’s mind<br />

will be prepared <strong>for</strong> what is to follow. The Introduction can (and often should) have<br />

equations in it if they <strong>for</strong>m part of the “background.” However, be careful not to include<br />

unnecessary background material, or to be repetitive.<br />

Note that if this is well done, then all subsequent statements can be fit into a rational<br />

understanding by the reader; if it is not well done, then the reader will expend creative<br />

energies trying to infer what is going on. Reading a report with a poor introduction is a<br />

frustrating experience.<br />

Analysis<br />

The Analysis will introduce the remaining basic equations (i.e., those not yet presented<br />

in the Introduction) and (more importantly) manipulate these into the <strong>for</strong>m required to<br />

interpret and process the experimental data. In some cases, the Analysis Section will<br />

present the equivalent of a “result of the investigation” in that the analytical results will<br />

be separately significant in-and-of themselves. The questions of: “what to include and<br />

what to refer to from previously written materials,” sometimes lead to confusion. In<br />

general, one can answer this question by observing that the analysis must be conceptually<br />

complete…the major steps must be shown…but that lengthy and detailed considerations<br />

are best covered by a reference to their original source. Note that at the conclusion of the<br />

Analysis Section, the reader will be aware of what basic data are required, and what will<br />

be calculated from these data.<br />

Note that “data” is a plural noun; one measurement is a “datum.” Note also that the<br />

symbols must be clearly defined - it is usually appropriate to make use of defining figures<br />

– line drawings are usually the most appropriate in this instance (think of your<br />

textbooks!). All of the symbols to be used should appear in a Nomenclature list (see<br />

below), or described in the text if no Nomenclature list is included.<br />

As a general observation, the Introduction and the Analysis sections should be written<br />

from the perspective that they could have been written be<strong>for</strong>e the experiment was<br />

executed. That is, they will include everything that could have been thought of be<strong>for</strong>e the<br />

work was per<strong>for</strong>med, even if some of it was not realized until the experiment was<br />

finished.<br />

The reader now has the in<strong>for</strong>mation of why the experiment was per<strong>for</strong>med and what<br />

data were desired. The reader is now ready to appreciate how the experiment was<br />

configured to provide the data and what procedures were followed to assure the<br />

correctness of the data.<br />

Experimental Apparatus and Procedure<br />

Sometimes this section is not necessary, particularly when the report is not<br />

documenting an experimental study. In that case, a separate Analysis section (see above)<br />

describes how you did what you did.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 23


A Guide to Technical Communication<br />

If you per<strong>for</strong>med an experiment, this section should provide a schematic<br />

representation of the experimental equipment, including detailed views of unusual or<br />

important components. This in<strong>for</strong>mation is usually a valuable aid in in<strong>for</strong>ming the reader<br />

about the experiment. The sketch can be used to document pertinent dimensions of the<br />

apparatus and it can be used to specify the experimental equipment used <strong>for</strong> the study. If<br />

the procedure used in the experiment is not an established one, it is necessary to include<br />

details of the techniques used. However, it should not be a simple protocol (a set of<br />

instructions). A method section should contain context (“In order to… we…”), and does<br />

not necessarily be in chronological order, but rather should be in the most logical order<br />

<strong>for</strong> the reader to follow. 5 The criterion here is that someone familiar with the general area<br />

of investigation should be able to reproduce your experiments from the in<strong>for</strong>mation given<br />

in this section.<br />

A common question is whether or not to include equations in the Experimental<br />

sections, rather than the Intro/Analysis sections. A good rule of thumb is if the equations<br />

are theoretical in nature, they belong in the Introduction. If they relate to reduction of the<br />

experimental data based on something specific to your experimental setup, they are more<br />

appropriate in the Experimental section.<br />

Results and Discussion<br />

The next section can be a “Results” or a “Results and Discussion” section; if the<br />

<strong>for</strong>mer, a separate “Discussion” section would follow. The basis of selection between two<br />

options is the volume of the results to be presented-and/or-the complexity of trans<strong>for</strong>ming<br />

the primitive results into the final <strong>for</strong>m. Experience is useful in making this decision and<br />

the stylistic tastes of the writer are important in the selection as well. If one-versus-two<br />

sections are used, then the comments below should be interpreted as applying to the<br />

combined section.<br />

Results<br />

This section is the location of all results of the experiment. The results should be<br />

introduced with appropriate prose; do not simply list a set of results such as P 1 = 3.5 in.<br />

of water, T 2 = 50° F, etc. For example: “Figure 3 presents the transient temperature<br />

distributions at different locations along the aluminum rod” or “Table 2 provides …” It is<br />

important to differentiate between primitive and processed results; that is, the reader<br />

should be aware of what was directly observed and what is inferred by calculations based<br />

upon equations in the Analysis section. It is essential that ALL presented figures or tables<br />

be referred to in the text, and have numbered, descriptive captions. The numbers must<br />

follow the sequence in which they are introduced to the reader.<br />

The results section should focus on presenting the data which answer the questions<br />

asked in the Introduction of the report. Irrelevant results (e.g. raw data) should not be<br />

presented here; rather, show them in an Appendix (see below). 5<br />

It is always appropriate to provide the reader with uncertainties. Their inclusion<br />

expands the in<strong>for</strong>mation content beyond that provided by the base numbers themselves.<br />

At this point in the report, the reader has access to all of the essential and objective<br />

in<strong>for</strong>mation that was available to the writer. Beyond this point, the writer has the<br />

opportunity to in<strong>for</strong>m the reader of the fruits of her/his creative ef<strong>for</strong>ts.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 24


A Guide to Technical Communication<br />

Discussion<br />

The major task of this section is to interpret the results, to note what is “as expected”,<br />

what is unexpected, and what is of technical interest. The interpretation of the results in<br />

terms of the motivation <strong>for</strong> the experiment should obviously be focused upon. The<br />

discussion could contain a comparison with other similar investigations as established in<br />

the background or an explanation of discrepancies between theoretical and experimental<br />

values. The strong points of the work should be brought out here along with any<br />

limitations. If the writer does not point out the limitations of his/her work, someone else<br />

surely will later. It may also be appropriate to comment on possible future investigations<br />

or improving the experiment. When discussing the experimental results, do not use vague<br />

references to the accuracy of the measurements; note the estimated uncertainties and their<br />

effects on the calculated values. As mentioned above, all graphs and tables should be<br />

discussed and referred to by their corresponding figure and table numbers.<br />

An immensely frustrating aspect of critiquing student reports is to read a passage like:<br />

“It is not possible to <strong>for</strong>m any conclusions from the study since the results are<br />

inaccurate.” On the contrary, it would be pleasant to read a quantitative interpretation of<br />

how the estimated uncertainly influences the extraction of the desired in<strong>for</strong>mation from<br />

the available measurements.<br />

Conclusions<br />

In this section, present the appropriate conclusions which can be drawn from your<br />

work; relate your findings to the original objectives; point out special features of your<br />

work; mention limitations and discrepancies; and demonstrate how closely you have<br />

achieved the objectives. A useful style is to start with a reiteration of the objective of the<br />

study. Following this introductory sentence, the major conclusions can be presented in<br />

the <strong>for</strong>m of simple declarative sentences. The conclusions will follow from the items<br />

developed in (an implied by) the material in the previous sections.<br />

No new in<strong>for</strong>mation (results or interpretation thereof) should appear in this section,<br />

with the exception with recommendations <strong>for</strong> related future projects. It should serve<br />

primarily as a summary of the major points of the work.<br />

References<br />

In general a list of references used should be included in any report. Great care should<br />

be taken to follow the specified <strong>for</strong>mat of the organization <strong>for</strong> which the report is being<br />

written (<strong>for</strong> example a research center may have different guidelines than a <strong>for</strong>-profit<br />

business). In this project, all references used during the preparation of the report, or<br />

during the design process, should be listed in the <strong>for</strong>mat given in the section Guidelines<br />

<strong>for</strong> References.<br />

Microsoft Word has a built-in Endnote function, which will automatically number and<br />

re-number references. Ask your instructor about this if you do not know how to use this<br />

feature.<br />

Appendices<br />

Sample or lengthy calculations, or side issues that are peripheral to the main theme of<br />

the report should be placed in an appendix. This could include computer calculations,<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 25


A Guide to Technical Communication<br />

sample calculations, extra graphs, extra tables, or extra figures. Appendices should be<br />

referred to in the text and should there<strong>for</strong>e be labeled and have a title (e.g. Appendix A:<br />

Motor Per<strong>for</strong>mance).<br />

A criterion <strong>for</strong> deciding whether or not to put something in an appendix is to ask the<br />

question “Does its inclusion in the main body of the report detract from the smooth flow<br />

of the presentation?” If the answer is affirmative, and if the material contributes to the<br />

in<strong>for</strong>mation content of the report, then it should be presented as a separate unit. Each<br />

appendix should be lettered; Appendix A, Appendix B, etc. Each appendix should be<br />

cited in the body of the report (if you don’t mention it, how does the reader know it’s<br />

there?), and the appendices should be ordered based on the order of their citation<br />

(Appendix A must be the first appendix cited in the report).<br />

Some of the most common items to be found in an Appendix are:<br />

Data Sheets<br />

The original data sheet must be submitted. This may be copied or reproduced <strong>for</strong><br />

clarity, in which case the original should still be submitted.<br />

Sample Calculations<br />

This section should include examples of each type of calculation per<strong>for</strong>med in the<br />

experiment. Typically, the first and last set of data in a run should be used <strong>for</strong> sample<br />

calculations. Each calculation should be identified by describing the part of the<br />

experiment that it is from (or the appropriate run number), what is being calculated, and<br />

the specific data that is being analyzed. If a number of calculations are to be per<strong>for</strong>med<br />

on the same data the run analyzed should remain the same. All units must be included,<br />

and numerical values should have an appropriate number of significant figures. The<br />

calculations should also be presented in an understandable manner so that the logical<br />

connection between adjacent calculations can be seen.<br />

Uncertainty Analysis<br />

It is always appropriate to provide the reader with uncertainty estimates of the results.<br />

The experimentalist is, of course, in the best position to per<strong>for</strong>m such estimates. Per<strong>for</strong>m<br />

this procedure on the sample calculations.<br />

Optional Sections<br />

Some types of reports may need additional sections. Examples of these sections are<br />

given here.<br />

Nomenclature Listing<br />

The Nomenclature listing, if included, is normally right be<strong>for</strong>e the Introduction. As the<br />

name suggests, it lists and define all symbols used in the report. Note that the symbols in<br />

the nomenclature should be arranged in alphabetical order and that Greek symbols (also<br />

in alphabetical order) should follow after the Latin symbols. Common subscripts and<br />

superscripts should be listed separately. Where possible, refer to an equation which<br />

defines the symbol. Also proofread your report to ensure that all symbols are defined.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 26


A Guide to Technical Communication<br />

Acknowledgments<br />

Be sure to thank the people who helped you in a meaningful way, <strong>for</strong> example the<br />

members of the technical services staff of <strong>Manhattan</strong> College, fellow students,<br />

instructors, outside experts, and any benefactors (sources of material or funding). When<br />

mentioning the name of someone you are thanking, also give his or her affiliation.<br />

Acknowledgments are usually placed after the Conclusions. An example of an<br />

Acknowledgments section is provided below:<br />

This work was supported by the National Science Foundation and the Air<br />

Force Office of Scientific Research. We would like to thank Professor Hai Wang<br />

of the University of Southern Cali<strong>for</strong>nia and Professor J. W. Bozzelli of the New<br />

Jersey Institute of Technology <strong>for</strong> their helpful discussions.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 27


A Guide to Technical Communication<br />

Format <strong>for</strong> Short Laboratory Reports<br />

Occasionally, a professor will ask <strong>for</strong> a “short <strong>for</strong>mat” laboratory report. The idea <strong>for</strong><br />

such a report is a documentation of the study, with primary focus on the collection and<br />

interpretation of the data, without significant underlying theory.<br />

As the name suggests, this type of report is to be short, but prepared according to good<br />

engineering practices. A short <strong>for</strong>m report would contain the following sections:<br />

Abstract<br />

Data Sheets<br />

Sample Calculations<br />

Uncertainty Analysis<br />

Results<br />

Discussion of Results<br />

Conclusions<br />

References<br />

Appendices<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 28


A Guide to Technical Communication<br />

Design Project Reports - General Instructions<br />

Now we will discuss the second major type of technical documents, related to design<br />

projects. There are three types of design project reports – Proposals, Progress Reports and<br />

Final Reports. The next three sections of this manual will discuss the <strong>for</strong>mat of each in<br />

turn.<br />

Remember, as stated in the Introduction, if an instructor provides alternate guidelines<br />

on the <strong>for</strong>mat of a report, those alternate guidelines supersede the <strong>for</strong>mat here.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 29


A Guide to Technical Communication<br />

Format <strong>for</strong> Design Project Proposals<br />

The first document to be written <strong>for</strong> a design project is the proposal, which outlines<br />

what you set out to do in your project, and how long it will take. All proposals shall<br />

contain the following sections with proper headings as indicated:<br />

Cover Page<br />

A sample cover page is given in Appendix A: Format <strong>for</strong> Cover Sheets, and an<br />

electronic version in Word <strong>for</strong>mat is available <strong>for</strong> your use.<br />

Table of Contents<br />

This is a list containing the section titles and the page numbers on which the sections<br />

begin.<br />

Introduction<br />

The Introduction is a brief discussion that introduces the reader to the project and<br />

prepares the reader to understand the project as described more fully in the MAIN<br />

BODY. It could have background in<strong>for</strong>mation that describes why the project is<br />

undertaken and other in<strong>for</strong>mation that establishes the importance of the project in the<br />

context of the course. It should have no equations and refer to no figures.<br />

Proposal<br />

The Proposal is the principal narrative section. It should contain the project goals, the<br />

accomplishments and remaining tasks. Figures presented are discussed in this section.<br />

Expenses, if any, are reported in this section.<br />

Schedule<br />

The Schedule refers to a Gantt chart presented as a figure that plans the project from<br />

proposal to completion with specific dates. Discuss the principal features of the Gantt<br />

chart in this section.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 30


A Guide to Technical Communication<br />

Format <strong>for</strong> Design Project Progress Reports<br />

Prepare this report <strong>for</strong> the reader who has not seen your proposal and is otherwise not<br />

familiar with your project. All progress reports shall contain the following sections with<br />

proper headings as indicated:<br />

Cover Page<br />

A sample cover page is given in Appendix A: Format <strong>for</strong> Cover Sheets, and an<br />

electronic version in Word <strong>for</strong>mat is available <strong>for</strong> your use.<br />

Table of Contents<br />

The Table of Contents lists the sections with page numbers on which the section<br />

begins.<br />

Introduction<br />

The Introduction repeats and corrects, if necessary, the in<strong>for</strong>mation in your proposal<br />

introduction and otherwise summarizes developments through the proposal stage. The<br />

final sentence(s) of this section introduces the reader to the discussion of the PROGRESS<br />

TO DATE, i.e., the next section. No figures are to be presented in this section.<br />

Progress to Date<br />

The Progress to Date discusses in detail the progress you have made since submitting<br />

the proposal. Explain the present state of your design with drawings and photographs as<br />

appropriate. Discuss your calculations if included. Remember to refer to all figures in this<br />

narrative and number the figures in the order in which you refer to them. Report expenses<br />

to date and indicate any updates to your budget.<br />

Schedule<br />

The Schedule reviews your schedule of work presented in your proposal. Indicate<br />

whether you are progressing rapidly enough at this stage. Indicate any changes in your<br />

schedule as a reflection of your experience to date. Update your Gantt chart if necessary<br />

and discuss the updates in this section.<br />

Calculations (If necessary)<br />

The Calculations section presents all calculations in an orderly fashion. Identify the<br />

nature of each calculation and discuss the calculation in your PROGRESS TO DATE<br />

section. All units must be included, and numerical values should have an appropriate<br />

number of significant figures.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 31


A Guide to Technical Communication<br />

Format <strong>for</strong> Design Project Final Reports<br />

Prepare this report <strong>for</strong> the reader who has not seen your proposal and progress report<br />

and is otherwise not familiar with your project. All final reports shall contain the<br />

following sections with proper headings as indicated:<br />

Cover Page<br />

A sample cover page is given in Appendix A: Format <strong>for</strong> Cover Sheets, and an<br />

electronic version in Word <strong>for</strong>mat is available <strong>for</strong> your use.<br />

Table of Contents<br />

Present as in previous reports.<br />

Executive Summary<br />

In two pages or less, state what you accomplished in narrative <strong>for</strong>m, i.e. no equations<br />

and no figures. State the name and address of any cooperating facility. Briefly state the<br />

accomplishments of both your project. This section serves one type of important reader,<br />

perhaps the chief executive of a company, who only wants to know what you<br />

accomplished and its significance. He or she may read only this section of your report<br />

and scan the section with figures. You want to be sure that person receives the message.<br />

[Your Project Title]<br />

This is the main body of the report. Briefly discuss the background to supplement the<br />

executive summary, any design constraints and success metrics <strong>for</strong> this particular<br />

problem, and then present your final design in detail with drawings and photographs<br />

presented as figures. Be sure to refer to all figures in the order you place them. Present a<br />

Bill of Materials which includes sources of supplies. Give a selling price <strong>for</strong> the product.<br />

For guidelines, double the cost of materials if it is a production item, more if it is custommade.<br />

In addition, the item in most cases should be better, cost less, or be both, than<br />

competitive products.<br />

Reflections<br />

Discuss whether you accomplished your goals, where you fell short, and how you<br />

might modify the design if you were to start again knowing what you now know.<br />

Describe problems you encountered. Describe obstacles you overcame.<br />

Calculations<br />

This section presents all calculations in an orderly fashion. Identify the nature of each<br />

calculation and discuss the calculation in your main body of the report. All units must be<br />

included, and numerical values should have an appropriate number of significant figures<br />

Acknowledgments<br />

Be sure to thank the people who helped you in a meaningful way, <strong>for</strong> example the<br />

members of the technical services staff of <strong>Manhattan</strong> College, fellow students,<br />

instructors, outside experts, and any benefactors (sources of material or funding). When<br />

mentioning the name of someone you are thanking, also give his or her affiliation.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 32


A Guide to Technical Communication<br />

References<br />

In general a list of references used should be included in any report. Great care should<br />

be taken to follow the specified <strong>for</strong>mat of the organization <strong>for</strong> which the report is being<br />

written (<strong>for</strong> example a research center may have different guidelines than a <strong>for</strong>-profit<br />

business). In this project, all references used during the preparation of the report, or<br />

during the design process, should be listed in the <strong>for</strong>mat given in the section Guidelines<br />

<strong>for</strong> References.<br />

Microsoft Word has a built-in Endnote function, which will automatically number and<br />

re-number references. Ask your instructor about this if you do not know how to use this<br />

feature.<br />

Appendices<br />

Sample or lengthy calculations, or side issues that are peripheral to the main theme of<br />

the report should be placed in an appendix. This could include computer calculations,<br />

sample calculations, extra graphs, extra tables, or extra figures. Appendices should be<br />

referred to in the text and should there<strong>for</strong>e be labeled and have a title (e.g. Appendix A:<br />

Motor Per<strong>for</strong>mance).<br />

Sample or lengthy calculations, error analyses, lengthy derivations, or side issues that<br />

are not really in the main theme of the report should be placed in an Appendix. A<br />

criterion <strong>for</strong> deciding whether or not to put something in an appendix is to ask the<br />

question “Does its inclusion in the main body of the report detract from the smooth flow<br />

of the presentation?” If the answer is affirmative, and if the material contributes to the<br />

in<strong>for</strong>mation content of the report, then it should be presented as a separate unit. Each<br />

appendix should be lettered; Appendix A, Appendix B, etc. Each appendix should be<br />

cited in the body of the report (if you don’t mention it, how does the reader know it’s<br />

there?), and the appendices should be ordered based on the order of their citation<br />

(Appendix A must be the first appendix cited in the report).<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 33


A Guide to Technical Communication<br />

General Guidelines <strong>for</strong> Oral Presentations<br />

Communication is key to being a successful engineer – unless you can write reports<br />

and give presentations to share your findings with colleagues, managers, and others, your<br />

findings may end up being ignored. However, you must know your audience and be able<br />

to keep their attention. One key to keeping a group’s attention is to tell a coherent story.<br />

A second key is brevity. Keep your talk short, simple, and to the point. Nothing makes<br />

<strong>for</strong> an uncom<strong>for</strong>table presentation like a long-winded, meandering story. Certain things<br />

can be done to maintain brevity and a coherent story.<br />

Initial Considerations<br />

When planning an oral presentation the presenter must have a clear idea of what has to<br />

be presented. To achieve this, a summary of key topics should be identified. Also, the<br />

presentation should be designed to suit the background and expectations of the audience.<br />

Finally, the presentation should be designed to fit into the allotted time <strong>for</strong> the<br />

presentation. At technical conferences presentations typically last 20 – 30 minutes,<br />

however, a status report presentation might some can be as short as 10 minutes while a<br />

thesis presentation or an invited talk may be as long as 45 minutes. All of these aspects<br />

associated with the creation of the presentation are time consuming there<strong>for</strong>e the<br />

presenter should not underestimate the time that it takes to put together a good<br />

presentation. A general rule of thumb is that you should spend, in average, about oneand-a-half<br />

minutes per slide. Rushing through slides is not a good practice. You should<br />

give enough time <strong>for</strong> audience to absorb the material that you want to convey.<br />

Preparation Guidelines<br />

As mentioned above, you should use no more than two slides per three minutes of<br />

presentation time. That would mean that <strong>for</strong> a 20-minute presentation, you should have<br />

no more than 14 slides, and <strong>for</strong> a half hour presentation, you should have a maximum of<br />

20 slides. This slide count includes the title slide. Don’t look at any of the slides and<br />

think “I can get through this slide in only a few seconds.” If you can do that, there must<br />

not be much in<strong>for</strong>mation on the slide and you can merge it with the slide be<strong>for</strong>e or the<br />

slide after. Remember that the first thing the audience is going to do when a new slide is<br />

put up is look at the slide – they will not be listening to you. If you only keep the slide up<br />

“<strong>for</strong> a few seconds,” they will barely get a chance to look at the slide, and they will not<br />

have heard anything you have said.<br />

Prior to the actual talk the presentation should be practiced to gauge its length, and to<br />

ensure smooth transitions between speakers if multiple speakers are involved. In fact, it<br />

may do you well to script your presentation. This does not mean that you should know<br />

your presentation word <strong>for</strong> word; it does mean that you know exactly what points need to<br />

be conveyed, and (more importantly) in what order. Know what you are going to say is<br />

the best way to avoid (or at least minimize) the “aahs” and “umms” that are peppered in<br />

many presentations. 8 Also, prepare <strong>for</strong> anticipated questions, and in a group environment<br />

ensure that team members do not interrupt or contradict each other when responding to<br />

questions.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 34


A Guide to Technical Communication<br />

Slide Design and Creation<br />

When creating the slides <strong>for</strong> the presentation, choose a slide design that is bright,<br />

simple, and easy to print out. This prevents the audience from being distracted by the<br />

graphics, and allows anyone to obtain copies of the slides. Also, ensure that the slides are<br />

not too crowded, and use large visual elements to allow the slide in<strong>for</strong>mation to be read<br />

by audience members distant from the screen. There should be minimal text content and<br />

what exists should be in the <strong>for</strong>m of bulleted items (use the oral part of the presentation to<br />

convey most of the word content). In general, if large amounts of in<strong>for</strong>mation, such as<br />

graphs, tables, etc., have to be conveyed use multiple slides. Keep in mind if you make a<br />

slide too crowded with lots of text the audience will start reading the slides, and not pay<br />

attention to your talk. Finally, if presentation software is being used, make sure that<br />

backup overhead projector slides exist in case there is a problem with the projection<br />

system.<br />

Examples of slides <strong>for</strong> different types of presentations can be seen in Appendix B:<br />

Sample Presentations.<br />

To Outline or Not to Outline? That is the Question<br />

The outline slide is a source of contention among people who regularly give<br />

presentations, because people either love them or hate them. You professor will most<br />

likely have an opinion, and it is not the purpose of this manual to offer an opinion.<br />

However, the arguments <strong>for</strong> and against will be provided <strong>for</strong> the benefit of the student.<br />

Be<strong>for</strong>e we get into the pros and cons, just remember that the outline of the<br />

presentation should mimic the outline of a written report. For instance, if you are<br />

presenting the material which would go into a laboratory report, your presentation should<br />

have the following order:<br />

• Introduction<br />

• Analysis<br />

• Experimental Apparatus and Methodology<br />

• Results<br />

• Discussion<br />

• Conclusions<br />

Do not prepare a slide with references. References should go at the bottom of the slides<br />

where the in<strong>for</strong>mation is presented. There’s a good reason <strong>for</strong> this. When you read a<br />

paper, having all of the references at the end of the paper gives you an efficient,<br />

organized way of accessing sources cited in the work. You can flip back and <strong>for</strong>th as you<br />

read the paper and check the references as you go. You do not have this luxury in a<br />

presentation, and so to understand which material is from various outside sources, the<br />

references must be on the individual slides.<br />

The reasons why the sections of the presentation should follow the sections of the<br />

report is simple. The sections of a report are set up to provide a compelling story that is<br />

easy to follow. Why should a presentation be any different? A good presentation should<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 35


A Guide to Technical Communication<br />

have both an easy-to-follow story, and a focus. Without these points, you’ll lose your<br />

audience. 8<br />

Okay, on to the outline versus no outline debate…<br />

Outlines are good to generate, because they are indispensable <strong>for</strong> organization<br />

purposes. The Outline Slide presents the audience with the path that your presentation<br />

will follow. The slide provides the first step in a three pronged approach of giving a<br />

presentation, “say what you are going to say, say it and say what you’ve said.” This<br />

approach rein<strong>for</strong>ces the main points of the presentation to your audience.<br />

However, since you are aiming <strong>for</strong> brevity, an outline slide can disrupt the flow of the<br />

story. By all means, you should have an outline worked out when you develop your<br />

presentation, but do you want to waste a slide telling the audience about the story you’re<br />

about to tell? Just get to the story. Instead of an outline slide, your first slide after the title<br />

slide can outline the problem, i.e., this slide can in<strong>for</strong>m the audience of the objective of<br />

the study. If you explain what you’ve set out to do, there will be no question why you’ve<br />

done anything that you show on subsequent slides.<br />

So what should you do? For now, you should include one if your professor says so, or<br />

not if he/she is against them. However, you should decide what works better <strong>for</strong> you once<br />

you start presenting in the “real world.”<br />

Use of Graphics<br />

Use pictures (schematics, graphs, etc.) as the “anchors” of your slides. Keep the words<br />

on the slides to a minimum; it will prevent you from reading directly from the slides, and<br />

keeps the slides from being cluttered. Equations can be good, but do not go through<br />

derivations in a presentation. Show the basic equations, followed by the final equations<br />

used in the reduction of the data. Skip the intermediate steps, but you can mention in a<br />

general sense how you get from the start to the finish.<br />

Make sure that any text on the slides is large enough to be seen (this includes<br />

equations). Here’s a good rule of thumb: Print the slides out, place them on the floor, and<br />

stand over them. If you can read the printouts from that height (5-6 feet), the audience<br />

should have no problem reading the slides when projected on a screen.<br />

Presentation Issues<br />

There are also several issues that have to be considered at the time when a presentation<br />

is given. The first involves the presentation equipment itself. Be<strong>for</strong>e giving a<br />

presentation, the equipment should be inspected <strong>for</strong> its physical arrangement and<br />

condition to ensure that any necessary adjustments or accommodations can be made.<br />

Remember that YOU ARE THE FOCUS DURING A PRESENTATION. The slides<br />

are there as visual aids to help explain what you have done. There was a professor at<br />

Princeton named Irv Glassman who, at conferences, would routinely turn off the<br />

overhead projector (this was be<strong>for</strong>e laptops and Power Point presentations) after being<br />

introduced. He would talk <strong>for</strong> a minute or two about the motivation <strong>for</strong> the research he<br />

was presenting, and then turn on the projector again and continue. Moreover, he would<br />

have all of his students do the same thing when they were presenting at conferences or<br />

dissertation defenses. While the projector was off there was nothing to focus on but the<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 36


A Guide to Technical Communication<br />

speaker. This practice would establish the speaker, rather than the slides, as the central<br />

concern of the audience. This is a rather radical practice, and few people would be brave<br />

enough to try something like this without significant coaching, but the logic behind the<br />

practice is undeniable.<br />

Be<strong>for</strong>e starting your presentation, remember that you are the expert on the material<br />

you are presenting. It may be difficult to remember this at first, especially when you are a<br />

student being evaluated on the quality of your presentation. However, when you leave<br />

and start presenting you work in your career, this expertise will become more evident,<br />

and there<strong>for</strong>e it will be easier <strong>for</strong> you to remember. It will probably be most evident in the<br />

way questions are asked. In school, questions are asked by the professor to test your<br />

knowledge. After school, colleagues will ask questions because they are interested in<br />

what you have to say, and they want to know more. It’s an empowering feeling, and you<br />

need to cultivate it.<br />

When giving the actual presentation a rapport with the audience should be maintained.<br />

This can be accomplished by working through the slide material rather than from notes; it<br />

creates a more cohesive presentation and shows the audience that the presenter is very<br />

familiar with the material. In fact, don’t even bring notes up to the podium with you.<br />

They’ll serve you no purpose. The speaker should also maintain eye contact with the<br />

audience by facing them at all times, while making sure that the projected image is not<br />

obscured. The presenter should also talk slowly, clearly and loudly enough to allow the<br />

audience to hear what is being said, and use a pointing device (either a telescoping<br />

pointer or a laser pointer) to call attention to salient features on the slides. Also, slides<br />

should not be removed too quickly, since the audience needs time to absorb the<br />

in<strong>for</strong>mation being presented.<br />

Care should also be taken to ensure that the presenter creates a good impression. This<br />

can be achieved by being presentable, neat, and well dressed. In addition, the presenter<br />

should never chew gum, wear a hat, put his or her hands in pockets, or use fills such as<br />

“um,” “ah,” etc. Introduce yourselves to the audience, if you haven’t already been<br />

introduced.<br />

Keep looking at the audience – pick individual people to focus on, but occasionally<br />

shift to different people. Do not let your eyes stay fixed on the screen, since then you’ll<br />

be talking away from the audience!<br />

Do not get rattled by interruptions. They happen. In class, if you’re interrupted, it’s<br />

done in order to improve your presentation style (to make sure you know what you’re<br />

talking about). In other situations, if you’re interrupted, it’s probably because the person<br />

is very interested in what you’re talking about and wants to know more.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 37


A Guide to Technical Communication<br />

General Guidelines <strong>for</strong> Electronic Mail<br />

Electronic mail (email) has become a common way to communicate with peers,<br />

colleagues, superiors, employees, etc. This mode of communication has, in the past ten to<br />

fifteen years, largely replaced the memorandum as a <strong>for</strong>m of communication within an<br />

organization, just as it has replaced the paper letter as the <strong>for</strong>m of communication with<br />

entities outside an organization. Why are emails so useful?<br />

Complex messages can be transmitted efficiently. Simple messages can be<br />

transmitted via telephone or face-to-face meetings. For something a more<br />

involved, an email is better. 1<br />

They provide a written history. Electronic communications allow <strong>for</strong> traceability<br />

of in<strong>for</strong>mation transfer between entities, and thanks to modern technology, are<br />

automatically archived “in the cloud.” 1<br />

They potentially eliminate meetings. If you can provide updates on in<strong>for</strong>mation<br />

that only needs to be transmitted one way, sending a memo-type email allows<br />

users to read in<strong>for</strong>mation at their leisure, keeping schedules free <strong>for</strong> other items. 9<br />

You will probably be writing more emails than any other type of document, and so it<br />

pays to know how to write them in a way that gets your point across in a clear, succinct<br />

manner.<br />

Just Because It’s Fast Doesn’t Mean It Should Be In<strong>for</strong>mal<br />

Many people treat emails in the same way they treat text messages; it’s a quick and<br />

easy way to send a message to someone. This treatment of email is certainly fine in a<br />

more familiar environment (with friends and family), but such an approach really is not<br />

the most appropriate <strong>for</strong> business communication. Here are two emails recently sent to<br />

me, which serve as examples of what not to do (the names have been removed to protect<br />

the not-so-innocent):<br />

from: Cxxxxx <br />

to: "john.leylegian@manhattan.edu" <br />

date: Fri, Feb 8, <strong>2013</strong> at 8:20 AM<br />

subject: Class Absence<br />

mailed-by: manhattan.edu<br />

Hello professor<br />

I will be unable to make it to class today due to inclement weather. Can u email<br />

me the topics to be covered in class today? Thank you and stay safe.<br />

From,<br />

Cxxxxx<br />

Sent from my iPhone<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 38


A Guide to Technical Communication<br />

from: Mxxxxx <br />

to: "john.leylegian@manhattan.edu" <br />

date: Fri, Apr 26, <strong>2013</strong> at 8:00 AM<br />

subject: Hey professor<br />

mailed-by: me.com<br />

Hey Professor,<br />

I will not be coming into class this morning , I have an early appointment with<br />

the passport bureau to get my passport <strong>for</strong> my upcoming France trip.<br />

Thank You<br />

Mxxxxx<br />

Both of these email messages exhibit a level of familiarity not appropriate <strong>for</strong> business<br />

email messages. In the first, the student wrote the email as if it were a text message,<br />

complete with a “u” where a “you” belonged. The second message has a subject line not<br />

indicative of the subject of the message, and an overly familiar greeting.<br />

TAKE YOUR TIME… and it doesn’t have to be a lot of time. When you write an<br />

email that is in a professional capacity, write it as if it were going to be read by a<br />

potential employer, since it very well might, but more on that in the next section.<br />

Who Will Be Reading Your Email?<br />

Who are you writing to? The short answer is: More people than you think. You might<br />

have an initial distribution <strong>for</strong> your email (people who you are sending to, then others<br />

who are carbon copy (cc:) or blind carbon copy (bcc:) recipients), but <strong>for</strong>warding an<br />

email only takes a single click. Recipients of your email may think it should have a wider<br />

distribution; so <strong>for</strong> better or worse, your email may end up in the inbox of almost anyone.<br />

This fact makes it imperative that you put your best face <strong>for</strong>ward.<br />

When replying to an email the question of distribution is just as important. You should<br />

know the difference between “Reply” and “Reply All.” There are two reasons <strong>for</strong> taking<br />

care with distribution <strong>for</strong> replies. First, you do not want to be the person who needlessly<br />

clutters other people’s Inboxes with in<strong>for</strong>mation that does not apply to them. Second, if a<br />

message is sensitive in nature, it is important to make sure only the people who need<br />

in<strong>for</strong>mation are getting it.<br />

If only the sender needs to see your response, make sure you “Reply” rather than<br />

“Reply All.” Remember: you can always re-send an email to a larger audience, you can’t<br />

“unsend” though.<br />

Subject Line<br />

The subject line is the first thing your recipients will see. There<strong>for</strong>e, it should be a<br />

clear, very concise description of what is to follow. Remember that if you do not your<br />

email may not be given the attention it deserves.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 39


A Guide to Technical Communication<br />

Another important thing to remember about subject lines: some anti-spam filters may<br />

block a legitimate email you’re trying to send because a subject line is vague, misspelled,<br />

or some other “red flag” is raised. Normally the best way to keep people’s emails out of<br />

your spam folder is to make sure they are in your Address <strong>Book</strong>. You should also check<br />

your Spam folder regularly to make sure important messages are not being inadvertently<br />

ignored.<br />

Keep the Length Appropriate<br />

An email should not be more than one or two pages in length. If you find that it needs<br />

to be longer, perhaps you should consider writing a report to convey your ideas.<br />

Format<br />

There are many different <strong>for</strong>mats <strong>for</strong> memos which could apply to email<br />

communications. They can be in<strong>for</strong>mational or instructional in nature, and more<br />

in<strong>for</strong>mation on these <strong>for</strong>mats may be found in References 1 and 9. The important thing to<br />

remember is, like in reports, to tell a clear, coherent story.<br />

Write an Initial Draft, Then Revise!<br />

When you start to write an email, you may write in a “stream of consciousness”<br />

manner; that is, you will just start to write as ideas pop into your head. This type of<br />

writing is okay to articulate your thoughts, but they typically do not come out in a<br />

reasonable order. There<strong>for</strong>e, once you have your ideas out, they need to be organized into<br />

a more logical manner to the reader. 10<br />

Use the first draft to get your ideas down in writing. The next one or two drafts should<br />

be used to fit your thoughts into a coherent <strong>for</strong>mat. Finally, polish up what you want to<br />

say in the final draft.<br />

Attachments<br />

There are three main issues when dealing with attachments.<br />

First, don’t <strong>for</strong>get them! If you have attachments <strong>for</strong> your email, they should be<br />

included as soon as you think they are necessary. If you don’t include them right away,<br />

you might <strong>for</strong>get them altogether. At this point, you’ll need to write the sheepish mea<br />

culpa: “Sorry, <strong>for</strong>got to include the attachment(s).” Avoid this mistake at all costs!<br />

Second, try to keep attachments in <strong>for</strong>mats that you know your recipients can read.<br />

Things like text files, pdfs, Word documents, Excel workbooks, etc. are best. Files in<br />

other <strong>for</strong>mats should not be sent unless you know that the recipient has the correct<br />

application.<br />

Third, be aware of limitations on overall attachment size <strong>for</strong> emails. You might not be<br />

able to send very large files, and your recipients may not be able to receive them. In this<br />

case, offer a link to the file accessible on the cloud. Applications like Google Drive,<br />

Dropbox, or internal network drives can be used <strong>for</strong> this purpose.<br />

Proofreading, You Still STILL Need to Do It!<br />

Be<strong>for</strong>e you hit “Send,” take a last look at it. Make sure everything is spelled correctly,<br />

grammar and punctuation are correct, the flow of the story is correct, and any attachments<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 40


A Guide to Technical Communication<br />

are included. If it’s really important, ask a colleague, and be sure to return the favor if<br />

he/she asks you.<br />

One consultor once said at one of our meetings, “If someone sends me an email<br />

riddled with grammatical and/or spelling errors, would I want him or her designing a new<br />

airplane, or a car, or even a coffee maker?” Remember, you only get one chance <strong>for</strong> a<br />

good first impression.<br />

Don’t Hit Send in Anger<br />

An important thing to always remember about emails and SMS messages: subtle clues<br />

about intonation, body language, etc., are non-existent. In addition, we all at one time or<br />

another have gotten heavily invested in the work we have done, and a result is<br />

hypersensitivity. A seemingly innocuous message could easily set someone off if it is<br />

misread. There<strong>for</strong>e, we offer two pieces of advice:<br />

First, when sending emails, refrain from any type of language which could easily be<br />

misconstrued as hostile. Leave tongue-in-cheek comments, sarcasm, and the like <strong>for</strong> inperson<br />

exchanges, where they may go over better. If you’re not sure, ask someone to read<br />

your email be<strong>for</strong>e you send it.<br />

Second, if someone has overblown a comment you made in an email, nip it in the bud.<br />

Calmly apologize, and try not to make the same mistake again. Business emails are not<br />

the correct setting <strong>for</strong> a flame war. No one wins.<br />

Closing and Signatures<br />

An email is a letter, and there<strong>for</strong>e should have a closing. The most common closing in<br />

business emails uses a pre-composed signature, but any closing used in business letters,<br />

e.g., Sincerely, Regards, etc. are appropriate as well. Sometimes both the closing and the<br />

signature are used together.<br />

Signatures, if your company uses them, should be standard. Usually if you are a new<br />

hire, guidelines <strong>for</strong> communications are laid out and expected of all employees. A big<br />

reason <strong>for</strong> uni<strong>for</strong>mity is branding. Try to keep uni<strong>for</strong>m between computer and mobile<br />

devices. For example, here is the standard signature used by <strong>Manhattan</strong> College:<br />

-----------------------<br />

John C. Leylegian, PhD<br />

Assistant Professor of Mechanical Engineering<br />

Riverdale, NY 10471<br />

Phone: 718-862-7279<br />

Fax: 718-862-7163<br />

john.leylegian@manhattan.edu<br />

www.manhattan.edu<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 41


A Guide to Technical Communication<br />

The font, including the color, bold face/italicization, etc., was standardized by the<br />

College. On the other hand, if you frequently send emails from a smart phone you might<br />

not be able to have an elaborate signature set up on your smartphone. In that case, use a<br />

plain text version, such as:<br />

--<br />

John C. Leylegian<br />

Assistant Professor of Mechanical Engineering<br />

<strong>Manhattan</strong> College<br />

Riverdale, NY 10471<br />

Phone: 718-862-7279<br />

Fax: 718-862-7163<br />

john.leylegian@manhattan.edu<br />

www.manhattan.edu<br />

----------------------------<br />

Sent from my DROID<br />

If you can apply the rules <strong>for</strong> good technical writing to your approach to emails, you<br />

will be a great deal ahead of your peers when you find yourself in the business world.<br />

Emails versus SMS (Text) Messages<br />

Text messages were mentioned earlier, as an example of what not to do in an email.<br />

Text messages were originally limited to 160 characters, because this was considered the<br />

maximum length necessary to concisely express a thought. 11 For this reason, SMS is not<br />

really the best way to communicate complex ideas, and you should probably avoid it<br />

whenever possible.<br />

If you need to send business messages via SMS, remember that the rules <strong>for</strong> email<br />

should still apply. Conduct yourself professionally, avoid abbreviations and emoticons,<br />

and be clear and concise in your communication.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 42


A Guide to Technical Communication<br />

General Guidelines <strong>for</strong> Voicemail<br />

When you work you will often need to leave voice mail messages <strong>for</strong> colleagues, or<br />

people who you would like to be potential colleagues. Voicemail differs slightly from<br />

email since voicemails aren’t necessarily editable (some voicemail systems allow you to<br />

re-record a voicemail, but this feature is far from ubiquitous). There<strong>for</strong>e, here are some<br />

simple guidelines when you want to leave a voicemail message <strong>for</strong> someone: 12<br />

Plan out what you’d like to say be<strong>for</strong>e you call. Write out a few key notes to help<br />

you. This way, you don’t lose your train of thought or fill your message with<br />

awkward pauses.<br />

Begin by clearly stating your name and a contact number.<br />

State your purpose <strong>for</strong> calling. Be specific and eliminate any confusion. Avoid<br />

rambling.<br />

End your message with a plan to call again on a specific day. This lets the<br />

recipient off the hook if they are unable to call back, and ensures you’re not<br />

waiting around <strong>for</strong> a return phone call.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 43


A Guide to Technical Communication<br />

References<br />

1 Eisenberg, A., Effective Technical Communication, 2 nd ed., McGraw-Hill, New York,<br />

1992, Chaps 2-5, 12.<br />

2 Longuski, J., Advice to Rocket Scientists, American Institute of Aeronautics and<br />

Astronautics, Reston, VA, 2003, Chaps 21-24.<br />

3 Course materials <strong>for</strong> 2.272 Project Laboratory, Spring 2009. MIT OpenCourseWare,<br />

URL: http://ocw.mit.edu, Massachusetts Institute of Technology. [cited 24 June 2011].<br />

4<br />

Straker, D., Types of Data, Changing Minds <strong>Web</strong>site, Syque, URL:<br />

http://changingminds.org/explanations/research/measurement/types_data.htm [cited 6<br />

April 2008].<br />

5 Belcher, A., Endy, D., Kuldell, and Stachowiak, A., Course materials <strong>for</strong> 20.109<br />

Laboratory Fundamentals in Biological Engineering, <strong>Fall</strong> 2007. MIT OpenCourseWare,<br />

Massachusetts Institute of Technology http://ocw.mit.edu [cited 24 June 2011].<br />

6<br />

AIAA ScholarOne Manuscripts Page, American Institute of Aeronautics and<br />

Astronautics URL: http://mc.manuscriptcentral.com/aiaa [cited 19 December 2012].<br />

7 Cockrell, C. E. Jr., Huebner, L. D., and Finley, D. B., “Aerodynamic Characteristics of<br />

TwoWaverider-Derived Hypersonic Cruise Configurations” NASA TP-3559, Jul 1996.<br />

8 Daum, K., “5 Tips <strong>for</strong> Giving Really Amazing Presentations,” Roaring or Boring, 3 July<br />

<strong>2013</strong>, Inc. URL: http://www.inc.com/kevin-daum/5-tips-<strong>for</strong>-giving-really-amazingpresentations.html<br />

[cited 8 July <strong>2013</strong>].<br />

9 Connor, P., Business Memos, Writing@CSU, Colorado State University, URL:<br />

http://writing.colostate.edu/guides/guide.cfm?guideid=73 [cited 19 June <strong>2013</strong>].<br />

10 Mias, C. and Zinn, M., Personal Communication, 4 April <strong>2013</strong>.<br />

11 Milian, M., “Why text messages are limited to 160 characters,” Technology Blog, 3<br />

May 2009, Los Angeles Times URL: http://latimesblogs.latimes.com/technology/<br />

2009/05/invented-text-messaging.html [cited 26 June <strong>2013</strong>].<br />

12 McClain, A., “How to Leave a Good Voicemail Message,” eHow Tech, URL:<br />

http://www.ehow.com/how_7516281_leave-good-voicemail-message.html [cited 26 June<br />

<strong>2013</strong>].<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 44


A Guide to Technical Communication<br />

Appendix A: Format <strong>for</strong> Cover Sheets<br />

The following pages provide some cover sheets <strong>for</strong> different types of reports. These<br />

cover sheets can be found in files on the Mechanical Engineering Department Blackboard<br />

site <strong>for</strong> your use. Just be sure to replace all of the pertinent in<strong>for</strong>mation.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 45


A Guide to Technical Communication<br />

MECH 405 (02)<br />

Thermal/Fluids Laboratory<br />

Experiment No. 4<br />

Forced Convection<br />

Report Submitted to<br />

Dr. Mohammad Naraghi<br />

Group 3<br />

John Aquino Experiment Per<strong>for</strong>med: 14 April 2003<br />

James Knapp Report Submitted: 28 April 2003<br />

Richard Thomas<br />

Mechanical Engineering Department<br />

<strong>Manhattan</strong> College<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 46


A Guide to Technical Communication<br />

MECH 211-01<br />

Introduction to Design<br />

DESIGN PROJECT<br />

Proposal<br />

Group A<br />

Eric Clegg<br />

Philip Ng<br />

Thomas Langowski<br />

September 22, 2004<br />

Mechanical Engineering Department<br />

<strong>Manhattan</strong> College<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 47


A Guide to Technical Communication<br />

MECH 401 (01)<br />

Mechanical Engineering Design<br />

Progress Report<br />

Project: Easy Rider Cart<br />

Report submitted to<br />

Dr. Daniel Haines<br />

20 October 2002<br />

Group B<br />

Twisted Minds Inc.<br />

Charles Dickens<br />

Mary Murphy<br />

James Patterson<br />

Mechanical Engineering Department<br />

<strong>Manhattan</strong> College<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 48


A Guide to Technical Communication<br />

MECH 401 (01)<br />

Mechanical Engineering Design<br />

Final Report<br />

Project: Easy Rider Cart<br />

Report submitted to<br />

Dr. Daniel Haines<br />

10 December 2002<br />

Group B<br />

Twisted Minds Inc.<br />

Charles Dickens<br />

Mary Murphy<br />

James Patterson<br />

Mechanical Engineering Department<br />

<strong>Manhattan</strong> College<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 49


A Guide to Technical Communication<br />

Appendix B: Sample Presentations<br />

In general, there are only three types of oral presentations that are associated with the<br />

engineering field: design presentations, presentations of experimental or theoretical work,<br />

and presentations describing state-of-the-art material. On the following pages there are<br />

frameworks <strong>for</strong> the first two types. It should be noted that these are only guidelines, and<br />

depending on the situation more than one slide may be needed to cover a specific issue,<br />

some slides may not be necessary, or a specific topic may be missing altogether.<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 50


A Guide to Technical Communication<br />

Experimental Study Slides<br />

Slide 1<br />

Experimental Study Title<br />

Names of Group Members<br />

Course Number<br />

Slide 2<br />

Introduction<br />

Use bullets to outline the objective of the<br />

project in question<br />

Use a slide design that is bright and easy<br />

to print out.<br />

Provide a background to the problem<br />

Discuss the State-of-the-Art<br />

Slide 3<br />

Theory and/or Hypothesis<br />

The basic principles<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 51


A Guide to Technical Communication<br />

Slide 4<br />

Experimental Design<br />

Discuss full or partial factorial design<br />

chosen<br />

Discuss the use of any confounding or<br />

blocking<br />

Slide 5<br />

Test Equipment Setup<br />

Use text, pictures,<br />

and/or diagrams<br />

Clearly annotate the<br />

pictures<br />

Describe the<br />

methodology<br />

Slide 6<br />

Data Measured<br />

? Present a sample of the raw data when<br />

appropriate, i.e., when data processing<br />

involves more than simple algebra<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 52


A Guide to Technical Communication<br />

Slide 7<br />

Statistical Analysis<br />

Present the statistical analyses<br />

ANOVA<br />

Regressions<br />

Confidence intervals<br />

Chi squared test<br />

Slide 8<br />

Tables/Graphs of Data<br />

Slide 9<br />

Discussion of the Results<br />

Discuss salient features of the data and<br />

trends observed<br />

Discuss any anomalies<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 53


A Guide to Technical Communication<br />

Slide 10<br />

Conclusion<br />

Present the conclusions that can be drawn<br />

from the experiment<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 54


A Guide to Technical Communication<br />

Design Study Slides<br />

Slide 1<br />

Design Study Title<br />

Names of Group Members<br />

Course Number<br />

Slide 2<br />

Introduction<br />

Use bullets to outline the objective of the<br />

project in question<br />

Use a slide design that is bright and easy<br />

to print out.<br />

Objective of Project<br />

Slide 3<br />

Specifications<br />

Present requirements and constraints<br />

State the what’s that needed to be done<br />

Present and Quality Function Deployment<br />

(QFD) analysis<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 55


A Guide to Technical Communication<br />

Slide 4<br />

Conceptual Designs<br />

Present the fours conceptual designs that<br />

were examined<br />

Use text, pictures, and/or diagrams<br />

Slide 5<br />

Design Selection Matrix<br />

Slide 6<br />

Detailed Design<br />

Design Analysis (assumptions, sample<br />

calculation, and results)<br />

Use text, pictures, and/or diagrams<br />

Present material selection process<br />

Reliability analysis<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 56


A Guide to Technical Communication<br />

Slide 7<br />

Prototype Per<strong>for</strong>mance<br />

Present per<strong>for</strong>mance data and graphs<br />

Slide 8<br />

Manufacturing Issues<br />

Processes to be used<br />

Slide 9<br />

Economic Analysis<br />

Part costing<br />

Manufacturing costing<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 57


A Guide to Technical Communication<br />

Slide 10<br />

Conclusion<br />

Present the salient features of the design<br />

Last Updated 8/22/<strong>2013</strong><br />

Page 58

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!