Substantially increase your chances for funding: make sure you know what your reviewer community wants.
Chances are, at this point in your research career, you know what it feels like to spend a lot of time, energy, and effort to write 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.
When you know your idea is good but it gets rejected anyway, the natural reaction is often, “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 random factors, but there are also substantial and significant things that we can do in our proposals to affect the likelihood that reviewers are going to have a positive reaction.
One thing you can do now to improve your proposal’s chances
This is a strategy that I wish I’d known when I started writing research grants. It’s not necessarily intuitive, but can dramatically increase the chances of your proposal writing efforts producing fruit.
To explain, let’s start with what not to do. In over a decade of helping clients write grant proposals, I’ve observed certain tendencies. One of them is to approach proposals from a starting point of, “Hey everyone, I’ve got a cool idea! Here’s my proposal for it! And here’s why it’s so great! That’s why you should give me the funding for it!”
You might say, isn’t that what a grant proposal is? Aren’t I supposed to tell them why my idea is so cool?
The answer is no, not directly. It’s not the first thing that we should present to them. That comes later, after we’ve built an appropriate frame for it.
OK, I can hear you asking, what should I be doing, then?
Don’t come in too hot
It’s an easy mistake to make, when we’re excited to share our project with the world. That is to “come in hot” presenting your approach/solution and why you think it’s exciting and 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 say: “I can solve this by adding a broad/general introductory statement that shows the importance or significance of the work,” understand that’s not what I’m referring to here. What I’m referring to is showing a more specific problem that the field is currently facing for which your work is a potential solution.
Rather than staying abstract about this, let me give you an example from one of my successful NIH R01 proposals.
I was teaching a bioinformatics class and discussing a computer approach called Markov chain Monte Carlo (MCMC). I was really excited about it at that time in my career and I was intrigued by some of the applications of it.
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.
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 very, very small subset of the potential reviewer audience. I knew most of them were not going to geek out on Markov chain Monte Carlo because there are very few people in the world who geek out on that! If I led with that and happened to get lucky, then maybe I would connect with one of those geeks—but that’s a big if. That’s trusting success to randomness.
Choose the right starting point
Instead, I started by asking myself, what is it that this reviewer community IS really excited about? The answer I came up with is this: 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. (And: 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 ever so briefly, but that was the only mention of it on the Specific Aims page. Instead of geeking out on what I was excited about (MCMC), I was focused on building a story to connect with the community, and making sure that this proposal was addressing 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. This is something I’ve covered in detail in every iteration of The Grant Dynamo Course, because it’s so essential.
In that particular case this part was relatively easy, because our own lab was facing this same problem. Integrating the datasets by hand was time-consuming and painful. We looked around and 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.
I realized the key to this: there’s a frustration about this in the community.
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, the frustrations they have, and their desire for a solution.
I wish I had learned this earlier
If I had learned this important strategy of connecting with the reviewer’s already existing problems earlier in my grant-writing career, it would have saved me countless time and energy spent on proposal writing.
I once had a proposal triaged, which means it was so poorly ranked on initial review that they didn’t even bother to bring it to the study section for review. I had a technology, I had a technique, and boom, I started out right away with the details of that on the specific aims page. I was convinced it was great, but reviewers weren’t buying it. I hadn’t convinced them that this would make their lives better, that this would realistically solve any problems that they cared about having solved.
This illustrates that 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 tune into the discussion already happening in your community, and starting your proposal from there, is one of the biggest traps I see people fall into—and used to fall into myself. But there are quite a few other pitfalls that I wish I had avoided early on in my career that led to painful rejections.
Rather than make this post really long, I’ve created a separate training where I go into five of the major traps that people get stuck in while trying to write a fundable research proposal. These are things I wish I had known about, that would have led to greater funding and success with considerably less frustration and rejection early in my career.
You can register and participate in that training for free right here. It’s about 75 minutes long, and includes real tips and strategies you can implement right now.
I look forward to hearing your questions and thoughts on the essential strategies and methods I share with you in that training!
Try It Out
For the proposal you are currently working on – what PROBLEM is your community facing that you have a solution for? Can you clearly articulate the problem? What discussions are going on within your community and how does your work fit into those discussions?
And don’t forget to register to learn about the other traps.