Advice on proposal writing

Many many people have written about how to write scientific grant proposals, and much of that advice is already online.   Rather than duplicate that work, and recognizing that sometimes different people need to hear advice in particular language, I want to link to some examples.

• Here (pdf) is some advice straight from the National Science Foundation about how to write a compelling proposal.  It's older (2004) and a bit out of date, but the main points are foundational.
• This is a very good collection of advice that has been updated (2015) to reflect current practice about NSF.  
• Here are lecture notes from a course at Illinois that touched on this as well, generalizing beyond the NSF.

Fundamentally, sponsored academic research is an odd thing.  You are trying to convince an agency or foundation with finite (often very finite) resources that allocating some of their precious support to you will be a good thing.  Limiting the conversation to the often ill-named "basic research" (see here and the book therein for a discussion of "basic" vs "applied"), this means work where the primary products of the research are (i) fundamental advances in our understanding of some system or phenomena; (ii) personnel trained in scientific/engineering/research knowledge and skills; (iii) scholarly publications (and/or patents for more technology-focused topics) that report the results, with the intent of propagating the work to the community and having an impact. 

This last one has taken a pre-eminent position of importance because it's something that can be readily counted and measured.  There is a rough rule that many program officers in NSF and DOE will tell you; averaging over their programs, they get roughly one high impact paper per $100K total cost.  They would like more, of course. 

Talk with program officers before writing and submitting - know the audience.  Program officers (including foundational ones) tend to take real pride in their portfolios.  Everyone likes funding successful, high-impact, exciting, trend-setting work.  Still, particular program officers have areas of emphasis, in part so that there is not duplication of effort or support within an agency or across agencies.  (This is especially true in areas like high energy theory, where if you've got DOE funding, you essentially can't get NSF support, and vice versa.)  You will be wasting your time if you submit to the wrong program or pitch your idea to the wrong reviewing audience.   NSF takes a strong line that their research directions are broadly set by the researchers themselves, via their deep peer review process (mail-in reviews, in-person or virtual panel discussions) and workshops that define programmatic goals.  DOE likewise has workshops to help define major challenges and open questions, though my sense is that the department takes a more active role in delineating priorities.   The DOD is more goal-directed, with program officers having a great deal of sway on topics of interest, and the prospect that such research may transition closer to technology-readiness.  Foundations are idiosyncratic, but a common refrain is that they prefer to fund topics that are not already supported by federal agencies.

Think it through, and think like a referee.  When coming up with an idea, do your best to consider in some detail how you would actually pull this off.  How could you tell if it works?  What would the implications be of success?  What are the likely challenges and barriers?  If some step doesn't go as planned, is it a show-stopper, or are their other ways to go?  As an experimentalist:  Do you have the tools you need to do this?  How big a signal are you trying to detect?   Remember, referees are frequently asked to evaluate strengths and weaknesses of technical approach.  Better to have this in mind while at an early stage of the process.

Clearly state the problem, and explain the proposal's organization.  Reviewers might be asked to read several proposals in a short timeframe.  It seems like a good idea to say up front, in brief (like in a page or so):  What is the problem?  What are the open scientific/engineering questions you are specifically addressing?  What is your technical approach?  What will the results mean?  Then, explain the organization of the proposal (e.g., section 2 gives a more detailed introduction to the problem and open questions; section 3 explains the technical approach, including a timeline of proposed work; etc.).  This lets readers know where to find things. 

I'll confess:  I got this organizational approach by emulating the structure of an excellent proposal that I reviewed a number of years ago.  It was really terrific - clear; pedagogical, so that a non-expert in that precise area could understand the issues and ideas; very cleanly written; easy-to-read figures, including diagrams that really showed how the ideas would work.   Reviewing proposals is very helpful in improving your own.  Very quickly you will get a sense of what you think makes a good or bad proposal.  NSF is probably the most open to getting new investigators involved in the reviewing process. 

Don't wait until the last minute.  You know that classmate of yours from undergrad days, the one who used to brag about how they waited until the night before to blitz through a 20 page writing assignment?  Amazingly, some of these people end up as successful academics.  I genuinely don't know how they do it, because these days research funding is so competitive and proposals are detailed and complicated.  There are many little formatting details that agencies enforce now.  You don't want to get to an hour before the deadline and realize that all of your bibliographic references are missing a URL field.   People really do read sections like data management plans and postdoctoral mentoring plans - you can't half-ass them.   Also, while it is unlikely to sink a really good proposal, it definitely comes across badly to referees if there are missing or mislabeled references, figures, etc. 

I could write more, and probably will amend this down the line, but work calls and this is at least a start.