• Catastrotunity: Using Rejected Proposals For Good

    Magnifying glass over the definition of Catastrotunity

    There are very few things I am willing to guarantee. However, if you submit grant proposals, you will get rejected. It is going to happen. I guarantee it.

    When it happens, it is going to be upsetting. Because you have spent a lot of time putting together a grant proposal for a project that is hugely important to you. You proudly submitted it, feeling good about the strength of your work and how your project conformed to the solicitation. But after waiting what feels like an impossibly long time, you get the notification your project was not funded, and in all probability, the reviewers’ comments of your proposals.

    What do I think you should do?

    Read the reviews right away. Let’s face it; you are going to anyway. They are likely to make you angry. The reviewers were too picky, or they didn’t understand your project. You will probably find yourself wondering how those people were picked as reviewers anyway, as they obviously don’t know anything about your field.

    Don’t spend too much time reading those reviews right away. Give them a read, get angry, and put them away in a place you can find them when you have calmed down and are ready to look at them again. This might be a few days or a few weeks, whatever you need.

    Because when you are ready, you are going to turn the rejection into a “catastrotunity”.

    Did I just create a new word? No. I wish, but no. I was introduced to this word in my kids’ favorite cartoon, The Penguins of Madagascar. Without boring you with details, four penguins are attempting to sneak themselves, a rhinoceros, and a gorilla out of a zoo and into an arena to see an ice skating show. When one penguin starts to say that the entire plan is a catastrophe, another penguin cuts him off and announces the plan is a catastrotunity—and although it’s not exactly how any of them envisioned it happening—the penguins, the rhino, and the gorilla all make it to the arena for the show and get back to the zoo before anyone notices they were missing.

    What I like about this word is while it is somewhat optimistic (along the lines of “when life gives you lemons, make lemonade”), it also acknowledges the mess of the situation and the determination required to do something good with it. The badness isn’t going away, and since it isn’t, why not just charge ahead and see what can be done?

    So, how do you make your proposal’s rejection into a catastrotunity? Well, depending on the reviews, you can:

    1. Treat it like a journal article R&R (revise and resubmit), where you take some time to strengthen your proposal, rework it, and resubmit it to the same program.
    2. Revise the proposal and submit it to another program and/or sponsor that fits better.
    3. Realize for one of several reasons that the idea isn’t as good as you originally thought and start over with a new or improved project idea.

    In the case of the first option, you are strengthening your project—and let’s face it, fixing the holes during the proposal phase is a lot easier than trying to fix them after the grant has been awarded and you are trying to fix them as you work through your project. In the case of the second option, you are saving yourself the time and effort of chasing down a project that isn’t going to work.

    So, how do you know which option is right for you? Well, let’s go back to those reviews, shall we?

    By this point, you have hopefully relaxed a little and can look objectively at the reviews. On occasion, you will get a comment that doesn’t make any sense. However, you should take most of the reviews as a sign that some editing is in order. Often, just adding some clarity is all you need. Below are some of the most common comments and what they mean for moving forward:

    Most of the reviewers seemed to like it, but one reviewer clearly did not.

    You need to talk to the Program Officer, who was probably in the room and might be able to give you some insight in the discussion. If the reviewer who did not like your proposal was the one with the most experience in your field in the group, then that opinion is going to carry a lot of weight and you need to keep that reviewer’s comments in mind. However, if that reviewer was reacting to some pet peeve (it happens sometimes) and reviewers change at every cycle, the Program Officer may suggest resubmitting with only a few changes. This will give you some time to strengthen your proposal even more.

    The reviewers seemed to generally like it, but didn’t score it high enough to be funded.

    This is frustrating because it’s hard to fix problems that don’t seem to exist. Usually, this means your project has merit, is a good fit for the sponsor and the program you applied for, but it just wasn’t as exciting as other proposals. This is another case where talking to the Program Officer is a good way to get some clarification. Hopefully, the Program Officer will give you a sense of how close you were and what factors went into the decision (if, perhaps, there were a few proposals from your subfield and they only funded one). However, if the reviewers weren’t excited about it, you need to revise your proposal to precisely articulate the significance and impact of your project.

    The reviewers’ comments don’t seem to be applicable to your project or were discussed in your proposal.

    Do not give into the temptation to dismiss the reviewers as wrong. Usually, this means your proposal was not as clear as it could have been. Remember, your reviewers have a lot of proposals to read in a short amount of time and are probably not experts in your subfield. Go back over your proposal and see how distinct and easy it is to read. After you revise it, have colleagues outside your field and/or the Office of Research Development read it and see if they can understand it. You can be confident that if people outside your field can get excited about it, so can a tired reviewer with several more proposals to read before the work day is finished.

    The reviewers had specific technical concerns.

    This is the easiest to fix because it just requires revisions to the project plan. Either the information wasn’t there and you need to add it, or it was there but it wasn’t fully explained and you just need to clarify.

    The reviewers thought the scope was either too ambitious or not ambitious enough.

    If the reviewers might be correct, then talk to your colleagues. If you think the scope is appropriate, then you need to rework the proposal to reflect the scope. Often, this can be solved by adding detail in the project plan and a timeline showing how long it will take to do each task. If reviewers felt it was too ambitious, you need to go into more detail about your qualifications and how your experience shows how you can do what you said you will.

    The reviewers didn’t think your project was a good fit.

    This requires you to talk to the Program Officer since that is the person who best knows and understands the program’s priorities. If your project is a good fit, it means you need to rework the proposal so the fit is easier for the reviewers to see. If your project isn’t a good fit, the Program Officer may have a suggestion for another program or solicitation you should to try instead.

    The reviewers felt the project wasn’t significant enough.

    This is one of the harder problems to correct. The first thing you need to do is really assess the project and see if you, after some reflection, agree with the reviewers. Sometimes, the solution is to find a different agency with different desires regarding innovation and impact (this is usually an applied research versus basic research situation) and rework the project to meet their needs. If you think you have the correct agency and the correct level of significance, you need to go back to the keyboard and rewrite the project description to express that point.

    The reviewers were not convinced the project would succeed.

    This is usually due to either a lack of preliminary data in the proposal or reviewer concerns that the PI or the research team wasn’t the right fit for the proposed project. There is nothing wrong with a project that is a little risky as long as the risks are clearly identified and managed in the proposal. The best way is to present a work plan clearly showing how the project can still move forward if a particular component of it doesn’t work. Also, adding preliminary data that lessens the risk can calm many reviewer concerns. Preliminary data and publications will also help if the reviewers’ concerns are about the research team. If they do not exist, consider adding a collaborator to the project with the experience the reviewers are wanting. But if your project is high-risk high-reward, consider if it would be a better fit for another program (I am thinking of the NSF EAGER program, but there are some others). If preliminary data really is the problem and you don’t have any, consider a one-year project to allow yourself time and funds to get the data you need or another funder who is more comfortable with higher risk projects. Talking to your Program Officer can also help with this.

    Based on what you’ve learned from reading the reviews, talking to the Program Officer, colleagues, and the Office of Research, you can decide your best course of action. But remember, while getting rejected is awful, you can use the experience to develop a proposal that is more likely to be competitive on the next go-round.

    Share this: