Skip to content

Tips for Submitting Proposals to EU FP7 (now H2020) and Others

Among the work I do is the evaluation of research proposals for the Framework Program 7 (FP7), and now H2020, of the European Commission. I review research proposals that are submitted in response to calls that are related to information security. Truthfully, this work is among the more interesting of projects I am involved with.

On account of this occupation of mine, for a few years already, I consider myself authoritative to bring up the following tips to whoever intends to submit a research proposal for European, or other, funding.

Before we start, I would like to state the obvious: The tips below are my own personal opinion, which I formed after evaluating proposals of different types for different entities. They represent neither recommendations, nor normative requirements, by anyone else.

 

Tip #1: Do not be too ambitious

I am not trying to imply that ambition is bad. You cannot get much funding without breaking new grounds. However, realize that you shall not state objectives that you do not explain how you are about to accomplish. Always remember that the people who evaluate your proposal come from the same field as you do. They are generally not impressed by mere rephrasing of the hard problems of the industry and by descriptions of how better off we would be once these problems are solved. We all have the same clue as to what the burning problems are, and motivational text stressing how important the problem is to solve, is essentially preaching to the converted. It gives good background, but it cannot be considered as the meat of the proposal.

You are more likely to instill confidence by bringing up specific problems and describing how you are to address them, than by setting objectives that encompass large core problems that you cannot demonstrate how you are about to solve.

The evaluator obviously does not expect you to draft the solutions as part of the proposal (you wouldn’t need funding for the project if you already had all solutions, would you?) What is required is a decent methodology. We all know what the problems are, we are all motivated to solving them, and we all know that the solutions are not available yet. The funding party seeks to bet its money on the entity that is most likely to solve the right problems, and do so properly; with this in mind your proposal should be written. Describe the problem to demonstrate you understand it, and present your methodology for solving it. If you do not properly explain how you attempt to solve the problem, it does not matter how large and important this problem is.

Tip #2: Be short

As opposed to what some people think, quality of proposals is not measured by its paper weight. A project that keeps a dozen people busy over three years shall generally not take more than 70-90 pages to describe. Don’t try to make it longer than necessary; no one appreciates it, really.

Tip #3: Highlight

Contradicting yet another myth, your proposal will probably be read by its evaluators in its entirety. Nevertheless, your evaluator typically reads 160-200 pages worth of proposals a day. Being human, his/her level of attention deviates throughout the reading process. A skillful evaluator will be able to capture the important points of your proposal also in this situation, with high probability. However, if this proposal is important to you, then why rely on probability?

Just highlight. By highlighting (e.g., using “bold”) key messages describing the merits of the proposal, you ascertain that the evaluator captures these points and comprehends their importance in any case. Besides that, you already know the key merits of your proposal, and the evaluator will appreciate your sharing of this indication with him/her.

Tip #4: Make a good first impression

The first pages matter most. It is often said that when you meet a person for the first time, it takes you a couple of seconds to determine your impression of him/her, and the rest of your time is spent on attempts to justify the initial verdict. You may have noticed that this holds true for documents and books you read as well.

Make sure your proposal makes a good first impression. If you proofread your proposal three times before you submit it, read the first part of it five times. No proposal is ever perfect in every aspect, but the first pages are not the place for spelling errors, unclear statements, or statements that may be found controversial by common wisdom of some experts.

Tip #5: Focus on the important aspects

Every proposal has the key aspects of its merit, and the “surroundings”. Assume that the evaluator figures what the key novelty is, and make sure this is what you put the focus on. Every proposal is for a project that delivers some core value. Identify this core value (e.g., the core problem you are trying to solve), and make sure you elaborate on how you intend to make it happen. Realize that the evaluator will look for exactly this text, and will usually not be fooled into focusing on other, non-key, aspects of the proposal, that may be easier to convince on.

Tip #6: Relate to the framework/programme documents

Every funding program has its plan, program, and/or other framework definition documents. Make sure you read those in their entirety, at least once. Also be certain that you understand all their provisions, and lastly, make sure you relate to the specified objectives in your proposal. To you, the core essence is the proposal, and compliance with the work program or framework is merely one gate to pass. However, to the evaluator, the work program or framework is the core essence, and your proposal is for a project that its Raison d’être (reason for existence) is to serve this program; with the burden of proof falling on the proposal.

That is it for now. Feel free to share your insights or questions as comments (which were recently enabled for this blog).


See also

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

No comments

Add Comment

Markdown format allowed
Enclosing asterisks marks text as bold (*word*), underscore are made via (_word_), else escape with (\_).
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
Form options

Submitted comments will be subject to moderation before being displayed.