Eu One Page Summary
Eu One Page Summary
Eu One Page Summary
Contact:
Contact person within your organisation
(name + email)
Basic idea:
Concise description (no more than 3 lines!)
summarising the basic idea of the project.
(This should answer the question: Tell me in 10
seconds what your project is about).
Project Title:
Provide a full title and a one-word title/acronym.
See note (1).
Project Type:
The choice is between Collaborative Project, NoE,
CSA. See note (3).
Objectives:
Describe briefly what you are trying to achieve in
the project.
See notes (4), (5).
Key Results:
What concrete results will be produced within the
project itself?
See notes (4), (5).
Impact:
Describe what will be made possible when the
project has delivered its results and achieved its
objectives and these can be taken into use.
See notes (5), (6), (7).
Partners:
Provide three separate lists: HAVE (names of
definite partners), MIGHT HAVE (names of likely
partners) and NEED (profile of the types of
organisations the project needs).
European Dimension:
Why is it important to perform the project as a co-
operation at a European level?
Initiator:
Write either the name of your company (if it is your
own idea) or the name of the other organisation
who has proposed the project and invited you to
join.
Co-ordinator:
There are 3 possibilities: (1) Your organisation co-
ordinates proposal writing and the project itself; (2)
Your organisation co-ordinates proposal writing,
but someone else should co-ordinate the project
itself; (3) Someone else co-ordinates proposal
writing and the project itself.
Duration/phases:
In months. If distinct phases are planned, list
these together with their duration.
Work breakdown:
Identify the main activities of the project
(workpackages).
Estimated budget/EU
financing:
Budget refers to total costs, financing refers to
how much the EU will fund.
EU one-page summary
Page 3 of 4
Guidance Notes
(1) The one word title is very often an acronym but doesnt need to be. So you can just choose
a simple name that you think suits the project. Dont waste time trying to find a perfect
acronym, especially during the early stages of developing a proposal where all you really need
is a label for the project. Also, project goals will evolve as the proposal develops, so what
might have been a perfect acronym at the start may end up being misleading when the project
is submitted.
(2) It is not essential that the proposal should be relevant to any parts of the Work Programme
other than the specific Objective to which it is addressed. However: it strengthens the
proposal if the relevance is wider than just to a single Objective, so try to identify and briefly
describe any relevance to other Objectives, or to more general, high-level objectives of the
Work Programme (as described in its introductory chapters).
(3) You need to read the text in the Work Programme carefully to find out which project types are
allowed for which parts of the Work Programme. This is sometimes specified very precisely
down to the level of individual bullets/sub-sections within a given Objective.
If you dont know the difference between the different project types, you ought to find out
urgently it makes a big difference to what you can do in the project.
(4) It is sometimes difficult to distinguish between objectives and results.
For instance, if you have an objective like To develop a new compiler for C++, it is a bit
redundant to then include New Compiler for C++ as one of the results. If you find such
EU one-page summary
Page 4 of 4
cases arise, take it as a signal that maybe you need to re-think what the objective really should
be. Think about why you want to produce the result. For instance: perhaps the objective is
To make it possible to compile C++ programs twice as fast and the result is the New C++
compiler.
(5) A common source of confusion for evaluators is that proposers fail to make it clear what will
be done within the project itself and what will be made possible after the project. This is a
classic case of something that is so obvious to the writer that it does not get explicitly stated in
the document.
Proposers write sentences like the following: "The project will allow typical car journeys to
be made with 20% less fuel consumption than is typical today". Does this mean that one of
the project deliverables will be a car with a more fuel efficient engine? Or does it mean that
the project will deliver the design documents for a new type of engine - but leave it up to
others to actually manufacture them? Or does it mean that the project will deliver a report
surveying the latest research in the area, and leave it up to others to produce engine designs
and to others still to manufacture the car? All are possible interpretations of the sentence.
It is vital that the evaluator is left in absolutely no doubt about such issues. And it's not good
enough that clarification can be found only by studying many different parts of the proposal:
evaluators don't read every word, and if they stumble on a sentence that is vague when read in
isolation they very soon develop a negative impression.
So: make a very clear distinction between:
* Concrete results that will be BROUGHT into the project, from the partners.
* Concrete results that will be DEVELOPED in the project, using EU money
("Objectives"/"Deliverables").
* Things that will become possible as a result of the project having achieved its
objectives ("Impact").
This may sound rather obvious - but muddle and confusion on this is often a major
contributing factor to proposals being considered "unclear".
(6) Whereas the Objectives and Results descriptions describe the work to be done by the
consortium within the project itself, the Impact section should summarise what will be
possible for others outside the project, using the project results.
Should answer the questions Why are you doing this project?, "So what?", Who cares?,
Why now?. When the project has been completed, how will it make the world a better
place - for society, for business, for standards, ?
(7) The Impact section should aim to educate the evaluator e.g. by providing facts and
figures from policy documents, or by providing other information that makes it clear why the
project is useful.