Guidelines for Engineering Presentations

Michael A. Latcha, PhD
Department of Mechanical Engineering
latcha@oakland.edu
Oakland University
Rochester, MI 48309
(248) 370-2203

Written Presentation Guidelines
Guidelines for Oral Presentations

Written Presentation Guidelines

The general guidelines presented here for technical reports or articles are similar to those of ASME. A general engineering written report consists of the following sections:

Title Page. The title page contains a descriptive title of the report, the name(s) of the authors, the date submitted and the name of the class for which it is being submitted. The title page may also contain a graphic that illustrates the results of the report, but if you choose to include one, be careful that it does not distract from the overall impact that you wish to make with the report.

Abstract. The abstract is a very brief summary of the report and should contain only highlights of the various sections in the report. The abstract should never include equation numbers or references to tables and figures in the report. It should be self-contained and the text should flow smoothly. Since the abstract summarizes the entire report, it is best to write it last. The abstract should never exceed 200 words. The abstract can appear in one of two places, at the bottom of the title page or all by itself on the page following the title page. The abstract is the first section that anyone will read and its quality and content often color how the reader will perceive the rest of the report.

Table of Contents. In general, a Table of Contents need not appear in a report of 10 or fewer pages. If one is considered necessary to help readers navigate the report, it appears on its own page immediately following the Abstract. The Title Page and the Table of Contents never appear in the Table of Contents.

Introduction. The introduction is the second most important portion of the report; the goal of the introduction is to reinforce the material contained in the abstract and to provide some additional detail. After reading the introduction, the reader should be able to identify the topic and purpose of the report, briefly describe what has been done, and why it was done. The introduction should clearly and concisely state the objectives of the experiment or design project, as well as provide a brief outline of the report. This section is usually about half a page long and generally does not include any figures or equations.

Theory. This section provides, when necessary, a description of the relevant theory (or model) needed to understand parts of the report, such as the discussion section, or details of a theory that will be compared to the experimental data or applied to a particular design problem. Laboratory reports should also have a subsection labeled "Procedure" which details the specific procedures followed in the laboratory. Equations must be properly labeled and referenced in the text. Place the equation number to the far right of the equation. In general, few readers of a general engineering report will delve deeply into this section (other than your instructor, of course), usually only those who are interested in your specific techniques or in duplicating your results.

Results and Discussion. This is the heart of the written presentation and also usually the longest section. It includes any experimental results, graphical and tabular presentation of data, analysis of data, details of the components developed in a design project, and discussion of the results (often in comparison with any relevant theory), along with any sample computations that illustrate any post-experiment data manipulations that were done. The use of tables, graphs and figures usually help to present data. Each table, figure or graph that appears must be discussed and explained within the text of the report. This section will be primarily of interest to those who wish to either duplicate or more deeply understand your work. Design project (ME 4300, ME 4999) reports must contain sections that discuss the aspects of safety, economic factors, reliability, aesthetics and societal impact and how these aspects influenced the proposed solutions to the design problems.

Conclusion/Recommendations. This section summarizes the results in the context of the entire experiment or project. This section is largely a repetition of the most important conclusions reached in the discussion section, but also seeks to explain the implications of the results or of the final design solution. All conclusions and/or recommendations presented must be justified on scientific grounds. In addition, any recommendations for the improvement of laboratory experiments or further work to be done in projects should appear here. This is often the third section read, after the Abstract and the Introduction, and should both contain and reinforce the material found in those sections. For design projects, this section is particularly important to those who would like to expand on your work in the future.

References. Every thought, idea or result that is not original to the author(s) must be referenced to its source. To do otherwise is dishonest, unethical and will be considered a form of academic misconduct. The preferred format is that used by the ASME:

Text Citation. Within the text, references should be cited in numerical order according to their order of appearance. The numbered reference citation should be enclosed in brackets. Example: "It was shown by Prusa [1] that the width of the plume decreases under these conditions. " In the case of two citations, the numbers should be separated by a comma [1,2]. In the case of more than two references, the numbers should be separated by a dash [5-7].

List of References. References to original sources for cited material should be listed together at the end of the paper; footnotes should not be used for this purpose. References should be arranged in numerical order according to the sequence of citations within the text. Each reference should include the last name of each author followed by his initials.

Reference to journal articles, papers in conference proceedings, or any other collection of works by numerous authors should include:

Reference to textbooks, monographs, theses, and technical reports should include:

Sample References

  1. Kwon, O. K., and Pletcher, R. H., 1981, "Prediction of the Incompressible Flow Over a Rearward-Facing Step," Technical Report HTL-26, CFD-4, Iowa State Univ., Ames, IA.
  2. Lee, Y., Korpela, S. A., and Horne, R. N., 1982, "Structure of Multi-Cellular Natural Convection in a Tall Vertical Annulus," Proceedings, 7th International Heat Transfer Conference, U. Grigul et al., eds., Hemisphere Publishing Corp., Washington, D.C., 2, pp. 221-226.
  3. Sparrow, E. M., 1980a, "Fluid-to-Fluid Conjugate Heat Transfer for a Vertical Pipe - Internal Forced Convection and External Natural Convection," ASME Heat Transfer, 102, pp. 402-407.
  4. Sparrow, E. M., 1980b, "Forced-Convection Heat Transfer in a Duct Having Spanwise-Periodic Rectangular Protuberances," Numerical Heat Transfer, 3, pp. 149-167.
  5. Tung, C. Y., 1982, "Evaporative Heat Transfer in the Contact Line of a Mixture," Ph.D. thesis, Rensselaer Polytechnic Institute, Troy, NY.
  6. Amon, A., Jr., 1995, Electronic Packaging, John Wiley and Sons, New York.
  7. "Stop! You Do Not Have to Write That Check To The IRS.", Internet: http://www.irs.ustreas.gov/prod/cover.html, April 15, 1999.

