PowerPointLabs is a free PowerPoint plugin for creating awesome slides with less effort.
Generate animations, spotlights, narrations, captions, zoom effects, and more ...
Download from http://PowerPointLabs.info
The presentation is for explaining your project - both the product and the process - to the evaluators. The presentation complements the project documentation and the product demo (if any). It gives evaluators a chance to clear up doubts by asking questions on the spot, for example.
While most evaluators are supposed to read your project documentation, there is no guarantee that they will read it cover-to-cover. But they are guaranteed to be present at the project presentation and it is up to you to make the best of it. Some evaluators prefer to attend the presentation first and read the report later. In such a case, the presentation creates the first impression of your project in the mind of the evaluator. In some cases, the whole evaluation is based solely on the presentation. Whichever the case in your course, treat the presentation as a key determinant of your grade. Given below are some tips to make the best of your project presentation.
|
|
Author recommendation: PowerPointLabs is a free PowerPoint plugin for creating awesome slides with less effort. Generate animations, spotlights, narrations, captions, zoom effects, and more ... Download from http://PowerPointLabs.info |
Project presentations are usually scheduled back-to-back, all of which are attended by the same panel of evaluators. Needless to say evaluators get irritated when you run over the time limit. It shows gross negligence on your part; if you did a rehearsal, you should have realised the problem earlier.
If the presentation duration is 30 minutes, target to finish in 25 minutes. The actual run almost always takes longer.
Be prepared for questions you can anticipate. Even if you have done all the right things in your project, evaluators get suspicious if you cannot explain the rationale behind your decisions. During practice, get your team mates ask questions that are likely to be asked by evaluators and make sure you can handle them fluently.
Do not waste time on what is obvious. For example, do not waste a slide to explain what is unit testing; evaluators know what it is (you might inadvertently display your own lack of understanding of it! I have seen that happen) Mention them in passing if you must. Instead, focus on what is unique in your project.
If you think a top-notch sales pitch can cover up a lousy project, you are mistaken. Give a balanced view of what happened. Talk about things that went right, as well as things that went wrong (and why they went wrong, what lessons were learned, etc.). Experienced evaluators are quick to see through the marketing-oriented presentation that oversells the project.
After you put your content into PowerPoint slides, it is often hard to move content around. Use a different medium such as a text file to organise the contents. After your content is stable and the flow is clear, you can transfer the text to slides.
If you feel you are running out of time during the presentation, NEVER increase your talking speed to catch up. Doing so is the same as saying "'in case you didn't notice, I screwed up the delivery of my presentation". Instead, keep cool, leave out less important details (you can say things like "This slide is about XYZ, I'm not going to explain this slide in detail. We can come back to it during Q&A time if you need clarifications"), and finish on time.
Do not feel compelled to follow exactly the same structure everyone uses. Evaluators will be happy to see a 'refreshingly different' presentation, as long as you do not stray too far from the objectives of the presentation.
Do not read directly off the slide. Evaluators can read, too. Instead use the slide as a backdrop to help you convey the point you are trying to make.
Murphy's Law often interferes with product demos. Steps of your product demo should be pre-determined and well rehearsed. If appropriate, part of the demo can be a pre-recorded screen cast of how the software works, or some of the product functionality can be explained using screen shots. You can always justify not doing a live demo as 'in the interest of saving time'. If you plan to do a product demo, rehearse it in the actual environment you would be using; for example, a low-resolution projector can really take the edge off your product demo that looked wonderful in your own computer. On a related note, make sure your slides still look good when projected and videos/links still work in the environment the demo/presentation will be done.
Some students are 'compulsive clickers' who keep clicking things and moving the mouse around in a very irritating fashion while they demo software. Avoid allocating the product demo to a compulsive clicker.
Do not dress shabbily even if there is no dress code. On the other hand, you do not want to be the only person wearing a full suit that day either.
It is safe to avoid certain behaviour ticks that might irritate the audience. Here are some examples:
As you prepare the presentation, consider it from the audience' point of view. In our case, the audience is the evaluators. A common mistake is to assume the audience knows something just because you know it. Here is a useful test you can do during preparation. For each slide, verify that every significant term or concept that will be used to explain that slide is guaranteed to be known to the audience beforehand or has already been explained in previous slides. This test is a great way to identify kinks in the presentation flow.
A train is not much use if it speeds through stations without picking up passengers; the same applies to presentations. Having all the right content organised in the best possible order is necessary but not sufficient to the success of your presentation. The truth is not all content is equally important to the audience. Slow down at key points, wait for impact, clarify doubts, and make sure everyone is 'on board' before proceeding.
A presentation should be as graphical (less textual) as possible. Use screen shots, graphics, animations, videos, gestures and verbal explanations in place of lengthy text. Remember, it is a project presentation, not a lecture. Take your cues from Steve Jobs' presentations [http://tinyurl.com/presentlikesteve], not programming 101 lectures.
Do not ruin your chances by betraying a lack of confidence in your own product. Avoid phrases such as "hopefully, it will start when I click this button". Rehearsing the demo beforehand will help you act confident while doing it.
When you explain 'possible' features that are non-existent at the current time, be sure to explain them as things 'you could do in future' rather than 'things you wanted to do but couldn't'. Avoid phrases such as "by right, there should be an XYZ here, and it should work like ABC". Instead, say "we can extend the product by adding an XYZ here to do ABC".
On a related note, do not show what you do not want the evaluators to see. For example, you should not be saying things like "oh, ignore that; It's just a debugging message".
If you run out of time, do not cut into the time allocated for Q&A time. Q&A time is for the evaluators to clarify things. Not giving them the chance to do so will not work in your favour. A question not asked is a question not answered.
Have backup slides to address questions. Evaluators will be impressed to see how you anticipated questions. When questioned, never act defensive. While it is OK to have a designated Q&A person (perhaps, the person who can think on his feet the best), be ready to take questions if that person is not conversant with the area under scrutiny. If you are cornered, do not try to bluff your way out. Being sincere and humble is more important than trying to score off every question. A better way out of a question that you cannot answer is to accept that you did not think of it, thank the evaluator for bringing it up, promise to think about it, and perhaps, use a light joke to break the tension.
If the course does not require all team members to take part in the presentation, it makes sense to let team members who are good at presentations to do the presentation. However, others should try to show the appropriate level of involvement without getting in the way of the presenters. Sitting in the back of the room checking email while your teammates present is definitely not a good idea.
Any suggestions to improve this book? Any tips you would like to add? Any aspect of your project not covered by the book? Anything in the book that you don't agree with? Noticed any errors/omissions? Please use the link below to provide feedback, or send an email to damith[at]comp.nus.edu.sg
 |
Sharing this book helps too! |
---| This page is from the free online book Practical Tips for Software-Intensive Student Projects V3.0, Jul 2010, Author: Damith C. Rajapakse |---
