EU Project Essentials: From Call to Competitive Proposal

The most useful early question is:

What must be true about this project for an evaluator to see a direct line from the call to the proposed work and from the work to the expected outcomes?

1. Start with the authoritative call

Before drafting, identify the exact topic or call and read the official material around it. Do not rely on a summary page, an old template or a previous proposal as the controlling source.

At minimum, check:

• the live Funding & Tenders Portal topic page;
• the applicable work programme;
• the General Annexes and programme guide where relevant;
• the proposal template and evaluation form;
• any Guide for Applicants, FAQs or topic-specific conditions;
• eligibility, consortium, page-limit and funding-form requirements;
• the expected outcomes, scope and destination or programme objectives.

Arvacore principle: treat the topic text as a specification for the problem to be solved, not as a list of phrases to repeat in the proposal.

2. Decide what kind of project you are actually building

European programmes fund different project logics. An individual frontier-research programme is not designed like a collaborative innovation action. A mobility and training fellowship is not designed like an industrial pilot line.

A useful first classification is:

This table is only a navigation aid. The live call documents determine actual eligibility and scope.

For Horizon Europe collaborative calls, also confirm the action type. RIA, IA and CSA describe different implementation expectations; the topic page and current official guidance remain controlling.

3. Convert the call into a project architecture

Do not begin by dividing pages among partners. First build the project logic.

A compact architecture is:

problem -> call need -> project objectives -> activities -> results -> outcomes -> longer-term impact

For each objective, ask:

• Which part of the call does it answer?
• What result will demonstrate progress?
• Which work package produces that result?
• Which partner or team owns the work?
• What evidence will show that the objective has been reached?
• Which expected outcome does the result support?

If those links are difficult to draw, the proposal usually needs more design before it needs more writing.

4. Build the consortium around the work

A strong consortium is not a collection of impressive logos. Every participant should have a necessary role in producing, validating, using, scaling or governing the results.

Build the partner map from missing capabilities:

• core scientific or technical expertise;
• experimental or validation environments;
• infrastructures and datasets;
• industrialisation or manufacturing capability;
• end users or adopters;
• policy, standardisation or regulatory expertise where relevant;
• exploitation and route-to-market capability;
• communication, dissemination or community reach where genuinely needed.

For each partner, write a one-sentence answer to:

Why would the project become materially weaker if this partner were removed?

That is a better consortium test than counting countries or organisations once the minimum eligibility conditions are satisfied.

5. Turn objectives into work packages

Work packages should express the logic of implementation, not merely divide administrative responsibility.

A coherent work package normally contains:

• a clear purpose linked to one or more objectives;
• tasks with defined ownership;
• inputs and dependencies;
• outputs or deliverables;
• milestones or decision points where useful;
• realistic effort and resources;
• risks and mitigation actions.

Check the interfaces between work packages. Many proposal weaknesses sit between WPs rather than inside them: data are produced but not transferred, a prototype is built before requirements are fixed, validation arrives too late, or exploitation depends on results that are not scheduled to exist yet.

6. Build resources from the work

The budget should follow the implementation architecture.

Start with the people, equipment, travel, subcontracting, consumables, access costs and other resources required to deliver the tasks. Then apply the funding rules of the specific programme and institution.

Avoid designing the project to reach a convenient total and then inventing work to justify it.

For collaborative proposals, person-months should reconcile with tasks, partner responsibilities and work-package timing. For lump-sum calls, the underlying resource logic still matters even when reimbursement is not based on actual-cost reporting.

Always validate salary assumptions, indirect-cost treatment and institutional costing with the relevant host or finance function before submission.

7. Design impact from the beginning

Impact is easier to write when it has been designed rather than added at the end.

A useful chain is:

project result -> user/stakeholder -> uptake mechanism -> expected outcome -> wider impact

Then ask what can block the chain:

• technical performance;
• adoption cost;
• standards or interoperability;
• regulation;
• access to infrastructure or data;
• user behaviour;
• manufacturing capacity;
• skills;
• intellectual property;
• procurement or market structure.

