CSCI 6838 Capstone Projects
Guidelines For Oral Presentations

by K. Yue, last modified: July 2010

I. General

Technical presentation is an integral part of the capstone project. Software developers should be able to communicate effectively with other technical professionals, business executives and customers to describe their projects.

The goals of the technical presentation in CSCI 6838 are to:

• inform the audiences of the technical results of the project,
• solicit feedback from the audiences to improve the final report of the project, and
• gain experience in technical presentations.

For the final presentation, each team will have 30 minutes, including the question and answer session. Each team member should have approximately equal presentation time.

Examples of some good technical presentations I have enjoyed.

II. Presentation Slide Format

There is no longer a required presentation slide format. However, they will need to be professional and consistent. Dress professionally and consider using a team member to handle the computer to free up the presenter.

The following is merely suggestions. Depending on the nature of the project, each team can select the most suitable presentation format and content of its choice.

It is a good idea to have a good slide footer.

Slide group #1: Project Title

List the project title, team number and presentation date using center justification.

Slide group #2:General Project and Team Information

Team members, mentors, etc.

Slide group #3: Contents

List the contents of each section of the presentation and the team member presenting the section. Team members should have approximately equal presentation time.

Slide group #4: Project Abstract

This is a concise abstract describing the project problem and the design, implementation and evaluation of the solution.

Slide group #5: Technical Contents

This is the bulk of the presentation that may include the following subsections. Again, the exact content is project specific. Some suggestions:

Problem Specifications

For examples:

• What is the problem?
• What is the significance of the problem?
• What is the context of the problem?
• What are the important specifications and constraints of the problems?
• What are the related problems?

Design and Implementation of Solutions

For examples:

• The architecture of the selected solution.
• Key design decisions and their rationale, which may include:
  • Key UML diagrams.
  • Key relation schemas.
  • Key data structures and classes used in the implementation.
• Main functions of the solution.
• Selected technologies and rationales behind the selection.
• Software development model used.
• Implementation issues: difficulties encountered and techniques to overcome them.
• Comparisons with other alternative solutions.

Product Demo

More often than not, the capstone project results in a prototype deliverable and demonstration is a key part of the oral demonstration. The team may select to provide a product demo earlier in the presentation as it may sometimes help the audiences in understanding the design of the product. The product demo may even be shown early in the presentation to provide a solid context.

Evaluation of Solution

For examples:

• How well does the solution solve the original problem?
• How well is the design of the solution?
• What are the main functions of the solution prototype?
• Is the performance of the solution prototype fast enough?
• How reliable is the solution prototype? For example, is it transaction safe?

Conclusions

For examples

• conclusions drawn
• lessons learnt
• future changes in the design of the solution, and
• future enhancement of the solution prototype.

Slide group #6 References

This section contains reference information, such as books, papers, URLs, etc

III. General Guidelines for Good Presentations

Nature

Know the nature of your presentations. The capstone project presentation is a technical presentation. It is not a sale, marketing, promotional or strategic presentation. The goals are to technically describe your projects and get technical feedback. Discussion on business cases, marketing opportunities, etc, should be minimized.

Audiences

Know your audiences well, their technical background, their interests and what they want to know from the presentation, not what you want to say.

In the capstone project, your audiences are technical software developers with close to a Master level of education in computing and may have some industrial experience. They are not general audiences with minimum in-depth knowledge in computing. Think about your audiences in preparing every slide. Do not spend too much time on contents that your audiences should have already know. It will be uninteresting and boring. Spend time to build up the necessary technical depth.

For example, assume that your presentation topic is "A WAP-based search engine for the mobile Web." It will be inappropriate to spend several minutes to talk about the potential of mobile Internet and WAP phones. That will be for more general audiences. A very brief summary will be fine. You may spend a little time on WML by comparing it with HTML, which you may assume every audience knows very well. You may also assume that the audiences already know some Web server-side technologies, such as CGI or JSP. A brief summary will be adequate. Your audiences definitely know how to use search engines so there is no need to describe what a search engine is. They may not know how to construct a Web-based search engine. Thus, a summary of how to construct a regular Web-based search engine is appropriate. Your presentation should focus on the special challenge of developing a search engine in the WAP platform. Clearly discuss the restrictions posted by the WAP platform and how your design addresses these restrictions.

