For the past several years, I have been involved as an independent expert, commissioned by the European Commission, to evaluate FP7 research proposals (and more recently the Horizon 2020 program). Every time I do this, it entails reading hundreds or even thousands of pages of research proposals in a relatively short time period so good, clear and concise proposal writing would be appreciated. Yet every single time I run into many proposals that frustrate the hell out of me, either because they’re just downright bad or because they might have something there but utterly and completely fail to communicate that in the proposal.
In order to help whoever is vying for funding via these channels, I offer the following advice. Please note that this is my individual view, not explicitly or implicitly condoned by the European Commission in any way, shape or form. Also note there are several experts independently reviewing every single proposal, so just writing it so that I like it will not get you any money. In other words, this advise comes with no warranty whatsoever, YMMV and all the relevant disclaimers. But here goes:
Cut the complicated language. One often wishes the writers would just get the basics of good writing right. Writing in a complicated way and using a wide range of meaningless buzzwords is not a sign that you know your domain, nor it is a sign of intelligence. At best it’s a sign of laziness, at worst it’s an attempt to cover up the lack of any real substance. Write simply. Do not try to complicate things unnecessarily; most of the time what you’re doing is completely feasible to present in very simple terms – dump the buzzwords and the pretend-intellectualism. And, please, check that the sentences you write make sense. Because sometimes they make no sense whatsoever, or do not mean anything.
Be realistic on impacts. Too many times the applicants completely forget they are operating with finite time and resources. I know the EC asks for impact assessments, but this needs to be realistic. Any talk of “saving Europe” or similar grandiose statements through just this one research project is just unrealistic and will be treated as such.
Focus; don’t try to achieve too much. It may seem that the more goals you have in a project and that the wider they are, the better it must be. It’s not. Have a clear focus, because that’s the only way to achieve something. If you focus on everything, you’re not focusing on anything and will accomplish exactly that. This is particularly important for STREP proposals. You do NOT need to address every single element in the call.
Don’t do research for research’s sake. Anything that you attempt to do that goes beyond state-of-the-art must have an application or use somewhere. It’s not good enough to say that after you research topic X for three years, you’ll have good grounds to continue the research.
Don’t waste money – get onto the ‘lean’ boat. Just having multi-year funding from the EC doesn’t mean you can use outdated project methodologies. Two iterations over three years is not “agile”. There is also no reason for you not to borrow a page or two from the Lean Startup. The EC – really the European taxpayers – don’t like to see their money wasted any more than a VC would. Keep in mind that most of the time part of the funding comes out of your tax dollars – would you invest in your project?
Don’t waste money, part II. 15% of project funding to management overhead is unacceptable. So is proposing to buy loads of gear or services at unreasonable prices.
Learn to pitch. Something you should learn from the startups; make sure you develop a compelling pitch – why should your project be funded? Don’t bury the lead on page 78, by when the reviewers will have lost any faith in you coming up with something good. It’s essential for the abstract to be compelling and engaging.
Learn to write (English). I bet you were taught to write essays in school, and scientific articles at the university. Try to remember those lessons: Use clear layout. Break into appropriate sentences and paragraphs. Reference concisely, i.e. in a way that doesn’t interfere with reading (superscripted  is good, [Lastname 1, Lastname 2, publication XYZ, page B, 2010] is not.). Use graphics, but make them clear. Check the spelling. Check the grammar. Write clearly. Avoid sentences that are like 100 words long. Avoid paragraphs spanning half a page. Pay attention to layout and pagination. Check the spelling and grammar again. Make sure the sentences make sense.
Did I mention you need to check the spelling and grammar? Surprising as it may be, it turns out we can’t read minds.
If, btw, your writing or scientific writing courses did _not_ teach you these things, take a better one that does.
Be specific. Particularly when discussing what it is that you’re going to be doing beyond state-of-the-art, it’s essential that you say something more than “research” this and that. And don’t forget to be realistic, too; don’t say you’re going to achieve something awesome which is clearly unrealistic. It is, however, fine to say you will try to do something.
Don’t forget business fundamentals. You need to have a story on how your thing could be used in the “real” world; often this means involving one or more business entities that somehow need to make money. Having a pure research-platform is fine, too, if it’s justified – but “build it and they will come” usually does not go down well as a strategy. Remember to engage the relevant industry in your project.
Innovate, sometimes radically. Don’t be afraid to propose something completely different as opposed to just progressing some field in an expected, linear fashion. If you think the call has inappropriate elements – because sometimes they do – don’t be afraid to criticize them and propose alternatives.
Don’t fall for neomania, i.e. making something new just for the sake of it being new. Not everything new or even innovative is worth doing – show that your use cases are actually useful and have demand, not merely “novel”. Novelty in and of itself is valueless; don’t fall for technological solutionism either.
Test your assumptions. Another concept from the Lean Startup; too many proposals list as some their core thesis assumptions that are entirely untested. At worst they are the result of groupthink of a very unrepresentative group of researchers along the lines of “We’d love this so why wouldn’t everyone?!”. If you base your project on assumptions, you need to test and validate those assumptions early. Oh, and on a related note: Gartner or some other analyst company saying so doesn’t make it so.
Get the right team; trying to make advances in areas where the members are amateurs in and not even engaging the parties with the actual state-of-the-art technology guarantees you will not get anywhere. These are not funds purely for your internal competence development.
Don’t get stuck on the Europe bit; don’t hesitate to bring in non-European partners if you can; not all SOA is of European origin and engaging organizations outside Europe can bring substantial benefits.
Manage the management right. Think about using more modern project management tools than email and Word documents.
Keep the big picture in mind. Having experts onboard is good. Having experts who can see beyond their little domain and into the macro-level developments and understand their significance is better; you need to have an understanding of the macro-environment and trends and how they might affect what you are going to do.
Finally, don’t submit a bad proposal. It just isn’t worth it. It will not get funded and you will have caused reputational damage to all participating organizations and the people identified by submitting stupid things.