Grant Playbook Theme 1

 

 

 

Welcome 

When starting a new proposal, it’s helpful to have an overview of the writing process. This page serves as a guide for those getting started with grant writing.  

Note that SEISMIC is able to purchase copies of The Grant Application Writer’s Workbook, a more comprehensive book filled with resources about grant writing (while funds last). Fill out the Google Form if you would like a copy! 

 

GOOGLE FORM

Is the money really needed? Is it about prestige? Is it a way to get a project team moving in one direction? Fulfilling proposed project responsibilities is a ton of work, and, in general, grants take more time and effort than is accounted for by budgeted salaries.

The NSF Division of Undergraduate Education programs are well-advertised, but there may be other good NSF programs (even outside of those in the STEM Education Directorate) for funding SEISMIC-related work. Every SEISMIC university maintains information about different funding programs (internal, external, government, foundation, etc.). As an example, information from the University of Michigan's Office of Research and Sponsored Projects is here.

Note that a lot of NSF programs have deadlines on predictable cycles, but they are always subject to change! NSF is required to publish the calls for proposals a minimum of 90 days ahead of the deadline. Putting together a brand new NSF proposal from scratch (assuming a lead role and only relying on team members for editing, essentially) takes about four weeks (120 to 160 hours). If you're submitting to an agency or program new to you, add at least a week. If you're revising a previously submitted proposal with basically the same team, subtract one week.

It can be helpful to draft almost everything in a single Google document, using the document outline feature to navigate around. Typical subsections of the project description include the overview, review of relevant literature, context, project plan, personnel, external feedback, broader impacts, and results from prior NSF support (which is required). Emphasize working in live documents with your collaborators, and try to make the budget documents live as much as possible, too. Especially for collaborative proposals, it can be difficult for each institution to have transparency into all the budgets.

  • The creation of the overview should occur early, within about the first week of concerted proposal development.
  • The overview should set up the gap in knowledge or lack of something, the statement of need, the overall objective, the central hypothesis (if applicable), the specific aims or research questions, and the expected outcomes. 
  • One other thing that is important to draft at this stage, is what the project team (broadly) would do to answer each of the research questions and who would do it. It is important to start getting the project team coalescing around what activities the project would fund and this can help set a preliminary set of parameters for the budget.
  • Get feedback on the overview from the project team and, if the project team is on board, the program officer and any other colleagues who could provide useful feedback.

  • The project plan (a.k.a. research plan) and budget have to be developed in concert because you need to propose a level of activity that can be reasonably funded (at least on paper). Delineate the tasks that should be done in more detail under each of the research questions. Begin to address more specific questions like which student populations would be involved and which semesters data would be collected or analyzed in.
  • Find a budget template specific to the agency from your university that you can use as a sandbox. Do not create your own budget spreadsheet; you will mess it up! Play around with how much the total budget can cover in salaries, travel, etc. Many people will suggest requesting the maximum amount of funds (i.e., if the call for proposals allows budgets up to $1M, do not request $700K; rather expand the project and request something closer to $1M).
  • For collaborative proposals where funds are being split between institutions, set budget limits from the beginning for each institution. This avoids last-minute re-budgeting issues if in total you are very close to the overall budget limit.

  • Once the overview, project plan, and budget are in reasonable alignment, it is time to flesh out the rest of the main proposal document (the project description). Connect the overview and the project plan with the background literature information that fills in the gap, write about the qualifications of the individuals involved (including prior experience working together), write the plan for what the advisory board will do, and draft the broader impacts statement.
  • Ideally, the full project description would be ready with at least (!) a week to go before the main deadline so that collaborators have time to provide feedback. Be careful about how you ask your collaborators for feedback at this stage. Emphasize to collaborators that they need to write suggested edits, not just make hundreds of comments. Be careful also about when (what will you have time to incorporate?) and how you ask for them (live vs. static document versions). Missteps at this point can be costly in terms of time and you are probably already stressed from being close to the deadline.
  • Draft good versions of the figures and tables. These are so clutch for reviewers who are almost always reading the proposal alongside at least a half dozen other proposals.
  • At the same time, draft the budget justification. This is also not a place to spend a lot of energy intellectually. The justification is a dry document with no narrative. It has to be extremely precise and is almost written like a contract (i.e., it is more than fine to copy language from other previously used budget justifications). Everything has to match the budget exactly.

Sometimes you can find colleagues outside of the main project team to review the full project description. This is valuable but should only be done if you’re superhuman and have at least a week for them to provide feedback and at least a week to respond to the feedback prior to the internal budget routing deadline. Anyone new to the proposal at this stage will have conceptual edits that undoubtedly will require reworking the budget, the project plan, etc.

  • Finally, write the project summary which is essentially a short version of the overview.
  • Do several final reads to dot the i’s and cross the t’s that help keep the proposal “reviewable” as well as compliant with all the annoying internal and NSF rules (e.g., no “...” in references, current and pending totals must match the budget exactly, no rounding errors, etc.). Remember that it is the job of those in research support offices to catch these little things and, in a way, to not trust the PIs to do things right. 
  • Submit the appropriate documentation internally (to the research administrator) and in the platform at hand (e.g., FastLane). Wait about six months and see what happens 🙂