How Not To Get Funded by the NSF
Courtesy of the NSF Division of Astronomical Sciences (special thanks to Frank Winkler)
Every year, the Division of Astronomical Sciences receives over 800 proposals. Of these, about 1 in 4 will be awarded. So, how do you write something that will review well? Just about anyone can give you advice on that... Here, we’ll give you some tips on how to do poorly.
How Not to Get Funded: The Fast Path
The following Grant Proposal Guideline (GPG) violations are fatal. If you would like your proposal to be quickly returned unread with a note from your program officer telling you how sorry they are but that their hands are tied, do one of these:
Have more than a one-page Project Summary
You are allowed one page at the beginning of the proposal to summarize the intellectual merits and broader impacts of your proposal. Anything longer than one page will get you turned down very fast.
Have more than 15 pages of Project Description
You are allowed 15 pages to talk about your project and the good things that will come of it. Anything longer than 15 pages and you’ll be eligible to be on the very panel that would have been looking at your proposal.
Leave out any discussion of Postdoc Mentoring
If you’re including a postdoc, don’t write about mentoring them in career planning, preparation of grant proposals, publications and presentations, ways to improve teaching, how to effectively collaborate with researchers, and training in responsible professional practices. This requirement was new in 2009, so no one will blame you for leaving it out. We’ll just return the proposal.
No discussion of Broader Impacts in your Project Summary (a.k.a. the #1 cause of returns)
You’re submitting to the National Science Foundation, not the National Broader Impacts Foundation, right? It turns out these are taken very seriously, and if you don’t include them in your summary, your proposal will be returned.
Soon to be Fast Paths to Non-Funding
For reasons we do not understand, the next two items are left out of some proposals. While their absence is not fatal this year, that may change in the near future.
Don’t include Results of Prior Support in the Project Description
Nobody wants to know if you or your co-PIs have received any NSF Support in the past five years. After all, your past record with NSF funding doesn’t matter, and impressing the reviewers with the results from that work isn’t going to improve your chances of being highly ranked. Really. We promise.
Leave out any discussion of Broader Impacts from the Project Description
Why give up precious space to talk about Broader Impacts, especially after you’ve devoted an entire paragraph to them in your Project Summary? After all, there are two review criteria (intellectual merit and broader impacts) - do you really need to worry about both of them? It turns out the answer is “yes, yes you do.” Not only will the reviewers probably downgrade the proposal if Broader Impacts are missing, we may just send it back unread in the future.
How Not to Get Funded: The Slow Path
If you’d like your proposal to go to review before not getting funded, try some of these!
Cram as much into the Project Description as possible
This is also known as “my project is so interesting, no one will mind...” or “Oh, rarely had the words poured from my penny pencil with such feverish fluidity...” There’s nothing reviewers like more than rambling prose that isn’t concise and to the point, so the more words you can use, the better. Along these lines, below are some tips for making room for all your prose.
Use the smallest possible font size
Most reviewers read proposals on their computers instead of printing them out. And the Acrobat Viewer has a zoom feature, so tiny type doesn’t matter. Besides, picking up a proposal—out of a stack of 30 that need to be read before the meeting—and seeing all that tiny type makes a great first impression.
Use slightly smaller margins
If you need extra room, cheat the margins. Nobody will notice because they’ll be distracted by all the words you’re using. Really. Reviewers like this approach so much, it may soon join the Fast Track to Non-Funding.
Make the figures really small
A picture may be worth a thousand words, but why not use both? Legible axes and distinguishable markers for different data points are overrated. And again, Acrobat does have a zoom feature!
Cut your proposal budget until you can’t do the project
The resources you have to do the project are an important consideration. So a good way to make sure your proposal isn’t successful is to come up with a budget that cuts things like page charges for publications, support for your time, travel to observatories (if you’ll be observing), and money for the postdoc who will be helping wade through the code.
Cite papers that you really really expect to be in journals by the time your proposal is reviewed
Odds are you’ll get to it. And what could go wrong? Especially if important parts are in the hands of collaborators.
Don’t download the completed proposal to make sure it’s OK
The odds of your uploading the wrong version of your Project Description is pretty low, right? Likewise, Fastlane never has any formatting errors. Ever. Trust the proposal will look exactly like what you expect it to.
Don’t proof read
No one equatse typos and other errors with bieng sloppy. And its not like your trying to convince anyone you can cary out a complex porject.
And remember, you don’t need to put your work in context
The entire panel will be super-experts in the minutiae of your field (for example, there will be an entire panel devoted to the composition of NGC 104, right?), so it’s OK to jump right in because the broader problems and longstanding questions that your work will address will be obvious to all.
And no matter what you do, don’t talk to your Program Officer. They might offer advice, tips, or ideas for funding. It’s also not a good idea to try to sit on some panels to get a feel for what successful proposals look like. Instead, listen what the person down the hall who got one 15 years ago has to say. Nothing has changed. Really.