Writing a Research
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.
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.
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
Allow extra time for tasks which are unfamiliar to you, and tasks which may
require iteration; and consider dependencies which might interfere with your
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