Proposal Reviews

I recently got an opportunity to review a couple of NSF proposals my professor gave me. Interestingly, one of the proposal was excellent while the other one was mediocre. I thus learned a lot comparing their writing styles.

For those new to the dojo, most state, army and private funding is procured by submitting proposals to the corresponding agencies which are mostly peer-reviewed. The intent of the proposal is to pose research problems, solving which would significantly advance the state of the art. These problems must somehow be related to the authors past work, thereby establishing his/her credibility. In the end, not all problems need to be solved. The idea instead is to establish concrete directions of future research that are promising not only for the author but for the entire community.

While I am no authority on proposal writing, I could point out some "common mistakes" I have noticed thus far.

1. Wish-list: The proposal should not sound like the future-work sections of conference papers. One cannot simply say that NP-hard problems will be investigated without explicating the exact approach. In fact each proposed problem must be devoted a couple of paragraphs at least: one formulating the problem and another giving an insight into the proposed solution methodology and possible challenges.
2. Text-only: Mathematics is a language. Use of equations helps express problems clearly. While it is necessary to keep the description at a higher level, one or two equations per-page is not scary at all.
3. Secret-designs: It is possible for a reviewer to pick up the proposed solution and start working on it. However, proposals which entice reviewers into taking up the problems are always considered the best and always get accepted. Its a risk that has to be taken.
4. Jargon-master: Peer reviewed proposals do not need to use DARPA-like jargon except probably beyond the summary. Buzzwords like cyber-infrastructure should not be used in a proposal that investigates routing protocols.
5. Can-be-generalized: The usefulness of running examples cannot be stressed more. However, generalizing toy-examples is often easier said than done. I have seen at least two proposals that described their approach on toy examples and left the problems at that stage.