IV. Tips on good presentations

This section is adapted from Dr. Boetticher's writing on "steps to a good presentation." I have added some comments at the end of each section. Thanks, Dr. Boetticher!

Much effort is required for making a very good presentation. Here is a brief outline.

Research

Boetticher: Knowing that you have enough to talk about is the first step. Be sure to spend enough time reviewing the code in your project. This will help you gain confidence in your presentation.

Yue: As a general rule of thumb, you need to know several times more materials than those appear in the presentation.

Preparation

Boetticher: Think of giving a presentation the same as writing a program. Begin with an outline and refine it. Collect screen images to use.

Slide creation tips

• Organize the presentation (start with an outline).
• Allow about 1 to 3 minutes per 'content slide'. A 'content-slide' is a slide that has some content, not just a title or outline slide.
• Don't put full sentences, and don't put everything you know on the slide.
• Don't overfill a slide - when in doubt, split it to two slides.
• Don't use animation and/or sound effects unless you have a very good reason; they are too distracting.
• Don't use too large/small of a font (24-32 pt. is generally good)
• No more than 1 line for the title
• Try to use no more than 1 line for each bullet
• Uppercase only at the beginning of the slide (if possible)

Yue: Preparing slides can be very time consuming. A good slide presentation usually includes several major and minor modifications. Like writing a paper, you should go through your slides carefully at least three or four times.

Before writing your slides, form a model of your audiences -- what they already know and what they are interested in knowing. Your slides should be based on this model. You are telling a story. It is important to know what should be kept. It is equally important to decide what details are minor to the flow of the story and should not be included.

Slides do not and should not contain everything in the presentation. They are visual tools to help the speakers and audiences to focus on essentials, central concepts and interesting and important observations. Slides should leave room for the speaker. Most people can best handle only two to three concepts at a time so don't put too much content in a single slide. Ideally speaking, each slide should present only one major concept.

Additional slide preparation tips:

• Eliminate nonessential contents.
• Grammatical errors and spelling errors are bad.
• Factual errors are bad.
• Explanation of unfamiliar acronyms should be included.
• Consistent use of styles, diagrams and tables project professionalism.
• Important resources, such as URL, should be stated.
• Prepare extra slides that will not be used for regular presentations, but are used for answering questions, as well as when the presentations go faster than expected.

Presentation tips

Boetticher:

• Try to remain calm
• Talk slowly and clearly
• Make good eye contact
• Smile!
• Don't read the slides, talk about the subject
• Dress professionally

Yue:

• Make sure that you speak loud enough.
• Similar to the preparation of slides, form a model of your audiences -- what they already know and what they are interested in knowing. Your presentation should adapt to this model.
• Think about a good starting line.
• Engage the audiences -- eye contact, walk around, ask questions, slow down at suitable time, use humor (if suitable), praise, shock, etc.
• Use lot of examples. Most people respond better to examples than abstract ideas.
• Write something on the viewgraphs. Write down important technical terms. Explain all acronyms.
• Distribute hard copies of your viewgraphs at the right time.
• Slow down if needed -- allow time for audiences to digest.
• Time management is critical. Allow time for posing questions.

Practice, Practice, and Practice!

Boetticher:

Don't assume that you can get the presentation right the first time. Practicing the presentation (out loud, and preferably to an audience) will make a tremendous difference in the second presentation. I usually practice a presentation at least 5 times prior to delivery.

Specific benefits of practice:

• Learn the timing
• More comfortable with slides
• Chance to catch errors in slides
• More confidence in presentation

Yue:

Ask your friends/relatives/classmates to criticize your presentation. Your team should arrange for a full presentation drill and spend at least equal time as the drill for analyzing the presentation.

If possible, tape your own presentation and study it yourself. You will be amazed by watching your own presentations and probably can make many self recommendations for improvement.