Tables/Figures/Graphs. The use of figures, tables and graphs greatly simplifies the presentation of data and their use is encouraged. All tables, figures and graphs must be titled and numbered in the order that they are found in the report. They should be found either on the page on which they are first mentioned or on the following page. Once they are titled, they are to be referred to by the capitalized type and number, such as "Figure 1." All tables, figures and graphs that appear in the report must be referenced in the text of the report; table, figures and graphs that are not referenced in text are unnecessary and should not appear in the report at all.

All of your tables, figures and graphs should be able to stand alone within the context of the presentation. They must include elements such as a descriptive title, axes or data column labels, axes or data column units, appropriate legend identifiers, and any other key experimental or test conditions that are important to understand the graph or to distinguish it from other similar graphs in the presentation. Some items that qualify under the last element are uncertainty info if that's not in the graph and/or distinguishing test conditions. The idea that figures must stand alone within the context of the presentation is especially relevant to oral presentations.

Appendix. The Appendix is the place for all of the supporting material that is not important enough to make it into the body of the report. All your calculations, the original data sheets from laboratories and detailed derivations all belong in appendices. Everything that would break up the flow of the report should be in appendices. Usually no one will read the appendices - this is for only the most interested reader who needs absolutely all of the material. Rule of thumb: you should be able to rip the appendices off your report and it still should be complete.

Guidelines for Oral Presentations

Unless otherwise directed by your instructor, the following are guidelines for oral presentations:

Good oral presentations follow the same general flow of a written report of introduction, discussion, results and conclusion. However, a successful oral presentation is not just a spoken version or a rehash of the written report. Due to the time constraint and the style of communication, only a limited amount of detail can be delivered and understood during an oral presentation. It is much better to "tell the story" of a design project than to try to explain complex analyses or complicated derivations. Spend more time getting your audience to understand the overall big picture rather than intricate details.

By the end of the first two minutes, your audience should know what you did, why you did it and how the rest of the presentation will be organized. The remainder of the presentation explains and fills in details. By the end of the presentation, the audience should know how your design solution evolved and why it is the best you have considered. The presentation should actually have an ending and not just taper off into nothing.

Only concentrated, timed practice will allow you to tune and deliver a good oral presentation, with all your group members participating, running the actual PowerPoint slides to be used and assisted by a stopwatch. In particular, pay attention to smooth transitions between speakers and topics. Always introduce the next speaker: "Amy will now explain the experimental results."

Use only about 1-2 slides per minute and limit the amount of information on any individual slide. Each slide should have a separate, distinct purpose in the presentation, much like a paragraph in a written report. Many studies have shown that the maximum amount of information that can be absorbed quickly from a slide is 4 bullet points, with at most 6 words per point. If you try to jam a lot of information on a slide it will have to be projected with small fonts, making it difficult to read or your audience will be busy reading and not listening to you.

To be instantly legible, try to stick to sans-serif fonts of at least 20-point. Light lettering on dark backgrounds usually works best for PowerPoint slides, but exceptions exist. About 11% of males have some degree of red-green color blindness - avoid the use of these colors, especially adjacent to each other. Limit the use of special effects, like flying words or sounds and of "busy" or distracting backgrounds. These effects become annoying very quickly, or worse, your audience will be paying more attention to the effects than to what you are saying.

Establish eye-contact with the audience. Avoid reading what is projected on the screen; the members of the audience can do that for themselves. Visual aids should support and enhance the presentation, they should not repeat it. Enthusiasm is good, excitement is even better. Smiles are better than frowns :) Body language is important. A confident demeanor can carry a presentation. Speak up so that the people in the back of the room can hear - speak directly to them, not to the people in the front of the room. Speak slower than normal and try to avoid "uh", "you know", slang, jargon and any bad jokes (hint - in a presentation, most jokes are bad).

At all costs, avoid losing contact with your audience during the presentation. Every time you change slides your audience stops listening to you and looks at the new slide. Make it easy for them - include only a very limited amount of information and stop talking for 10 seconds or so until they can absorb it and turn their attention back to you. Never turn away from your audience, even to glance at notes or the screen, and never to point at the screen. It is very hard to pay attention to someone who isn't making eye contact, and it is hard to not pay attention to someone who is speaking directly to you. If you absolutely must turn away, make it very brief. You will have to work hard to regain lost attention. You can often get it back by physically moving, for example, by taking a step towards the audience.

The very best way to combat nervousness is careful, thorough preparation. Remember always that you know more about your project than anyone else in the room, and they are listening to you because they want to know what you did and why you did it. Relying on notes, including those you can imbed into PowerPoint, is a poor substitute for practice. Few things are worse, for presenters and audiences alike, than reading a 20-minute presentation from notes.

Visual aids other than simple PowerPoint slides are extremely important during oral presentations. Include in the presentation photos, diagrams and videos - anything that will make it easier for your audience to understand how your solution works.

If at all possible, have your prototypes at the presentation to demonstrate. It is a lot easier to show someone how something works than to describe it, and the "cool" factor increases immensely. HOWEVER - it is very, very common for a reliable, perfect device to not work when it is demonstrated for others. If that occurs during your presentation, do not attempt to fix the device and get it working. Instead, prepare in advance and be able to smoothly move from the planned demonstration to a video clip that shows exactly what you want your audience to see. Hope for the best, plan for the worst.