Philip Guo (Phil Guo, Philip J. Guo, Philip Jia Guo, pgbovine)

Writing an NSF Grant Proposal: A First-Timer's Perspective

[Update in July 2014: I did not end up winning this grant, so do not use this as a guide to grant-writing! It is merely a reflection from a first-timer's perspective.]

In my ongoing training to become a professor, I spent my winter break working on my first grant proposal. This experience was like training for and running a marathon for the first time. I managed to cross the finish line (submitting a legit-looking proposal), but my performance wasn't stellar (chances of winning are slim). In the process, though, I learned enough about NSF grants that my next submission attempt will be less arduous.

This article is a reflection on the past eight weeks of my life immersed in grant-writing mode. It's most useful for other first-time applicants, especially for NSF grants. It's useless for experienced applicants since you already know all of this by now. (But maybe it's fun to laugh at my naivete!)

Disclaimer: This article is not meant to be a definitive advice guide. I have never won an NSF grant, so what I say might be bogus. These are just my unfiltered thoughts at the moment.

What you're supposed to do

When I was interviewing for faculty jobs last year, I was SUPER scared about the prospect of competing for grants with experienced veterans. After my first interview, I was so anxious that a part of me was reconsidering this career path. A year later, I'm still scared, but there's no way forward except to try ... and fail, and learn, and re-try.

NSF grants are vital for getting tenure in my field (computer science), so that's what everybody applies for. From talking with over 100 faculty during interviews and informal chats, I kept on hearing two pieces of advice:

  1. The first NSF proposal you submit should be a collaborative grant with senior faculty who have already won NSF grants and developed relationships with program officers.

  2. You should get senior faculty to recommend you to serve on an NSF review panel so that you can get insider knowledge of how grants work from the reviewer's side.

These best practices greatly improve your chances of success when applying for your own grants. But since I'm impulsive, I just jumped the gun and decided to apply for my own sole-PI grant without ever having served as a reviewer. I wouldn't necessarily recommend this path, but forcing myself into a situation that's a bit beyond my comfort level is how I personally learn best.

Timeline

7 weeks before deadline – Saw a somewhat-relevant-looking NSF funding call on Twitter (social media rocks!). Cold-emailed a program officer listed on the website to ask for a time to chat on the phone. That didn't pan out, so I cold-emailed another one and arranged a time to chat.

6 weeks before deadline – Spoke on the phone with the program officer for 40 minutes; introduced myself, asked for high-level advice for a naive first-timer; and pitched three relevant ideas to see which one she liked the most; then decided to pursue the one she was most enthused about. (Tip: Be SUPER nice to these people. And prepare a ton for that initial phone call to make a good first impression.)

6 weeks before – Emailed my department's administrator at the University of Rochester to ask how to get the paperwork started with a 6-week lead time. She was very helpful but told me that she was going to be on vacation starting in 2 weeks and won't be back until after the deadline. So we got most of the initial paperwork done in the subsequent 2 weeks. There were a lot of logistics to set up as a first-time applicant. (Tip: Be SUPER nice to the administrators, since you are relying on them to fill out the proper paperwork.)

5 weeks – Learned about the NSF proposal submission process by reading the GPG (Grant Proposal Guide) and as many advice Web pages as I could find; took a ton of notes. Also, another administrator from my university's grant office forwarded me some relevant PowerPoint Webinar slide decks about the grant for which I was applying.

5 weeks – Started brainstorming concrete ideas and met with Rob Miller, my postdoc advisor, to get high-level advice. In general, I didn't want to take up too much of Rob's time on this proposal since it was for future work that's not related to my current postdoc role. (I would've obviously involved him much more if this were a collaborative grant with him as a co-PI.)

4 weeks – Started working full-time on my proposal. Before I was just doing legwork while finishing up other projects. My first task was to print out four recent NSF grant proposals obtained from colleagues and dissect them in detail. They weren't all relevant to my topic, but studying real examples was still way better than just reading advice guides. I paid close attention to how each proposal was organized, what key pieces of vocabulary they used, how they framed their ideas and presentation, what the proposals all had in common, and how they differed. I also followed up my hunches by asking Rob.

4 weeks – Did a ton of background reading and collected all of the relevant BibTeX citations for my proposal. For more details, read Intense Single-Tasking.

4 weeks – Iterated a lot on the one-page project summary and solicited early-stage feedback from a few people.

3 weeks – Started my three weeks of full-on writing of the proposal itself. For more details, read Writing for Work.

2.5 weeks – Emailed four colleagues to ask each for a short letter of commitment. These letters are optional, but my program officer told me that they might help my case, since I'm applying as a first-timer and sole-PI without a prior track record. These are not letters of recommendation or support for me (since those aren't allowed); rather, they simply state how each person plans to collaborate with me on the proposed project.

0.5 weeks before deadline – Finished writing; printed out to do final editing by hand; Rob graciously offered to read over the whole thing the night before the deadline, which was awesome considering he's not involved in this proposal. Fiddled with a bunch of tedious last-minute paperwork and then submitted!

