W Randolph Franklin
http://wrfranklin.org/
Rensselaer Polytechnic Institute
21 Aug 2002, revised 9 Jan 2007

Here are some hints for proposal writers, based on my experience as Director of the Numeric, Symbolic, and Geometric Computation Program from Jan 2000 to Aug 2002. At that time, NSG comprised computer graphics, computational geometry, numerical computing, mathematical optimization, automated theorem proving and symbolic computation. I also wrote two CARGO solicitations and organized several ITR and IGERT panels.

This document was inspired by errors seen in past proposals, and by questions asked by PIs. My apologies to people who find the points here insultingly simple.

Disclaimer: These are my personal opinions, and do not represent official government policy. Consult the NSF web site, http://www.nsf.gov/, for the official rules.

- Proposal preparation
- Budget
- Reviewing
- After the decision
- Summary

Proposal preparation

  1. If you want NSF to pay you to research, then start by demonstrating your research skills on its web site. Read the NSF 08-1 Proposal and Award Policies and Procedures Guide, January 2008 and Guide to Programs.
  2. Get the proposal in on time; all proposals received even a minute late are returned.
  3. After fastlaning your proposal, close the feedback loop by downloading it and reading it, both on the screen and on paper.
  4. It's ok to have multiple proposals in consideration simultaneously, subject to published limits, provided that they are clearly different if read by a nonspecialist.
  5. However, because of the load on the reviewers, NSF now prefers PIs to concentrate their efforts on fewer but better proposals.
  6. You are encouraged to use your special skills to address national priorities, e.g., as mentioned in new solicitations and programs, like CDI.
  7. Proposals with a "wow" factor are always welcome. It's hard to define, but can be recognized. IOW, revolutionary, not evolutionary.
  8. New money from NSF requires new ideas from the PI. Saying to send more money because NSF has sent previous money is hated by the reviewers, and always loses.
  9. If you're junior, consider having other people, such as chairmen and deans, read your proposal before submission.
  10. If you're senior, be aware of recent advances in the field.
  11. A proposal should have a unified theme, not just be a list of a dozen misc problems.
  12. The summary should directly say what is proposed, and follow that with the relevance, methods, etc, etc.
  13. Here's my idea of an ideal start to a summary: "We propose to transmute lead into gold. That will build on our earlier successes transmuting lead into copper, tin, and silver. More gold will prevent renewed price inflation. Our proposed technique is to irradiate polywater with N-rays...."
  14. Support from another group, such as a company, is good, if that support is concrete. A mere general reference letter will hurt you.
  15. Read the Fastlane FAQ for info on how to prepare a proper PDF file. A surprising number of proposals are hard to read on the screen, because the PI used obsolete versions of LaTeX, dvips, and gs with the default, bitmapped, cmr fonts.
  16. Small amounts of non-peer-reviewed money may be available for REU supplements, workshops, and SGERs. However, they do come from the same fixed pot of money, and take money away from a peer-reviewed proposal. These have no fixed deadline; ask the Program Director before writing the formal proposal.
  17. Consider applying to broad-based programs, such as IGERT and MRI. Computer scientists submit proportionately fewer proposals than some other disciplines. To the extent that CS is taxed to support those programs, this means that money leaves the community.
  18. When writing the proposal, feel free to consider the listed reviewing criteria as a check list, addressing all that are relevant in the proposal.
  19. Specifically, impact is equal to merit, and must be mentioned in the summary, per the rules in the Grant Proposal Guide. Those PI's who try to do as little as possible and evade the spirit of this rule tend not to be funded.
  20. Impact includes the so-what factor. Will anyone care if you do what you propose?
  21. The impact of your work should extend broadly into society. Why should the taxpayer care?

Budget

  1. Feel free to ask the Program Director what a normal budget is.
  2. The big constraint is that each faculty member's support should be accompanied by a grad student's support. Other than that, I didn't care, provided it was legal.
  3. Larger amounts of money, e.g., for HW, must be requested from another program.
  4. A proposal's budget has no effect on the probability of success (within limits).
  5. Therefore ask for somewhat more than you expect, unless it's a program with a legal maximum.
  6. If your proposal is good enough, but too rich, then you may be asked if you would still be able to do useful research with a smaller budget. If yes, then please submit the revised budget and work statement quickly. Don't argue, or you might get zeroed.

Reviewing

  1. The reviewers may not be exactly in your area; it's your job to convince them. This is a proposal, not a FOCS paper.
  2. NSF is tougher than most journals. It's not unknown for proposals based on papers to be rejected for that reason.
  3. Most funded proposals had at least one excellent review.
  4. Conversely if you are serving on a panel, and you give none of proposals that you review an excellent, then you are telling NSF that your field does not deserve to be funded. This is more a problem in Computer Science than in other disciplines. CS reviewers tend to rate their proposals a point lower on a 5-point scale than do reviewers in other disciplines.
  5. Because of limited funds, even a proposal with one excellent review may be declined if there were other proposals with higher ratings.
  6. Since NSF uses external reviewers, and since a typical proposal gets 4 reviews, and a typical panelist reviews 8 proposals, you owe NSF to serve on one panel for every two proposals you submit.
  7. Serving on a panel also shows you the current proposal quality level. This is especially relevant for certain people who may be too busy to serve the community this way.

After the decision

  1. Unfortunately NSF has many false negatives. That's regrettable; please tell people in the hierarchy that NSF needs more money.
  2. You have the right to a debriefing if your proposal is rejected. Its actual usefulness depends on whom you talk to. Do not wait for a year to do this.
  3. When you do get an award, please send nuggets with nice results and pictures when requested. I was very disappointed that only 15% of my PIs sent me nuggets when I asked in May 2002. Upper management might see this as a sign that this program's money would be better spent on other, more exciting, programs.

Summary

The PI and the Program Director have a symbiotic relationship. The PI wants money. The PD needs ideas and results if the program is to continue and grow. Keep the good proposals coming in.


<< Program Solicitations | Research Page List | Bresenham Circle And Line Drawing >>