A Few Comments On Technical Presentations
Jean Koster
First, it was a pleasure to see that so many of you put a substantial effort in the Lunar
Module presentation and also took advantage of the guidelines published on our
webpage.
As we are here to learn and improve, here are a few general comments, all relate to
“technical/scientific” presentations, given to a technical audience:
Whenever you give technical presentations, you need to research technical data, such as
properties, dimensions, in support of your arguments, words are not sufficient. Absence
of data/graphs makes a technical presentation non-technical. Use table format or graphs
to visualize the data. If you show a graph/sketch/design: explain it and discuss content.
“Throwing” a table/graph with lots of data at the audience without explanation is as bad
as not having a graph/table at all. In case you show technical instruments, include the
model name, brief data, capabilities, related to your task, and reference the manufacturer.
Engineers never develop a perfect system, they always try to “improve” an existing
concept, thus they discuss the “reference.” Improvements over a reference system can
often be expressed in %. That is more helpful than just giving numbers of the new system
performance, and saying it is a better system.
Text on slides needs to be short, each word well selected; no long sentences that require
the audience to concentrate on reading. Reading off the slides distracts the audience from
listening to you. This can always be improved through rehearsals where you include
peers that are not studying in the same field as you are.
If you are asked about a historical account, you have to be careful. Historical information
can be quite overwhelming and you need to understand where to stop. For example the
lunar landing could not have been done without the invention of the rocket in China 3000
years ago as well as the work of Goddard, Sänger, Tsoilkowsky, and others. Fortunately
nobody went that far back! Sure, Kennedy gave the go-ahead for the lunar landing, and
there were many interesting events in the lunar program of the 60-70s. But are they all
important for the redesign of the landing gear? Here is my recommendation how to limit
history to pertinent developments, it is not a content outline of the paper though, you
apply it after you have your draft:
1) Topic: Look at the topic as defined. You were asked to “redesign the landing
gear.” Thus focus on the landing gear.
2) Time: In any presentation, most important is YOUR work, your contribution,
here on the redesign of the landing gear. This is the most important part of your
presentation. A first guideline is that it should amount to about 60-80% of your
presentation time. You may start with a draft that would require 130-150% of the
allotted time slot and put all your wisdom in a logical sequence. Later you
ASEN2001-02
1
3)
4)
5)
6)
prioritize and shorten to the allotted time, using some of the dismissed slides as
hidden slides.
Other’s Work: Review primarily the history of the landing gear. Review lessons
learned: pros/cons, and quantify those data in tables/graphs. Compare later to your
redesign concept. Ask yourself now: how much time do I have left in my allotted
presentation time. If I have one minute+, then I add one slide on more general
background related to the LEM. If no time is available, you just mention the LEM
in your very first slide where the task is stated; because another team would be
responsible for the higher system integration issues such as: should the LEM have
3, 4, or 6 legs. In industry you must be aware of the tasks of other teams and
respect them, otherwise you engage in turf battles that you are likely to loose as
colleagues turn against you. Communication between teams is an essential part of
a system development like the LEM.
Time Review: Next, make a new time analysis. Rehearse your presentation and
find out whether YOUR work is appropriately presented, to-the-point, complete,
logical, and understandable by the targeted audience. You prioritize the
information that you are presenting. Supporting information must be prepared for
hidden slides that you show only if needed in the following discussion.
Comprehensive: Ask yourself: Do I have nothing else to say about MY TEAM’s
OWN work? Is the accounting of achievements comprehensive? Then I can
decide to fill in a few words/single slide on history of the lunar program, but allot
only 30 secs (i.e. little time). However, it is always better not to use all the allotted
time, as the audience then tends toward the assumption that your team is on top of
the task. The first second you run over your allotted time starts turning the bias of
the audience against you and your presentation. You have anyway some “hidden
slides” that you pop up when questions require it, thus no need to run over time.
Hinting to the right question during the presentation is a skill of the professional
engineer: your team looks good if you pop up a slide with an answer that is to the
point of the question. Never try to fill your time slot with useless historical (or
other) background information, never!
Sales Pitch: Remind yourself always that a presentation is also a “sales pitch:”
you try to “sell” an idea to your company/colleagues/customer, or “sell” good
scientific work to the academic community. If the audience likes your “product,”
they “buy” it, meaning for example you get your proposed R&D (research and
development) program approved by your company, or your reputation in the
scientific community is increased as scientists like your work as a major
contribution to their knowledge base.
A grain of salt: No one is perfect! How a good presentation should be done is always an
issue of “culture,” corporate culture as well as academic culture, sometimes differing
from Department to Department, Professor to Professor. Thus, when joining a new
environment, always assess the “culture-dynamics” in your new environment.
ASEN2001-02
2