Increase your chances for NIH, NSF or other funding: connecting your proposal with the community’s problem
At this point in your research career, chances are you know what it feels like to spend a lot of time, energy, and effort writing a grant proposal. And when that proposal comes back with a poor score—or worse, when reviewers dismiss it out of hand—it can be frustrating and disheartening.
You might think… “Well, proposal selection is just random.” And while this take on things helps preserve your faith in yourself—which is an important thing—I’ve observed in my own work, and during 10+ years of working with clients, that it’s not as random as we think it is. There are substantial and significant things that we can do in our proposals to affect the likelihood that reviewers are going to have a positive reaction.
I’m going to share a strategy that I wish I’d known when I started writing research grant proposals. It’s not necessarily intuitive, but can dramatically increase the chances of your proposal writing efforts producing fruit.
In a nutshell, don’t come in too hot.
Resist the temptation to start right off with, “Hey everyone, I’ve got a cool idea! And here’s why it’s so great! That’s why you should give me the funding for it!”
It’s an easy mistake to make, when you’re excited to share your project, your approach/solution, and why you think it’s important.
Instead, what we need to be doing to build trust with our reviewers is to start by building a story that connects our work with known problems that the community—as represented by the reviewers and program officers—is trying to solve.And to be clear, for those who are tempted to try connecting to reviewers by adding a broad/general introductory statement that shows the importance or significance of the work, understand that’s not what I’m suggesting here. I’m talking about showing a more specific problem, that the field is currently facing, for which your work is a potential solution.
Not addressing the problem is the problem
Rather than staying theoretical about this, let me give you an example from one of my successful NIH R01 proposals.
The Idea Spark
I was teaching a bioinformatics class and discussing a computer approach called Markov chain Monte Carlo (MCMC). I was really excited about it and intrigued by some of its applications.
The Actual Problem
At the same time, we had this big problem in the lab of integrating different data sources to get a unified picture of protein modifications. We were generating different types of mass spectrometry data, and I had a graduate student who was trying to integrate these by hand. It was very painful. Seeing this juxtaposition, I wondered if the MCMC analysis could be used to solve some of the problems that we were having with integrating the datasets.
The Proposal
Now, if this is not your field, all you need to know is that I went on to propose this idea as an NIH ROI on the use of MCMC to solve the problem of integrating different data sources to find post-translational modifications on proteins.
However, I didn’t start out of the gate in the first few paragraphs of the specific aims page with anything about MCMC, even though that was the core of the proposal.I knew that would only connect with a small subset of the potential reviewer audience. I knew most of them were not going to geek out on Markov chain Monte Carlo. If I led with that and happened to connect with one of the few people in the world who geek out on MCMC, what a stroke of luck! But that’s a big if. That’s trusting success to randomness.
Your reviewer’s problems are your problems
Instead, I started by asking myself, what is it that this reviewer community IS really excited about? They’re excited about new computational solutions to the problem of finding post-translational modifications on proteins by integrating different types of mass spectrometry data, because it’s so hard to do this by hand. (Not to mention that existing programs for doing this were very limited.)
So, on the Specific Aims page, but also in the Significance section, I led with the difficulties of finding and identifying these post-translational modifications on these proteins. I built a whole story around that. And that story, step by step, ultimately led up to how the solution was going to be this MCMC approach.
In aim number one, I mentioned MCMC briefly, but that was the only mention of it on the aims page. Instead of gushing about what excited me about MCMC, I focused on building a story to connect with the community. I made sure my proposal spoke to something that they were excited about having addressed. This was the groundwork I laid before I got into the details of what I was excited about doing, which was building these MCMC models.
Looking behind the curtain
In order to connect with the reviewers, I had to really understand the community’s frustrations, pain points, and interests. How did I come by this understanding? Through community research.
In that particular case the community research part was relatively easy, because our own lab was facing this same problem. Integrating the datasets by hand was time-consuming; we saw that other people were having the same pain that we were having. Someone had tried to write a very basic software program to address this, but it was a really challenging problem and their solution was quite limited.
Once it was clear to me that there was a problem the community wanted solved, it was just a matter of bringing my solution in to be the answer. Later on in the proposal, we talked a lot about the details of our MCMC approach. But initially, on the aims page, it was all about connecting to reviewers—through their frustrations and their desire for a solution.
Save yourself and learn this early
Community research is something I’ve covered in detail in every iteration of The Grant Foundry Course, because it’s so essential. If I had learned the important strategy of connecting with the reviewer’s already existing problems earlier in my grant-writing career, it would have saved me countless hours and energy spent on proposal writing.
What it really comes down to is getting out of our own heads when we’re writing our proposals, and instead, moving into the mindset of the reviewer. What is this reviewer community thinking? What are the funders thinking? And how can we make sure that what we write on the specific aims page connects with the discussion that is already going on in the reviewer’s thoughts, rather than just starting off with our own ideas?
Avoiding other pitfalls in proposal preparation
Failing to ground your proposal in the discussion already happening in your community is one of the biggest traps I see people fall into—and used to fall into myself. Taking your reviewer’s viewpoint into perspective is one of the critical pieces of successful proposal writing. But how exactly do you do that?
