mikeksmith’s posterous

The big idea: Have one (and only one) aim for your presentation.

(from Olivia Mitchell ) "A presentation that tries to do (two things) is going to be confused and will achieve neither."

In my work we sometimes are interested in optimal designs. In optimal design theory you can optimise on only one thing. That design will be suboptimal for everything else. It's the same with attention and presentations. You should optimise to get the key message across.

Two main types of technical presentation:

• Peer Review
• Decision making

Sometimes you also get a third type of technical presentation:

• Knowledge transfer or a Sharing / Inspiring presentation. In this the format is usually more of a dialogue and verges on an informal teaching or brainstorming session. Often results in dialogue and discussion. The presenter is usually looking to facilitate discussion rather than present, say,20 minutes of new material.

Peer Review:

• SPEAKER WANTS technical review, input, ideas, validation of work. AUDIENCE WANTS to know how ideas might be applicable to their situation.
• Presenter likely to have worked on this topic for considerable time. Understands the data, context etc. Audience don't have this information SO need to spend reasonable amount of time explaining context, assumptions, specifics of this situation. (Fantastic post by Zen Faulkes on this topic).
• Ensure that your presentation meets the needs of BOTH you and the audience i.e. Don't just show how clever you are - aim to get to the point where the audience understands and can give you what YOU want out of the meeting (ideas, feedback, new direction). HELP the audience to see how what you're presenting could be applicable for them (application in new areas, lessons learned etc).
• If you over-egg technical stuff then audience split into 2 camps: Engaged but lost / Disengaged and thinking of other stuff. Type 1 turns into Type 2 quite quickly if you don't work hard to get them back. Stop & check understanding from time to time. Summarise. Paraphrase. Recap. Don't just ask "Any questions?".
• For peer review of ALL technical details - write a manuscript. DON'T present.

Interview presentations are also "peer review" in nature, even though the stakes are high. You want to impress the audience, but you also want them to be engaged and get them enthused about / interested in what you're presenting and show that YOU are interested in this stuff.

Decision Making

• SPEAKER WANTS Credibility, buy-in from decision makers / stakeholders. AUDIENCE WANTS to make a decision using available technical input.
• Different stakeholders will have different needs from the presentation. Do you know what these are? Find out BEFOREHAND.
• Present ONLY the information that helps make the decision.
• Skip to the key point / conclusions quickly. Then backfill details.
• Make a clear recommendation, and provide evidence to substantiate your recommendation.
• Present caveats, assumptions clearly.
• What are the costs (in $ / resource / other) of ignoring the technical information? What are the costs of buying into the conclusion?
• Technical aspects should go in a precirculated executive summary.
• Don't get side-tracked by technical questions from "experts" in the audience. Address quickly or refer to executive summary.

Compare and contrast presentations with manuscripts

Manuscript structure:

• Introduction
• Methods
• Results
• Discussion
• Conclusions

Peer review presentation structure

• Introduction Motivation
• Premise / Conclusions
• Methods
• Results
• Conclusions Applicability / Applications.
• Discussion, assumptions, caveats, applicability to other cases

Decision making presentation structure

• Introduction Motivation
• Conclusions Recommendation (Suggested actions)
• Results (evidence)
• Discussion, caveats, assumptions, costs
• Methods (if necessary, if asked!)

Following standard "manuscript" structure for technical presentations is likely to lead to BORED audience. They could download your manuscript and read it at their leisure later... Why listen? OR you don't cut to the results and conclusions quick enough to engage decision makers - if you lose their attention is the decision based on your presentation of technical results or their best guess / hunch / gut feeling?

• Manuscripts focus on Methods. Usually light on introduction and conclusions.
• Peer review should be big on motivation, conclusions and applicability i.e. Why did we do this? What did we find? What impact does it have?. Light on results (the specifics of the results matter most to you and other experts in the area. Perhaps less so to people outside your specific topic).
• Decision making should be fast to conclusions and recommendations. Results back up the recommendation. MOST of the presentation should be conclusions / recommendations. Lighter on motivation if the topic is already familiar to the decision makers. Methods should only be presented if absolutely necessary.

(From Olivia Mitchell) "Technical presentations shouldn't be a mystery novel where you wait to see whodunnit. Having the conclusion upfront helps people put the information that comes next into context".

For technical presentations, motivation is key

• Why did you, as speaker, take the bus across town or the train halfway across Europe or a transatlantic flight just to come and talk about this stuff?
• Why did the audience turn up at your session? Presumably something in the title or abstract caught their eye. (Perhaps they're only here to listen to the talk AFTER yours!).
• Just getting up from your desk to come to the presentation shows some level of motivation from you AND the audience. Honour that motivation.
• Why is what you're presenting important?
• Why should they (the audience) be interested?
• What is it about your findings that might be applicable to somebody else and move forward their understanding of this area? HINT - it's not page after page of detailed methods!!