(Note that my deadline was one week before the actual NSF deadline. The university grant office usually wants PIs to submit materials to them a week beforehand so that they can double-check everything and then send it off to the NSF.)

Proposal structure

The 15-page Project Description forms the bulk of your proposal and is what your reviewers will be scrutinizing most closely. First, make sure your font sizes and margins adhere to NSF standards, or else your proposal might get rejected without review! (In particular, LaTeX font sizes and margins can be annoying to set, so watch out.)

Some grants will recommend or impose a specific structure. The one I applied for had no structure requirements, so this was the one I used. But when in doubt, carefully read the call and any associated FAQs.

  • Title
    • A long, descriptive title seems fine; mine had 13 words, but I've seen some that were up to 17.
  • Introduction (2.75 pages)
    • Make this really good. If someone reads only this section, they should be sold on your proposal. In fact, if they read only the first page, they should be sold.
    • Intellectual Merit – needs its own subsection!
    • Broader Impacts – needs its own subsection!
  • Desired Outcomes and Evaluation Criteria (0.75 pages)
    • What are your main research questions, and how do you plan to evaluate whether you are succeeding?
    • Keep this section separate from your introduction to prime the reviewers about evaluation.
  • Background (2.5 pages)
    • Related work to set the stage for your contributions.
    • SUPER important to show that your proposal is grounded in the appropriate literature.
    • This section contains the bulk of your references, which ranges from 40 to 80 papers. Note that your bibliography doesn't count toward the 15-page limit.
  • Proposed Research (5.5 pages)
    • The centerpiece of your proposal. Your time to shine!
  • Evaluation Plan (2.5 pages)
    • Be very concrete about how you plan to run your evaluations. You aren't obliged to do exactly what you propose, but it's important to show that you've thought carefully about experiment design.
  • Timeline for Implementation and Evaluation (0.4 pages)
    • Include a table showing what you plan to do for each season of the funding period (e.g., Spring of Year 1 ...). Again, you don't need to follow this exact timeline, but it's important to come up with something feasible.
  • Advisory Board and Evaluators (Unfunded Collaborations) (0.4 pages)
    • This section is optional, but I included it since I attached letters of commitment from external collaborators.
  • Results From Prior NSF Support (0.2 pages)
    • This section is mandatory. I just mentioned that I'm a first-time applicant but got part of my Ph.D. studies funded by the NSF Graduate Research Fellowship.

5 of the 15 pages in my proposal had a figure, which broke up the monotony of the wall of text.

The good, the bad, and the ugly

The good:

  • Brainstorming high-level future research ideas is exciting! If you're not excited about this process, then you should instead be in industry making a lot more money :)

  • It was a good excuse for me to do a deep-dive into related work, which was really fun, enlightening, and helpful for my future projects.

  • Since the work involved only writing, I could predict my pace fairly well and make consistent forward progress every day. In contrast, when programming or running experiments, sometimes I'd get stalled for days due to unexpected snags.

The bad:

  • It was difficult to motivate myself to work really hard every day knowing full well that the chances of success are slim. Aside from the usual competitiveness of peer review, there are also higher-level political factors that affect funding priorities.

  • It was also hard for me to write convincingly in future tense about work that I haven't yet done. I suppose this gets easier with practice, though.

The ugly:

  • There are lots of forms to fill out, and I've heard horror stories about proposals getting rejected due to some minor paperwork-related error. Thus, I was super paranoid about triple-checking everything. Don't underestimate the time it takes to check over all of the details, even if administrators are helping you along the way.

  • The FastLane Web interface is, errr, quirky. Sometimes PDF documents that you upload won't get properly processed. (One trick that worked for me was to print an existing PDF as a new PDF on my Mac, and then re-submit.) Also, the character count checker for the Project Summary text boxes is super funky, especially if you add newlines into your text. So don't wait until the last minute to submit everything because, chances are, something will break.

Tips for first-timers

My naive impression of how NSF reviews work is that they want to know:

  1. Is this an awesome proposal?
  2. Is the proposer in a good position to implement it?

As a first-time applicant, you're at a severe disadvantage for the second criterion since you don't yet have a track record on NSF-funded projects. Here are some ways to mitigate this disadvantage:

  • Propose a project that's a continuation of your dissertation work or something that you've done in the recent past, since you already have momentum there. Of course, the risk is that your proposal might look too incremental and not visionary enough.
  • Don't propose a giant project that requires a lot of funding and complex resources over a long time period, especially if you are a sole PI. Talk to your program officer about defining a modestly-sized initial project to hopefully get you in the door.
  • Add an advisory board and attach letters of commitment from each member to show that you have the support of some senior colleagues. However, read the GPG carefully to learn the rules regarding external letters.

Email me at philip@pgbovine.net if you have more thoughts. I still have a lot to learn!

Created: 2014-02-01
Last modified: 2014-02-02
Related pages tagged as assistant professor life: