Hints for Writing a PhD Proposal

By Angelos Keromytis (April 2010)

• a description of the problem in enough detail to clearly state the thesis proposition (next item)
• a proper, concise thesis proposition; this is not an abstract statement like "we're going to investigate the insider problem", but something along the lines of "our hypothesis is that the use of XYZ technology in environment Z under constraints Q can identify insider attackers with probability Z" --- obviously, the fewer qualifiers the better, but you also need to be accurate; since this is a thesis proposal, we will cut you some slack -- but it's in your best interest to think hard about this, since it is the anchor point of your whole thesis (and the next few years' worth of work for you)
• a description of the related work, how it does not solve the problem, and how your hypothesis has not been tested before
• preliminary results (if any) that indicate that you have reason to believe that the hypothesis holds
• additional experiments that you will run to prove that the hypothesis holds
• what you'll need to build to run said experiments (and what you've already built)
• what happens if you can't run some of these experiments, or if they give you "bad" results --- what's your failover?
• what are the expected contributions, keeping in mind that each major contribution must demonstrate novelty, non-triviality, and usefulness (so, "first", "best", "only" are good adjectives here)
• how long you expect all this to take

Hints for PhD Proposal Defenses

• PhD proposal defenses in Computer Science allow student audience; this is a good opportunity to find out what works and doesn't from your more senior colleagues.
• Proposal defenses consist of four parts: first, the candidate introduces themselves, then presents a summary of their work, interrupted and followed by questions from the committee. Finally, the committee meets in private to discuss the presentation and the plan.
• While most of the committee will have read most of your proposal, you cannot assume that everyone has read every page in detail.
• Avoid high-level talks: "... they usually fail to convey the intellectual substance, creativity, ingenuity of the speakers' accomplishments - what takes the work out of the routine. Naturally, these comments apply to all of our speakers who want to impress people with their ability as opposed to the breadth of their knowledge or the size of their project." (Ed Coffman)
• When presenting experimental work, be prepared to defend your methodology. What was your sample size? Confidence intervals?
• Standard presentation guidelines apply:
  • Be prepared; for example, avoid wasting your audience's time with setting up the projector or conference bridge. Thus, try out any presentation arrangements well ahead of time, particularly if it includes remote presentation, multimedia contents or demonstrations. Your first slide should be on the screen when the committee shows up for your talk.
  • Dress for the occasion: This is a major milestone in your academic career, where most members of your committee will meet you for the first time. Treat it like a job interview.
  • It is customary, but not required, to provide minimal refreshments, such as coffee and maybe some fruit and/or cookies.
  • Talk to your audience, not to your slides.
  • Project your voice; speaking softly conveys the impression that you are unsure of what you are saying.
  • Make sure that all your graphs are readable. Check this in the actual presentation environment (using a video projector), not just on your laptop screen. A common problem is that the lines are too thin.
  • Avoid flashy or cheesy animations, such as animated GIFs, or PowerPoint word art. This is not a sales talk and these gimmicks distract from the message and make you look unprofessional.
  • Keep to the allotted time of no more than 45 minutes.
• Your presentation needs to address the following:
  • What is the problem you are studying?
  • Why is it important?
  • What results have you achieved so far and why to they matter?
  • How is this substantially different from prior work?
  • What do you need to do to complete your work?
• Your workplan should be sufficiently detailed so that the committee can judge whether it is realistic or not. You don't have to account for every day between the proposal and your thesis defense, but a roughly monthly or quarterly granularity is to be expected, depending on how far away your anticipated graduation date is. Specify the experiments you need to run, the software you need to write and the algorithms you want to try out. This should not just be one page that says "I will do miraculous things".
• The committee should be handed a copy of your slides. At least a day ahead, email the presentation to your committee as well.
• No more than 25 slides, plus "back up" slides with additional material in case of questions. The committee will get anxious once the presentation lasts longer than 35-40 minutes.
• List your contributions early and explicitly. You don't want to create the impression that related work is yours, and vice versa.
• One of the most important concerns during the proposal is to convince the audience that you are aware of all related work. Since some of your work may date back a few years, it is not sufficient to just copy the reference list from your first paper. Check common recent conferences to see whether any recent work applies to your thesis. If applicable, point out your work predates work presented by somebody else done more recently. (Given the duration of most theses, it is not uncommon that others pursue a direction after you have stopped working on it.)
• When presenting your contributions, be sure to use "I" and not "we" so that the committee will know what aspects of the work where yours, and which were group projects.
• You must convey a clear plan how you are going to evaluate your work systematically - by measurement, simulation, user experiments. This is a core part what makes computer science science and not just software-building.
• Be prepared to back up any comparative statement with facts, in particular statements like "works better", "faster", "scalable" or "optimal". If you are presenting a protocol, how do you know that it works correctly? If your algorithm is optimal, can you prove that it is? (If not, avoid the term.)

Thesis Contributions

By Yechiam Yemini (March 2010):

A thesis contribution is a technical result that is both substantially novel and creates significant new knowledge.

A technical result is a solution of a technical problem. There are four types of technical results:

1. A theory consisting of a body of theorems and their proofs from first principles.
2. An algorithm that computes certain output from a given input.
3. A performance analysis describing quantifiable behaviors of a large class of mechanisms, or characterizing optimal selection of their control parameters.
4. A design for a hardware, software or protocol mechanism capable of resolving a broad class of problems.

A result is substantially novel if it cannot be derived as a simple application or extension of known results. A result creates significant new knowledge if it is (a) not obvious; and (b) if it is sufficiently abstract to be applicable to a large class of problems.

As a PhD Examiner … My Top 25 Tips for PhD students

---

[Hints for PhD defenses]   [Writing style]   [Writing bugs]  

---

Last updated by Henning Schulzrinne