Progress Report

Following the fall break, you will give a short progress report describing your research project, the progress that you have made so far, and what remains to be done.


There are four key things that you must communicate lucidly in a very short amount of time:
  • The Problem - What problem are you attacking? Why is this an important problem and why is it tricky to solve?
  • The Solution - What is your approach to solving this problem? What makes your solution novel, difficult, or non-obvious? Be sure to include a carefully prepared diagram that shows the components of your software, system, or algorithm, and how they interact.
  • Initial Results - What have you accomplished so far? Demonstrate that your basic idea works, albeit in some incomplete way. If your project involves performance measurement, show a measurement that verifies your basic hypothesis. If your project involves collecting data, show some real data and explain some interesting anomaly in the data.
  • The Road Ahead - What remains to be accomplished? Are there any unexpected technical issues that change the directory of your project? What results will you demonstrate at the end of the semester?
  • Grading

    Your grade will be based upon your correct and clear explanation of the four points given above, reasonable progress in your work, and completing the talk in a timely manner.

    Technical Requirements

  • Medium: Your talk should be accompanied by video slides, perhaps five to ten total. You may use any tool that you like to create slides: Powerpoint, OpenOffice, and Keynote are common choices. However, your final slides will be downloaded and shown on a single Windows machine, so you must submit them in either Portable Document Format (PDF) or Powerpoint (PPT). (There won't be time for everyone to muck around by plugging in laptops, rebooting machines, or running other software.)
  • Handin: You must email your completed slides to me by 9AM Tuesday October 26. I will put the talks in random order; everyone must be prepared to start the first talk on time.
  • Time: Each talk will occupy TEN minutes plus TWO minute for questions and discussion. Groups with more than one person should arrange to have everyone speak for a portion of the time. I will give you a silent warning when you have 1 minute remaining. The next talk should load slides and get ready during the question period.
  • Meeting: After the progress report, you must schedule a second meeting with me. In the meeting, we will discuss your progress, consider any changes in method or scope, and set goals for the final paper.
  • General Advice from Me

    Ten minutes is a very short talk, so there won't be time for you to hem and haw. A short talk can be more difficult than a long talk in this respect -- you must stick carefully to your message. Practice your talk multiple times, preferably with someone else paying attention. (It's short, so it's easy to practice several times.) Make sure that you use all of the time available!

    Keep in mind that you have been thinking about this problem for a while, but your audience has not. Start from a high level and explain some of the reasoning that brought you to this point where you are now. Of course, you also want to demonstrate that you are now an expert about this idea, so throw in one tricky detail that shows that the problem is non-trivial and that you are clever. (Your final talk can place more emphasis on the technical details.)

    Use your slides to back up what you say to the audience. A bunch of slides spelling out exactly what you intend to say is pretty darn boring for everyone involved. Instead, display a picture of your system, and describe it in words. Or, display a single sentence that drives home a key idea, and then discuss the idea for minute. Or, display a code snippet on the screen, and then describe what is interesting about the code. Don't just display words and read them out loud.

    In a long talk, speakers often give outline slides describing the whole structure of the talk: Introduction, Overview, Methods, Results, Related Work, Conclusion. Don't do this in a short talk: it is painfully obvious and wastes valuable time.

    A demo is a risky matter. A really good demo can make a complex idea clear. However, demos frequently crash and burn for technical reasons. A good middle ground is to give a "staged" demo (be honest about this) that is a video or screenshot or PowerPoint approximation of what your software does.

    Be prepared for technical malfunction. If a projector breaks, a computer crashes, or the demo fails miserably, don't waste your valuable talk time puttering with the equipment. This makes you look foolish. (Which you aren't.) Just tell a joke and then move on without that element of your presentation. Listeners will remember you for being smart and adaptive. (Which you are!)

    Advice from Others