Structural Aspects of Revising Your NIH Grant

A recent query to the blog emailbox echos things I occasionally see on the search traffic leading to the blog and that I deal with IRL. It asks about the more structural aspects to revising a NIH grant application that has been unsuccessful. In the most recent case it is coming from someone pretty junior who has been asked by the PI to learn how to accomplish this task. (I think that’s weird, of course, this is the PI’s job in my view but so it goes.)

One of the best starting places for getting in the proper mindset to revise a NIH grant is to think about the review process. There are a couple of key aspects that I didn’t pick up on until I was actually doing reviews and a couple that I knew but didn’t understand how to incorporate that information.

You are aware that in most cases your grant will go back to the same study section…but sometimes it will not. It will likely go back to at least one reviewer that has seen it before, but also to at least one reviewer new to the application. It is not impossible to get all three retreads or all three new, btw. The reviewers will see the summary statement from the prior review but not the application itself. This last is absolutely key.

You also have to keep in mind that any prior reviewers (and it is not impossible that members on the panel may have read your application closely even if not assigned as a reviewer) may of course remember your proposal. They may also have, illegally, retained a copy in their files to which they may refer.

With that as background, structurally speaking the revised application is duck soup. Here’s what I recommend based on my own approaches and a distilled impression from reviewing grants that I am far from alone in this approach.

At present you have a one-page “Introduction to the Revised Application” to work with. Before the shortening of the R01 application, you had three. Space is most assuredly at a premium in the present era.

You should start off with a sentence to the effect of “This is a revision of IC031666 reviewed in Panel VWXYNot in Feb of 2011 where it received a priority score of 31 and a percentile rank of 26%“.

Recall that while any reviewers who were present at the prior review know the post-discussion score range, they do not know how the mean of the panel went down, nor the all-important percentile rank. I think it a good idea to get this in their minds. Yes, yes, scores are not supposed to be benchmarked on the prior score but let me tell you this is a nearly inescapable psychology of some reviewers.

Next you will be inclined to polish the apple a little bit. Don’t. You simply don’t have room for that crap, nowadays.

The less-obvious no-no is that you will be inclined to reiterate some of the more glowing and approving comments made by the reviewers. I used to do this…

“We are gratified that Reviewer #2 found the PI’s laboratory ‘uniquely qualified’ for the studies and Reviewer #1 thought the Approach was elegant and ideal for…”

…and got smacked down for it by a senior colleague who had study section experience. This is where your understanding that the reviewer has the summary statement right on her desk next to your revised application comes in handy. They can read the good bits and heck, they might have written those themselves. Cut to the chase.

I shouldn’t have to mention this but also resist the urge to talk schmack about the prior review(ers). This doesn’t go well.

The rest is, structurally speaking, quite simple. It should be a listing of the most-important and/or most-consistent criticisms, one by one, with your reply underneath. I like to set quoted material in italics and then answer in plain font. You can do this with a line in the margin (meh) or with font face (yuk) but I like italics better. I also edit this down to a few phrases that communicate the point and combine the same criticism from multiple reviewers if applicable- gotta save space. Remember, they have the summary statement.

Identifying which are the most critical comments is up to the Investigators and it is very hard to set general principles or advice here. Obviously you’d be best off if you can reply to anything that looks like a knock on your prior version but space is limited. Having more-experienced colleagues read your summary statement and draft Intro can be helpful here.

Likewise, the content of your response is going to be up to the criticism, your proposal and your situation in general. My generic advice is to give them something. Throw the reviewer a bone, even if you can’t deliver the response they probably want to see. Never, ever totally stiff a comment by saying there is no way in hell you are going to do it. That is a surefire way to another crappy score.

Where possible it is nice to point the reviewer to where you made the discussed changes. A few parenthetical references to “see Innovation” or “Specific Aim 2” goes a long ways here.

Try as hard as you can not to blow off a criticism that seems important. If it shows up in the Resume of Discussion you’d damn well better have a response. Ditto if your conversation with your PO after the review revealed a major issue of discussion.

Then you end (or possibly end the first paragraph before you get into the point-by-point) with the comment that major changes in the proposal are indicated by a line in the margin (I find this the most readable) or italics or altered font or something. If there really is wholesale revision, you can say this and omit the indication of revised bits. But in most cases you are going to have a few key passages and design features, perhaps some new data, and you want to draw the reviewer’s eye to what is new. Remember, that she does not have access to the prior version of the proposal…and may not have ever seen it before anyway.

These changed bits will hopefully correlate directly with the items you have listed in your point-by-point and indeed with other criticisms that have not made the cut for the one page Intro to the Revised Application.

The quality of your response to the prior criticism is a major factor in review. You do not want the reviewer in any doubt as to just what you have changed. Fortunately, the structural part is relatively easy.

It is only the content of your revision that should have you sweating bullets.