Measures such as dissemination, exploitation, communication, standardisation, policy engagement and user involvement should respond to those real barriers.

8. Treat cross-cutting requirements as part of the design

Open science, research data, ethics, security, gender dimension in R&I content, responsible AI use and other cross-cutting requirements can affect the project architecture.

Do not leave them for the final compliance pass when they materially change:

• methodology;
• data access or sharing;
• participant roles;
• recruitment;
• ethics approvals;
• security measures;
• dissemination routes;
• or exploitation decisions.

The exact obligations depend on the programme and topic, so use the current official guidance.

9. Separate uncertainty from weak implementation

Ambitious research and innovation projects contain uncertainty. The proposal should show that the consortium understands where that uncertainty sits.

Distinguish:

Scientific or technical uncertainty - the answer, mechanism or performance may differ from the preferred hypothesis.

Execution risk - a partner, dependency, procurement, dataset, recruitment plan or technical route may fail to deliver as planned.

Scientific uncertainty can be a source of value. Execution risks should normally have credible controls or alternatives.

For major decision points, state what happens if the preferred route does not work and what information allows the project to choose the next route.

10. Plan the review before the deadline

A proposal benefits from several different reviews because they answer different questions.

Scientific / technical review

Is the idea credible, ambitious and well supported?

Call-fit review

Does the proposal directly address the topic, scope and expected outcomes?

Evaluator-readability review

Can an expert reviewer understand the logic quickly, or is the argument buried in detail?

Consortium review

Do roles, tasks, resources and dependencies reconcile across partners?

Administrative / portal review

Are forms, annexes, budgets, participant data, declarations and required uploads complete?

Build these reviews into the preparation plan instead of attempting all of them in the final week.

11. Use information days and brokerage events deliberately

Different events solve different preparation problems.

Official information days are useful for rule changes, templates, evaluation questions and programme interpretation.

National Contact Point sessions can help applicants understand programme conditions and locate authoritative guidance.

Brokerage events are most valuable when you arrive with a defined topic, a concise capability statement and a clear description of the partner capability you are missing.

Evaluator-led proposal workshops can help expose weaknesses in clarity, criteria coverage and proposal architecture.

After an event, convert contacts and notes into actions: partner discussions, call clarification, a revised concept note or an internal decision. Attendance alone does not improve a proposal.

12. Who can help?

Different support actors are useful at different stages.

• Host-institution research or grants office: institutional commitments, costing, signatures, eligibility and internal processes.
• National Contact Points: programme guidance, official information events and call interpretation.
• Experienced peers or former applicants: scientific challenge and reviewer readability.
• Consortium partners: technical design, implementation, resource ownership and impact routes.
• External proposal specialists: architecture, red-team review, cross-section consistency, figures, impact logic and evaluator-facing clarity.

Scientific ownership should remain with the applicant or consortium. External support is most useful when it strengthens reasoning and communication rather than replacing the intellectual content.

13. Where to find reliable material

Use an authority hierarchy:

1. Funding & Tenders Portal topic/call page - the live call and submission route.
2. Current work programme and General Annexes - programme architecture and standard conditions.
3. Programme guide / Guide for Applicants / evaluation forms - practical and scheme-specific interpretation.
4. European Commission, REA, ERC, EIC, Chips JU or MSCA official guidance - depending on the instrument.
5. National Contact Points and official info days - applicant support and clarification.
6. Arvacore resources - practical interpretation, tools, proposal architecture and reviewer-oriented guidance.

If a third-party guide conflicts with the current official call package, follow the official call package.

A one-page concept note before the full proposal

Before distributing writing tasks, prepare a short concept note containing:

• call/topic and action type;
• coordinator or applicant;
• problem and why it matters;
• 3-5 project objectives;
• main expected results;
• expected outcomes addressed;
• proposed work-package logic;
• partner roles / missing capabilities;
• major uncertainties and risks;
• likely resource drivers;
• first impact and exploitation logic.

If the team cannot agree on this page, writing 40 pages will usually amplify the disagreement rather than solve it.