Research Proposals

Writing a Research Proposal

All good research proposals, whether they're for an undergraduate Directed Studies project, a graduate thesis or term project, or to a granting agency for millions of dollars of research funds; and whether they represent work of an individual or of a large team, have some characteristics in common. Here are some tips on what I want to see in any research proposal that I am asked to evaluate.

1. Background

Motivation: what is the basic problem which your research is going to address? I.e., why should anyone care about what you are proposing to do?
Progress: what has already been done that relates to solving this problem? I.e., what will be your starting point? Sometimes it seems like you are working in a brand new area and there isn't any prior work. That is never true: even if your implementation relies on an entirely new technology, or you are using some method for an entirely new purpose, somewhere someone will have tried to solve that problem using a different approach, or used some variant of your technology in a different way, etc. Find what's closest and talk about it, even if its relevance seems quite distant to what you plan to do. Saying "there is no prior work" will seriously damage your credibility, since it just makes it sounds like you aren't very familiar with the field.

Conversely, in some contexts, it isn't really expected that you are deeply familiar with the area, or will have had time to do a thorough review. Do the best you can, even if it's only asking the nearest expert at hand for a few relevant references and taking a look at them before writing the proposal.

2. Goals

Anticipated contribution: what will exist or be known when you're done? There may be more than one thing.

Remember, this is research, so you don't know for sure what you'll accomplish. However, you hopefully can state that you are going to ask some kind of question and find the answer to it. The whole point is that you don't know what that answer is; but if the question is well-posed, then even if the answer is not what you were hoping for, then you will have learned something in the process and not wasted your time.

3. Milestones: what are the steps to get from Prior Work to your Goal?

Break down your task into a manageable number of steps, to be executed either serially or in parallel. 4-5 is often a reasonable number for a proposal - later as you do the work, you may further break down those steps into sub-tasks for yourself. For each task, identify a "deliverable" or question-point, where you will (a) know that you've finished that task, and/or (b) will be able to make some decision that influences the way the work will proceed from that point.
Dependencies: for each task, take into account activities, resources, necessary learning, and in particuluar, events or contributions outside of your control which your successful progress will depend on. This last might include things like arrival or completion of a piece of equipment or software that someone else is building, or time contributed by someone with a special expertise.
Schedule: how long will each step take? Put down expected duration and a date for when you expect to reach the milestone. This is where you get to prac the fine art of time estimation. Believe me, you will probably not allow enough time, even if you write down twice as much time as you think the step could possibly take. Sometimes it helps to further break down the task at this point, and if you're confident about the completeness of the list of subtasks, you may be able to estimate them with better accuracy. With practice (i.e. doing the job then comparing your actual performance with predicted) you'll eventually get a little better at estimating how long it takes you to do different kinds of things, and consequently you'll get better at planning although you should accept that most mortals never reach perfection in this.

Allow extra time for tasks which are unfamiliar to you, and tasks which may require iteration; and consider dependencies which might interfere with your schedule.

4. Screw Points: milestones where if you cannot complete them successfully or on time, then you are screwed.

There is probably a more polite term for this: look for places where a bad result will mean that there is no point in continuing because you are not going to learn or accomplish anything of value. It's really important to take this into account personally even if it's not included in your proposal: suppose it is your Ph.D. thesis and you find yourself in this unfortunate position after working on a problem for several years? If the proposal is to me, it should be in there.
What will be your backup plan in each case? Is there an alternate, perhaps less desirable but still acceptable path that will lead to some result other than absolute failure? If not, and the failure has any real liklihood of occurring, then this is a seriously flawed research plan.

5. Deliverables: what tangible result will you deliver throughout and at the end of your project?

This might include:

Report (interim and/or final; including a published paper)
For a design project, some kind of prototype - e.g. physical, simulated, drawing) - something that either documents the project through embodiment, and/or allows the design to be experienced
Results of user studies
Presentation - e.g. in a lab seminar or at a conference