Written Proposal

Proposal writing is an important skill -- you will be writing research proposals throughout the rest of your career and much of your success will be determined by how well you can convince others that the work you want to do is worth doing and that you have the ability to accomplish that work.

The purpose of the written proposal is to save you time by (1) identifying a specific goal and establishing that pursuing that goal is worthwhile and (2) developing a concrete strategy for meeting those goals and verifying that the proposed strategy actually matches the stated goals. (You would be surprised at how many research projects' strategies either do huge amounts of irrelevant work for a given set of goals or do a bunch of work and then realize that they still have not address their goals).

We will provide feedback on the written proposal to enhance both the written and in-class oral proposals.

The written proposal should follow the following format: Outline for written project proposal 3-5 pages

• Abstract -- 1 paragraph written in first person
• Introduction -- 1 paragraph only
Say what you are doing (don't worry about explaining "why" yet). Be specific: if the reviewer does not know what you are proposing to do by end of first paragraph, the reviewer will almost certainly reject your proposal.
• Motivation/problem statement/importance of problem (about 1/2 page)
• Related work: (about 1 page)
• What useful approaches you will build on?
• Limitations of current approaches.
• How will your study extend the state of the art?
• Proposed solution (about 1 page)
• Hypothesis under test (1 sentence in bold italics)
• Overview of proposed solution
• Specific research contributions if project is successful
• Evaluation methodology (about 1.5 pages)
• List of experiements. For each experiment:
• Summary of experiment
• What is purpose of experiment?
• Proposed graph (what is x axis, what is y axis, what are lines, what is workload, ...)
• How does this graph serve the purpose of the paper? (e.g, if hypthosis is true, what will graph look like. If false?)
• Week-by-week milestones of what needs to be built for the experiment.

Example:

The following is taken from my notes on a recent project that I began:

Summary: Experiment Set C:  Background loading v. foreground
We compare two cases. In one, when a server's reply indicates that
customization should be applied, the extra stage in the pipeline is
added immediately and the reply passes through it before being sent to
the user. Case 2: when a server's reply indicates that customization
should be applied, we hand the answer back immediately but begin
downloading the customization program in the background. Once it is
loaded, we update the customization pipeline for that server.

Purpose: 
o Test the following performance model: under foreground mode, the first
  request will take (T_remote + delta_1) to handle (while the custom
  code is downloaded) and all subsequent requests will take
  T_local. Under background mode, the first k requests will take
  (T_remote + delta_2) to handle and the rest will take T_local.
o Test hypothesis that background loading improves overall 
  system performance.

Proposed graph: x axis is elapsed_time, y axis is response_time for
a request. Lines in graph represent different programs under test in
either foreground or background loading mode:
                PROGRAM=null program MODE=foreground
                PROGRAM=null program MODE=background
                PROGRAM=adrot+hit count MODE=foreground
                PROGRAM=adrot + hit count MODE=background
                PROGRAM=catalog application MODE=foreground
                PROGRAM=catalog application MODE=background

Suppose that a request to a remote service takes T_remote, a request
to the local copy of the service takes T_local.  This set of
experiments will (a) test the hypothesis that the model is correct,
(b) quantify k, delta_1, and delta_2, and (c) test the hypothesis that
background loading is beneficial: if k and delta_2 are small and
delta_1 is large, then this experiment will support using background
loading. Otherwise, this experiment will tend to argue against using
background loading.


MILESTONES:
  MILESTONE C1: customization programs written
    MILESTONE C1-1: nullNS.jar written DONE
    MILESTONE C1-2: we don't want NULL, we want a program that changes
        the uncachable reply to become cachable. Write MakeCacheable.jar
	8.6.99
    MILESTONE C1-3: complete adrot, hit count downloadable services 
        8.13.99
    MILESTONE C1-4: complete pages to be accessed to install and use services
	8.13.99
  MILESTONE C2: complete driver script to do repeated timed access
        8.17.99	
  MILESTONE C3: run experiments
    MILESTONE C3-1: test system with all machines on LAN
        8.17.99
    MILESTONE C3-2: install server at far site (e.g., Duke or Washington)
        8.13.99 -- get started early on this!
    MILESTONE C3-3: run experiment (clients on UT LAN, server on far site)
        8.24.99
    MILESTONE C3-4: run experiment (clients on modem or ISDN, server on far site)
        9.1.99
    MILESTONE C3-5: graph results; iterate experiments if needed
        9.1.99
    MILESTONE C3-6: update section 5.B of the paper describing
       experiments and results
        9.8.99

• Overall Timeline -- e.g., 3 weeks after proposal, what experiments will be completed? What about 5 weeks? If you run short of time (you will!) what experiments will you jettison and which are essential for you to complete the project?
• Risks and risk management (about 1/2 page)
What are the risks to the project. What could make you fail? (e.g, too much code to write, assumption X could be wrong, can not get access to realistic workload,...) What will you do to reduce the impact of the risk? (E.g., if "assumption X could be wrong" is a risk, then is there an experiment you can do in the first 2 weeks to test assumption X rather than completing the project in 3 months and only then discovering that your assumption was wrong?)