How to get through to interview

This is a rough guide on how to increase the chances of your proposal being successful at the first stage, where grants are short-listed by an expert panel for the next stage (typically the interview). I am writing this for a couple reasons: First, having set on multiple panel sessions of a major funder for discovery/basic life science in the UK I have seen hundreds of applications which allowed me to get a sense of what the main errors are where grants typically fail at this stage. Second, I am getting increasing requests for meetings from prospective candidates where I find myself repeatedly giving the same advice so I am hoping to save some time here, whilst also making this info accessible to prospective candidates who are less inclined to contact me. Third, it is somewhat sad (and a little tiring) to see the same errors being made over and over again and I take no joy in repeatedly pointing them out.

So, here are the cardinal errors you should avoid:

Don’t waste the time of your reader.

Panel members assess mind numbingly large volumes of projects. As a result they have only very limited time to read your grant. Think of that time as the single most limited resource and use it wisely! To achieve this you should: Write your grant in an intuitive way. Panel members, whilst likely working in an area that is related to your field, are often not experts in your particular field. Therefore, it is really important that you write your project in a way that allows a non-expert (but someone with a basic understanding of the area) to ‘get it’ at the first read. Guide the reader logically through your project and take the technical stuff down a notch or two. Feedback from colleagues, especially those outside your immediate area, or even friends who aren’t scientists will help you achieve that. Other things that help is to avoid jargon, don’t overuse acronyms and make sure you explain them properly, and intuitively designed figures. Design your figures well. Don’t overload your figures with information that panel members won’t have time to digest. Also, use font sizes that are readable without zooming in to 500%. Make your grant enjoyable/interesting to read. I usually allocate myself a specific amount of time on reading each grant and I am quite strict with this. In some instances, however, I find myself spending more time than I allocated myself because I got so interested in the project that I couldn’t stop reading. Ultimately, as scientists we get a kick out of learning new stuff (it literally pushes the happy button in our brains). Effective grant writers use this to their advantage.

Don’t design a ‘piecemeal’ project.

Often grants fail because the work packages are not coherent enough. This seems obvious but it happens more often than you think. Without a clear coherent framework that holds it all together, or a clear common goal that provides focus your grant will fail at the first hurdle. This shows typically up in projects where each work package could also be an individual grant. Ask yourself this: Is the whole project more than simply the sum of its parts? Do the results of the individual work packages contribute to the main goal in a complementary fashion? Can the goal of the project be achieved without work package X? The answer to these questions should be, yes, yes, no.

Don’t be a pyramid! Be an onion.

Whilst your work packages should all contribute to one single goal in a complementary fashion, the interdependence between them should be minimal. Often grants fail to convince a panel because subsequent work packages depend on the success of earlier work packages. Ask yourself this “Can I still do work package X if work package Y fails?” To give a specific example, say your project relies on developing a specific technology that is used in other work packages, what will you do if that fails? In other words, the work packages in your project should be onion shaped, where each work package adds another layer, rather than being pyramid shaped where work packages are hierarchically stacked on top of each other. However, sometimes dependencies between work packages are unavoidable, but in this case you should have a convincing risk mitigation plan in place. On that:

Don’t forget to include a risk mitigation plan!

Sounds basic, I know, but you’d be surprised how many applications actually don’t have one. In your risk mitigation plan don’t make up ‘strawman arguments’ (i.e. risks that actually aren’t risks) or dress up something as a risk mitigation plan that isn’t. Instead, honestly talk about the risks and come up with a genuine plan B if plan A fails. Panel members do cut you some slack, especially when the potential gains are high and they often say things like “If plan A doesn’t work, then plan B will still critically advance our understanding”. But they can get annoyed when risks are not properly acknowledged or swept under the rug.

Don’t go on a fishing expedition.

Basic science necessarily means to go into unchartered territory, which is why you need hypotheses to help you navigate this. Not having clear hypotheses in a research project is like Magellan attempting to find the western passage to the spice islands without bringing a compass. It is ok to have several hypotheses, with contradicting outcomes for example where there are two competing theories predicting two different outcomes. This is often a big plus as it derisks your project since scientific advance is almost guaranteed.

If you do go on a fishing trip …

Sometimes hypotheses free approaches are required, especially when the aim is to find patterns in big data like genome-wide transcriptomics or epigenomics or brain imaging data. If you do that, be explicit about it and state the necessity for your hypothesis-free approach, and tell us how you will use the data to generate/test specific hypotheses.

Don’t be incremental.

Programme level grants are expected to deliver something new, something that has the potential to really bring about a transformative knowledge gain. New exciting projects often entail the applicant going out of their comfort zone, to do something new. This may require to bring in collaborators to cover expertise you don’t have, which is often seen as a positive as the project benefits more people and also means that you grow as a researcher. What you want to avoid is to give the impression that you ask for funding to just continue your operation to do some ‘more of the same stuff’. An exception here is where ‘more of the same stuff’ is so much more that is in itself transformational, like for instance mapping the whole brain (synapses and all) of a new model organism.

Make sure you appropriately contextualise your project.

In other words, make sure you cite the relevant literature. A guaranteed way to sink your proposal is to promise doing something new, which actually has already been done by previous work which you don’t properly refer to.

Don’t oversell and underdeliver.

If you promise the moon, show how your project could potentially deliver it. For example, if you state that your project potentially identifies actionable targets for treating disorder X, but you don’t show how, the panel will pick that up as a big negative.

Avoid missed opportunities!

This comes up a lot, and while not necessarily a deal-breaker in itself it can be the straw that breaks the camel’s back. Ask yourself this “Do I optimally use all resources/techniques/data to maximise the potential for knowledge gain?”

Don’t rush the stuff that ‘goes into boxes’.

Project applications always have multiple parts, with a main part (i.e. often a pdf you upload as the description of the project) and then the bits and bobs that go into the boxes which the application form ask you to fill. This could be a description of your research environment, your previous accomplishments, your approach to a positive research culture, PPIE approaches, your experience as mentor, approach to environmentally friendly research, etc. Panel members actually do read that stuff! So, take them seriously. You get brownie points for being specific and creative here. For example, if you describe how you contribute to a more inclusive and positive research culture point to specific examples you have, or actions you plan to take, instead of just saying some generic stuff on how you are a generally nice person.

Acknowledgements

Thanks to Anthony Isles for comments and suggestions