In advance of the grant writing panel to be held this Saturday 8pm at STOC, Sanjeev Arora put together some very useful tips for people writing grant proposals. These tips as well as others will be discussed on Saturday by our panelists: Joan Feigenbaum, Piotr Indyk, Bala Kalyanasundaram, and Salil Vadhan.
The panel will be moderated by Moses Charikar and me.
Advice on writing a research grant proposal.
Sanjeev Arora
Professor of Computer Science,
Princeton University
April 2013
- Approach it with a positive attitude: it is a necessary part of your job along with writing papers, giving good talks, following the research in your field, PhD advising etc. Remember: the better you get at it, the less frequently you need to do it.What I like about the current peer review system (at least in computer science) is that it allows young researchers with good, imaginative proposals to get funded, leaving more senior researchers in the dust. I’ve seen it happen a lot.
Another positive aspect for me is that this system forces me to evaluate myself every couple of years, and figure out what I should do next.
- Don’t forget the basics: a grant proposal has to identify a problem or set of problems; outline what is lacking in current approaches; and sketch how you will address these deficiencies and solve the problem. Along the way it should argue that you are the right person to do this work. Usually it’s best to weave your past track record subtly into the entire narrative instead of relegating it to a separate section at the end. Keep in mind that reviewers are asked to judge the proposal based upon the research that is being proposed, and not merely upon the past track record of the PI. (Of course, in practice reviewers rely a lot upon the past track record.)Also, it is useful —for proposer as well as the reviewer— if the proposal states concrete “project goals” sprinkled throughout the writeup. (Create a separate latex environment for this.) Instead of saying something wishy washy like “We plan to further explore area x” say: “Project Goal 4: Use technique blah to design a polynomial time algorithm for problem foo.” Ideally this concrete goal should come after a paragraph or two where you have sketched the prior art, and explained the importance of this goal.
Avoid the temptation to cut and paste text verbatim from your recent papers (or even worse, actual theorems riddled with messy parameters). A research proposal is more like an expository article geared to a broad audience —at least the couple of opening sections.
- In addition to getting the basics right, you should pay attention to the other stuff and do your groundwork. Carefully read the program solicitation, and if possible, talk to NSF program officers. They attend conferences, answer emails, take phone calls, etc. Obviously, they will be most candid in face to face conversations. (Keep your conversation short and to the point, though.) They can give you a sense of funding trends and current buzzwords at NSF, saying things like: “There are three buzzwords in the program solicitation but the last one is more important to us than the first two.” Or “Your work seems relevant to area X and there is a program in area X that is looking to fund foundational work.” Colleagues can also be useful in this process.Such groundwork is especially useful for a new funding program that is in the pipeline. If you know about it in advance, you could have a proposal idea ready —or collaborators lined up—when the solicitation comes out. In general it is much easier to get funded in the first year or two of a new program, before it gets overwhelmed by “proposal pressure.”
- While writing your proposal, be sure to address the buzzwords you have discovered as part of (3). I don’t mean to make all this sound shallow or dishonest. Obviously, if your work has no implication for national security, you shouldn’t claim any. But if there happen to be some, do point them out. (Don’t exaggerate; reviewers are smart.) Another example: if you enjoy working with high school students and have an excellent track record in it, consider making that a component of your proposal. There are no fixed rules, and anything that helps you stand out from the crowd is fine and good.Put yourself in the reviewers’ shoes as you write. They have limited time and have usually received highly specific instructions from NSF (usually including the buzzwords from the solicitation). Make it easy for them to evaluate your proposal. Use short sections with descriptive titles, especially “Broader Impact”, “Postdoc mentoring plan” etc. that NSF wants them to specifically comment on. Use short, declarative sentences that are easy to parse.
- Conversely, if you are ever asked to serve on a selection panel, take careful notes on what worked in the proposals you reviewed and what didn’t. What aspects did the panel dislike? Of course, the quality of research is the most important aspect. But panels can be harsh on good researchers who clearly didn’t put in the time in crafting a good proposal, or who had obviously not read the solicitation carefully.
- Ask colleagues for advice as well as examples of their successful proposals. (Do it indirectly so you don’t put them on the spot. Most people are happy to help.) Ask colleagues who are not in your subarea as well. I find it very stimulating to read a well-crafted proposal not in my research area.
- Work out a writing schedule that works for you. I like to do a 1-page sketch to collect my thoughts and then modify it as I ponder it for several weeks. But then I do the actual writing fairly close to the deadline when I am more focused and efficient. If you plan to seek feedback on your draft, allow time for that.
ADVICE SPECIFIC TO CROSS-CUTTING SOLICITATIONS
Crosscutting solicitations are often judged by panels composed of people from different specialities. So write appropriately. Suppose you wish to work on theory problems arising in computer systems. Be sure to read some successful systems proposals and learn what aspects are important to systems reviewers. Talk to systems colleagues and learn a bit of their lingo. A day or two of such legwork will really pay off, and also improve your research.
Most panelists will not know your past record, and it has to come through clearly in the proposal.
The “groundwork” aspect described earlier (talking to program officers, etc.) is very important for crosscutting program. Some program officers will even go to the trouble of listening to your proposal idea and give you valuable feedback. Sometimes they will give you feedback on a rejected proposal and suggest changes that could allow it to succeed in future.
Things like broader impact, training of underrepresented groups, etc. can be very important. Pay attention to the solicitation’s “buzzwords.” All of this advice is is especially relevant for larger projects. Again, I don’t mean to advocate any dishonesty; just keep those aspects in your mind.
Often crosscutting proposals involve collaboration. The proposal usually should contain contributions from all team members, but one individual should take charge to make the proposal read well. Panels look for the following: Does this collaborative team make sense? How likely is it that these people will actually work together? Have they collaborated before? If your team involves people in different geographical locations, you need to sketch out a plan for how this collaboration will happen: regular meetings, joint postdocs, whatever. (It is wise to give such a plan even if all people are in one place. Sometimes solicitations will require such plans.) Also give a rationale for the team’s composition. (“Doing such a project calls for a mix of skills x, y, z. On our team we have skills x, y, z.”) Ideally do this mental exercise sufficiently ahead of the deadline so you can seek additional collaborators if you realize your team needs to be fleshed out.
Theory Matters 