Common Mistakes in Horizon Europe Proposals and How to Avoid Them
15 mistakes across Excellence, Impact, and Implementation — with practical fixes for each
The Horizon Europe success rate sits between 10% and 15% for most calls. That means for every ten proposals submitted, eight or nine are rejected — many of them by teams with genuinely strong ideas and relevant experience.
In most cases, the difference between funded and unfunded is not the quality of the underlying research. It is the quality of the proposal itself. Evaluators are experienced, time-constrained, and working from a structured scoring form. They reward clarity, specificity, and coherence — and they penalise vagueness, inconsistency, and missing information, even in otherwise strong applications.
This post documents the 15 most common mistakes we see across Horizon Europe proposals — five in each of the three evaluation sections — with concrete examples of what the mistake looks like in practice and how to correct it.
15 Common Horizon Europe Proposal Mistakes
Below is a summary of the 15 most common mistakes that reduce proposal scores across the Excellence, Impact, and Implementation sections.
Excellence
Starting with background instead of the problem
Writing objectives that are not specific or measurable
Weak state-of-the-art positioning
Presenting a methodology without contingency planning
Writing only for specialists and not evaluators
Impact
Confusing outputs with impacts
Ignoring the expected impacts described in the call text
Failing to establish a credible pathway to impact
Treating the DEC plan as a list of conferences and publications
Neglecting open science and open access requirements
Implementation
Designing work packages that do not align with project objectives
Failing to justify budget allocations at work package level
Including partners without clearly defined roles
Providing a superficial risk analysis or no meaningful risk management plan
Across the Entire Proposal
Internal inconsistencies between Excellence, Impact, and Implementation sections
Part 1 — Excellence: Five Mistakes That Cost You Scientific Credibility
The Excellence section is your scientific case. Evaluators assess whether you are addressing the right problem, whether your methodology is sound, and whether your level of ambition is credible. Most weaknesses in this section are not caused by poor science, but by poor communication.
Mistake #1: Starting with Background Instead of the Problem
Many proposals begin with several paragraphs explaining the broader context of the topic. Climate change, artificial intelligence, food security, biodiversity loss, and other major challenges are often introduced in detail before the project itself is even mentioned.
While this background may be accurate and well-written, it rarely answers the question evaluators are asking:
What specific problem does this project solve?
Evaluators review dozens of proposals. They do not need to be convinced that climate change matters or that digitalisation is important. They need to understand the precise gap in knowledge, technology, policy, or practice that your project will address.
Strong proposals therefore begin with the problem rather than the context.
Instead of spending several paragraphs describing a broad challenge, quickly identify the specific limitation that currently exists and explain why it matters. Once the gap is clear, you can then provide the supporting context and evidence.
For example, rather than opening with a general discussion about climate change and agricultural resilience, a stronger proposal would immediately identify a specific challenge, such as the lack of validated, affordable soil moisture monitoring tools for smallholder farms. The broader context can then be used to explain why solving that challenge is important.
Why This Matters
The opening paragraphs set the tone for the entire Excellence section.
If evaluators can quickly understand the problem, they are more likely to follow the logic of your objectives, methodology, and expected results. If they spend the first page searching for the actual research gap, the proposal immediately becomes harder to evaluate.
Quick Fix
Open your Excellence section with the problem statement, not the background.
Within the first paragraph, evaluators should be able to answer three questions:
What is the specific problem?
Why does it matter?
Why has it not yet been solved?
The broader context can follow, but the gap should come first.
Mistake #2: Objectives That Are Not Measurable
Vague objectives are one of the clearest signs that a proposal has not been fully developed.
Objectives such as "improve understanding", "explore opportunities", or "develop innovative solutions" may sound ambitious, but they provide little information about what the project will actually achieve. More importantly, they give evaluators no clear basis for assessing success.
Objectives serve as the backbone of the proposal. Evaluators use them as a reference point throughout the entire application, tracing them through the methodology, work packages, deliverables, milestones, and expected impacts.
When objectives are vague, this traceability breaks down.
For example, an objective such as "advance knowledge in carbon sequestration" raises immediate questions. What knowledge? How will it be generated? How will success be measured? What evidence will demonstrate that the objective has been achieved?
Strong objectives answer these questions directly. They specify what will be developed, validated, assessed, demonstrated, or implemented, and they include enough detail for evaluators to understand what success looks like.
Why This Matters
Objectives are one of the first things evaluators read, and they influence how the rest of the proposal is interpreted.
Poorly defined objectives make it difficult for evaluators to assess the quality of the methodology, the relevance of the work plan, and the credibility of the expected outcomes.
In many cases, weak objectives also create problems in the Implementation section because they cannot be clearly linked to specific work packages, tasks, deliverables, or milestones.
Quick Fix
Apply the SMART test to every objective:
Specific – Clearly define what will be achieved.
Measurable – Include criteria that allow success to be assessed.
Achievable – Ensure the objective is realistic given the project's scope and resources.
Relevant – Demonstrate a clear connection to the project goals and call objectives.
Time-bound – Indicate when the objective will be achieved where appropriate.
A useful test is simple:
If you cannot clearly explain how you will know whether an objective has been achieved, it is probably not specific enough. Rewrite it until success can be objectively demonstrated.
Mistake #3: Weak State-of-the-Art Positioning
The purpose of the state-of-the-art section is not to demonstrate how many papers you have read. Its purpose is to convince evaluators that a genuine gap exists and that your project is necessary to address it.
A common mistake is describing existing research, technologies, or approaches without explaining their limitations. The result is a section that reads like a literature review rather than a justification for the proposed project.
Evaluators often finish these sections with a simple question:
If all of this already exists, why do we need your project?
If the answer is not immediately obvious, the state-of-the-art section has not achieved its purpose.
Another common weakness is relying heavily on publications from the consortium itself or citing only older literature. Evaluators expect to see evidence that the proposal is grounded in the current state of the field and reflects the latest scientific, technological, and policy developments.
Why This Matters
The state-of-the-art section is where your project's novelty and ambition are established.
Without a clearly articulated gap, it becomes difficult to demonstrate innovation. Evaluators may conclude that the project represents only a small incremental step beyond existing work or that the need for the project has not been adequately justified.
A strong state-of-the-art section creates a logical progression:
What currently exists
What has already been achieved
What limitations remain
Why those limitations matter
How the proposed project addresses them
By the end of the section, the need for the project should feel obvious.
Focus on Gaps, Not Summaries
Many applicants fall into the trap of summarising paper after paper without drawing conclusions.
Instead of treating the state of the art as a bibliography, treat it as an argument.
Each piece of evidence should help build towards a clear conclusion that an important challenge remains unresolved.
The strongest proposals do not simply describe previous work. They explain why previous work is not yet sufficient.
Quick Fix
For every existing approach, technology, methodology, or study you describe, add one sentence explaining its limitation.
Ask yourself:
What does this approach do well?
What can it not do?
Why does that limitation matter?
How does my project address it?
The gap you identify is the justification for your project's existence.
Make sure it is impossible for an evaluator to miss.
Mistake #4: A Methodology with No Contingency Planning
One of the fastest ways to lose evaluator confidence is to present a methodology that assumes everything will go perfectly.
Research and innovation projects rarely follow a completely linear path. Technologies underperform, datasets prove incomplete, recruitment targets are missed, pilot sites withdraw, and external conditions change. Evaluators know this because they have experienced it themselves.
A methodology that describes only the ideal scenario often signals inexperience. It suggests that the consortium has not fully considered the uncertainties and challenges that may arise during implementation.
Strong proposals recognise uncertainty and demonstrate preparedness.
Why This Matters
Evaluators are not looking for risk-free projects.
In fact, Horizon Europe often funds ambitious projects precisely because they involve uncertainty and innovation. What matters is whether the consortium understands the key risks and has credible plans for dealing with them.
Acknowledging methodological risks does not weaken a proposal. On the contrary, it strengthens it by demonstrating scientific maturity and realistic project planning.
A proposal that openly discusses potential challenges and explains how they will be managed is generally viewed as more credible than one that assumes every activity will proceed exactly as planned.
What Evaluators Want to See
A strong methodology typically includes:
A clear rationale for selecting the proposed approach
An explanation of why alternative approaches were not chosen
Identification of the main methodological uncertainties or risks
Practical contingency measures if key assumptions prove incorrect
Evidence that the consortium has experience dealing with similar challenges
The objective is not to create a lengthy risk analysis within the Excellence section. It is simply to show that the proposed methodology remains robust even if unexpected obstacles arise.
Think Beyond the Ideal Scenario
When reviewing your methodology, ask yourself:
What happens if recruitment targets are not achieved?
What happens if data quality is lower than expected?
What happens if a pilot site withdraws?
What happens if a technology does not perform as planned?
What happens if validation results do not meet expectations?
If the answer to each question is "the project fails," your methodology is probably not resilient enough.
Strong proposals demonstrate alternative pathways that allow progress to continue even when challenges emerge.
Quick Fix
Add a short "Risks and Contingencies" subsection at the end of your methodology.
It does not need to be extensive. Three to five key methodological risks, each paired with a realistic mitigation strategy, is usually sufficient.
This small addition can significantly strengthen evaluator confidence by showing that the consortium has planned not only for success, but also for uncertainty.
Mistake #5: Writing Only for Specialists
One of the most common mistakes in Horizon Europe proposals is assuming that every evaluator shares the same level of technical expertise as the proposal authors.
In reality, evaluation panels are multidisciplinary. Your proposal may be reviewed by specialists in your field, but it may also be read by innovation experts, policymakers, practitioners, or researchers from related disciplines. All of these evaluators contribute to the final score.
A proposal that can only be understood by a narrow group of specialists risks losing points, even when the science itself is excellent.
Why This Matters
Evaluators cannot award points for ideas they do not understand.
If the objectives, methodology, innovation, or expected outcomes are buried beneath unexplained jargon, technical acronyms, or highly specialised language, non-specialist evaluators may struggle to follow the argument.
This does not mean simplifying the science or reducing technical rigour.
It means presenting the science in a way that allows an educated non-specialist to understand:
What problem is being addressed
Why the problem matters
What the project will do
Why the approach is innovative
What difference the results will make
The technical detail can still be included, but the core narrative should remain accessible.
Write for Understanding First
A useful principle is to explain the purpose before the mechanism.
Many proposals begin with highly technical descriptions of methods and technologies before explaining why they are important. This forces evaluators to decode complex information before they understand its relevance.
Instead, explain the objective first, then introduce the technical details needed to achieve it.
When readers understand the purpose, they are far more likely to appreciate the methodology.
Avoid Unnecessary Jargon
Specialist terminology is sometimes unavoidable, but it should never be assumed.
Technical terms and acronyms should be explained when they first appear. Where possible, use plain language descriptions alongside specialist terminology.
The goal is not to eliminate technical language. The goal is to ensure that it supports understanding rather than creating barriers.
Think Like an Evaluator
When reviewing your proposal, imagine that the evaluator is intelligent, experienced, and motivated—but not an expert in your specific niche.
Could they explain the project's core idea after reading the Excellence section?
Could they describe the innovation in a few sentences?
Could they understand why the methodology was chosen?
If the answer is no, the issue is probably not the science. It is the way the science is being communicated.
Quick Fix
Once the Excellence section is drafted, ask a colleague from a different discipline to read it.
If they cannot clearly explain the problem, the approach, and the expected contribution after reading the section, revise the framing and explanations.
Do not simplify the science.
Simplify the pathway to understanding it.
Part 2 — Impact: Five Mistakes That Undermine Your Real-World Case
Mistake #6: Confusing Outputs with Impacts
This is one of the most common weaknesses in Horizon Europe proposals and one of the fastest ways to lose points in the Impact section.
Outputs are the direct products of your project. These might include reports, datasets, software tools, methodologies, prototypes, publications, training materials, or policy briefs.
Impacts are something entirely different.
Impacts describe the changes that occur when people use those outputs. They explain what becomes different in the real world as a result of the project's results being adopted, implemented, or applied.
Unfortunately, many proposals stop at the output level.
Applicants often present a long list of deliverables and achievements and assume the impact is self-evident. Evaluators do not make this assumption.
Their next question is always:
So what?
If you develop a software platform, who will use it?
If you publish policy briefs, who will read them?
If you create a dataset, what decisions will it inform?
If you organise training workshops, what behaviours will change as a result?
The Impact section should answer these questions directly.
Why This Matters
Horizon Europe does not fund projects simply because they produce knowledge.
The programme funds projects because of the value that knowledge creates.
Evaluators therefore want to understand not only what the project will deliver, but also how those results will be translated into societal, environmental, economic, technological, or policy benefits.
A proposal that describes outputs without explaining their consequences often appears incomplete, even if the underlying science is excellent.
Think in Terms of a Chain of Change
A useful way to structure impact thinking is to move through three levels:
Outputs – What the project produces
Outcomes – What users do with those outputs
Impacts – The broader changes that result
Strong proposals clearly connect all three levels.
They explain not only what will be delivered, but also who will use it, how it will be used, and what difference it will make.
Follow the "Then What?" Test
Every time you describe an output, ask yourself:
Then what?
If you publish a report, then what happens?
If you develop a tool, then what happens?
If you deliver training, then what happens?
Keep asking the question until you reach a meaningful change in behaviour, decision-making, policy, business practice, or societal outcome.
That final change is where impact begins.
Quick Fix
For every output you mention, add one sentence explaining:
Who will use it
How they will use it
What will change as a result
This simple habit transforms a list of project outputs into a credible and convincing impact narrative.
Mistake #7: Ignoring the Call Text's Expected Impacts
Every Horizon Europe topic includes a section describing the expected outcomes and impacts that funded projects should contribute to.
These are not background information. They are one of the most important reference points used during evaluation.
Evaluators are explicitly asked to assess whether the proposal contributes to the expected outcomes and impacts described in the call text. If your proposal does not address them clearly, it becomes difficult for evaluators to justify a high score, regardless of how strong the science may be.
Why This Matters
Many applicants treat the Impact section as an opportunity to describe whatever benefits they believe their project will create.
While project-specific impacts are important, they are not a substitute for the impacts identified in the work programme.
The European Commission publishes these expected outcomes and impacts because they represent the changes the programme is trying to achieve. Projects are funded not only because they are scientifically interesting, but because they contribute to these broader policy objectives.
A proposal that ignores the expected impacts can appear disconnected from the purpose of the call itself.
A Common Mistake
One of the most frequent weaknesses is a generic Impact section that never references the call text.
This often happens when proposals are adapted from previous submissions or when applicants rely heavily on standard impact templates.
The result is an Impact section that may be well written but fails to demonstrate alignment with the specific objectives of the topic.
Evaluators usually recognise this immediately.
Start with the Call, Then Build Beyond It
The strongest Impact sections begin by demonstrating how the project contributes to every relevant expected outcome and impact listed in the call text.
Only after this alignment has been established should applicants introduce additional project-specific impacts.
Think of the call text as the minimum requirement.
Your own impacts should build on it, not replace it.
A Practical Approach
When drafting the Impact section:
Identify every expected outcome and impact listed in the work programme.
Determine which project activities, results, and outputs contribute to each one.
Explain that contribution explicitly in the proposal.
Where possible, provide evidence, indicators, or targets that demonstrate the expected contribution.
This creates a clear line of sight between the objectives of the call and the activities of the project.
Quick Fix
Treat the expected outcomes and impacts in the call text as mandatory requirements rather than optional context.
Create a simple checklist and verify that every expected impact is addressed somewhere in your proposal.
If an expected impact is not covered, either revise the project scope or provide a clear explanation for why it falls outside the project's remit.
The easiest way to lose Impact points is to make evaluators search for alignment.
Make it obvious.
Mistake #8: No Credible Pathway to Impact
Describing what your project will achieve is only half the job.
The other half is explaining how those achievements will reach the people who need them and ultimately create real-world change.
This is the purpose of the pathway to impact.
A pathway to impact is the chain of events, actors, activities, and mechanisms that connects project results to societal, economic, environmental, technological, or policy outcomes.
Many proposals describe ambitious impacts but never explain how those impacts will actually materialise.
As a result, evaluators may agree that the proposed impacts would be valuable while remaining unconvinced that they are achievable.
Why This Matters
Impact does not happen automatically.
A software tool does not create change simply because it exists.
A policy brief does not influence policy simply because it has been written.
A new methodology does not improve practice simply because it has been validated.
Someone must adopt, use, implement, promote, commercialise, regulate, or scale the result before impact can occur.
Evaluators therefore want to understand not only what the project will produce, but also how those results will travel from the consortium to the outside world.
The Missing Link in Many Proposals
A common weakness is describing broad stakeholder groups without identifying the specific actors involved.
Statements such as:
Policymakers will be engaged
Industry will adopt the results
Stakeholders will benefit from the project
sound positive but provide very little evidence of how uptake will occur.
Evaluators immediately start asking questions:
Which policymakers?
Which companies?
Which organisations?
Through what mechanism?
At what stage?
Why are they likely to adopt the results?
If the proposal cannot answer these questions, the pathway remains speculative rather than credible.
Build a Chain of Adoption
A strong pathway to impact explains:
Who the key users are
What results they will use
How they will gain access to those results
Why they are likely to adopt them
What changes will occur once they do
The strongest proposals often benefit from having end users, policymakers, industry representatives, networks, advisory organisations, or public authorities directly involved in the consortium.
Their presence provides a natural route through which project results can be transferred into practice.
Name the Actors
One of the simplest ways to strengthen a pathway to impact is to move from generic stakeholder groups to identifiable actors.
For example:
A specific ministry rather than "policymakers"
A named industry association rather than "industry stakeholders"
A particular advisory network rather than "end users"
Specificity increases credibility because it demonstrates that the consortium has already thought about who will use the results and how engagement will take place.
Quick Fix
Review every impact claim in your proposal and ask:
Who will make this happen?
If the answer is a generic category such as policymakers, industry, or stakeholders, add more detail.
Name the organisations, networks, partners, or intermediaries involved and explain the mechanism through which results will reach them.
The more clearly evaluators can see the pathway from project results to real-world uptake, the more credible your impact case becomes.
Mistake #9: A DEC Plan That Is Just a List of Conferences
The Dissemination, Exploitation, and Communication (DEC) plan is a dedicated sub-criterion within the Impact section and plays a significant role in how evaluators assess a project's ability to maximise its results.
Yet many proposals treat DEC as an afterthought.
A common pattern is a short section listing a few conferences, a publication strategy, and perhaps a social media account. While these activities may be useful, they do not constitute a comprehensive DEC plan.
Evaluators want evidence that the consortium has thought strategically about how different audiences will access, use, and benefit from the project's results.
Why This Matters
Dissemination, exploitation, and communication serve different purposes.
When they are combined into a single generic activity, it becomes difficult for evaluators to understand how the project will create impact beyond the consortium itself.
A strong DEC plan demonstrates that the consortium understands:
Who its target audiences are
What each audience needs
How different results will reach different users
How uptake and engagement will be measured
The more specific the strategy, the more credible the impact case becomes.
Understand the Difference
Although often grouped together under the DEC acronym, dissemination, exploitation, and communication are not the same activity.
Dissemination
Dissemination focuses on sharing scientific and technical results with the research and innovation community.
Typical activities include:
Open-access publications
Conference presentations
Scientific workshops
Public datasets
Open repositories
Evaluators expect a clear approach to open access and, where relevant, open science and data management.
Exploitation
Exploitation focuses on ensuring that project results continue to create value after the project ends.
Depending on the project, this may involve:
Commercial products or services
Business models
Licensing agreements
Standards development
Policy uptake
Follow-on investment
A strong exploitation strategy identifies who will exploit the results, how they will do so, and what support mechanisms are required.
Communication
Communication focuses on raising awareness among non-specialist audiences.
These may include:
Citizens
Policymakers
Farmers
Businesses
Public authorities
Civil society organisations
Communication activities are designed to build understanding, visibility, trust, and engagement rather than to disseminate scientific findings.
Avoid Generic Activity Lists
A list of conferences and publications is not a strategy.
Evaluators want to understand:
Why a particular activity is being undertaken
Who it targets
What result it is expected to achieve
How success will be measured
The strongest DEC plans connect activities directly to project objectives, expected outcomes, and pathways to impact.
Connect DEC to the Work Plan
One of the most common weaknesses is describing DEC activities in the Impact section without showing how they will actually be delivered.
If dissemination, exploitation, and communication are important, they should appear in the Implementation section as tasks, deliverables, milestones, and budget allocations.
Activities that exist only in narrative form often appear aspirational rather than operational.
Quick Fix
Write three separate subsections:
Dissemination
Exploitation
Communication
For each one, identify:
A lead partner
A target audience
At least two specific activities
A measure of success
Then verify that these activities are reflected in your work plan, deliverables, and budget.
If they are not, your DEC strategy may still be a promise rather than a plan.
Mistake #9: A DEC Plan That Is Just a List of Conferences
The Dissemination, Exploitation, and Communication (DEC) plan is a distinct sub-criterion within the Impact section, and evaluators assess it carefully. A common mistake is to treat all three activities as the same thing and then populate the section with a list of conferences, publications, and social media channels.
This tells evaluators that the consortium has not thought strategically about how different audiences will access, use, and benefit from the project's results.
A strong DEC plan recognises that dissemination, exploitation, and communication serve different purposes and target different audiences.
Why This Matters
Evaluators are looking for evidence that your project results will reach the right people through the right channels.
A publication strategy may be appropriate for researchers, but it is unlikely to influence policymakers. A communication campaign may raise awareness among citizens, but it will not automatically create commercial uptake. An exploitation strategy may support market adoption, but it will not replace scientific dissemination.
The strongest proposals recognise these differences and design separate activities for each objective.
What Evaluators Want to See
Dissemination
Dissemination focuses on sharing scientific and technical results with the research and innovation community.
Evaluators expect to see:
Open-access publications
Conference presentations
Public datasets and repositories
Open science and data management practices
Exploitation
Exploitation focuses on creating value beyond the project lifetime.
Evaluators expect to see:
Routes to market
Commercialisation plans
Policy uptake pathways
Standards development
Intellectual property considerations
Clearly identified exploitation owners
Communication
Communication focuses on engaging non-specialist audiences.
Evaluators expect to see:
Defined target groups
Appropriate communication channels
Outreach activities
Measures of reach and engagement
Clear communication objectives
Quick Fix
Write three separate paragraphs: one for dissemination, one for exploitation, and one for communication.
For each activity, identify:
A lead partner
A target audience
At least two concrete actions
Then check that these activities appear as tasks, deliverables, and budget items in your work plan. If they only exist in the Impact section, evaluators may see them as intentions rather than commitments.
Part 3 — Implementation: Five Mistakes That Undermine Deliverability
The Implementation section is where evaluators assess whether your team can actually do what you have promised. The mistakes here are almost always about coherence and detail — or the lack of it.
Mistake #11: Work Packages That Do Not Match the Objectives
Evaluators explicitly check whether the work plan reflects the objectives defined in the Excellence section.
If the proposal presents five carefully crafted objectives but the work packages do not clearly contribute to achieving them, evaluators quickly begin to question the coherence of the proposal.
This creates an impression that the objectives and work plan were developed independently rather than as parts of a single integrated project.
Why This Matters
Objectives define what the project intends to achieve.
Work packages define how those objectives will be achieved.
The relationship between the two should therefore be obvious.
Evaluators should be able to move from an objective to the corresponding work package, task, deliverable, and milestone without difficulty.
When this connection is unclear, confidence in the implementation plan decreases.
A Common Cause
This problem often emerges when proposals are written by multiple authors or adapted from earlier submissions.
One group develops the objectives, another designs the work packages, and no final review is conducted to ensure everything aligns.
The result is a proposal that may contain strong individual sections but lacks overall coherence.
The Traceability Test
A simple way to assess coherence is to create a traceability matrix.
List the project objectives as rows and the work packages as columns.
Then identify which work packages contribute to each objective.
When completed:
Every objective should be supported by at least one work package.
Every major work package should contribute to at least one objective.
No rows should be empty.
No major work packages should appear disconnected from the project's goals.
Any gaps usually indicate a structural issue that should be addressed before submission.
What Evaluators Want to See
Evaluators are looking for a clear line of logic that connects:
Project objectives
Work packages
Tasks
Deliverables
Milestones
Expected results
The stronger these connections are, the easier it becomes for evaluators to understand and trust the project plan.
Quick Fix
Include a short objective-to-work-package mapping in the Implementation section.
This can be a simple paragraph, figure, or traceability table showing how each objective is addressed through specific work packages.
It takes very little space, but it immediately demonstrates project coherence — something many proposals claim but few clearly show.
Mistake #12: A Budget That Is Not Justified per Work Package
A strong budget is not simply a collection of numbers that add up correctly.
It is a reflection of the work plan.
Evaluators expect the budget, work packages, tasks, deliverables, and resources to tell a consistent story. When those elements do not align, confidence in the proposal quickly decreases.
This is particularly important under Horizon Europe's lump sum model, where budgets are allocated at work package level and payment is linked to the successful completion of work package outputs.
Why This Matters
Evaluators are not assessing whether a project is expensive or inexpensive.
They are assessing whether the requested resources are justified by the activities being proposed.
If a work package receives a large share of the budget but contains relatively little work, evaluators may question whether the budget is realistic.
Similarly, if a technically demanding work package has a surprisingly small budget, evaluators may doubt whether the proposed activities can actually be delivered.
The key question evaluators ask is simple:
Does the budget make sense given the work being performed?
A Common Mistake
Many proposals explain the budget only at partner level.
For example, they may describe how much funding each organisation receives while providing little explanation of how those resources relate to specific activities.
This approach makes it difficult for evaluators to understand what the budget is actually funding.
A strong budget justification focuses first on the work packages and then explains how partner resources contribute to those activities.
What Evaluators Want to See
For each major work package, evaluators expect a clear explanation of:
Who is performing the work
The level of effort required
The person-month allocation
Any significant equipment costs
Any subcontracting requirements
Major travel or event costs where relevant
The objective is not to justify every euro individually but to demonstrate that the budget is grounded in the planned activities.
Match Resources to Complexity
Work packages that involve substantial technical development, large-scale piloting, extensive stakeholder engagement, or complex data collection will generally require more resources than coordination or reporting activities.
When resource allocation reflects the actual workload, the budget appears credible.
When the relationship between effort and cost is unclear, evaluators often identify this as a weakness in Implementation.
Think Beyond Evaluation
Budget justification is not only important during proposal evaluation.
A well-justified budget also supports project negotiations, consortium discussions, and future reporting activities.
The clearer the rationale, the easier it becomes to explain and defend resource allocations throughout the project lifecycle.
Quick Fix
For each work package, write two or three sentences explaining:
Who will perform the work
The approximate level of effort involved
Any major equipment, subcontracting, travel, or event costs
This small amount of explanation helps evaluators understand why the work package costs what it does and demonstrates that the budget has been developed alongside the work plan rather than added afterwards.
Mistake #13: Partners with No Clear Role
A strong consortium is not simply a collection of impressive organisations.
Evaluators assess whether each partner has a clear purpose, a defined contribution, and a genuine reason for being included in the project. If a partner appears in the consortium description but has no identifiable responsibilities within the work plan, evaluators will quickly question their necessity.
This issue is particularly common in large consortia, where some organisations may have been added to strengthen geographic coverage, improve stakeholder representation, or satisfy eligibility requirements without being fully integrated into the project's activities.
Why This Matters
Every partner increases the complexity of project management.
More partners mean more coordination, more reporting, more meetings, and more potential risks. Evaluators therefore expect every consortium member to contribute value that justifies their inclusion.
When a partner has no clear role, it raises two concerns:
The consortium may not have been designed strategically.
Resources may be allocated inefficiently.
Even if only one or two partners appear disconnected, evaluators may begin to question the overall coherence of the consortium.
What Evaluators Want to See
For every partner, evaluators should be able to identify:
The work packages they lead or contribute to
The specific tasks they are responsible for
Their role in key deliverables and milestones
The expertise they bring to the project
The experience that makes them suitable for that role
The connection between expertise and responsibility should be obvious.
A partner should not simply be present because they are well known or have participated in previous projects. Their contribution should be clearly linked to the project's objectives and activities.
Avoid Generic Partner Descriptions
One of the most common weaknesses is providing lengthy descriptions of an organisation's history, achievements, or previous projects without explaining how that experience will be applied within the proposed project.
Evaluators are not assessing the partner in isolation.
They are assessing the partner's contribution to this specific project.
Strong consortium descriptions therefore focus on relevance rather than reputation.
The Necessity Test
A useful question to ask for each partner is:
Why is this organisation in the consortium instead of another organisation?
If the answer is not immediately clear, the role probably needs to be strengthened.
The strongest proposals make it obvious why each consortium member is uniquely positioned to deliver their assigned responsibilities.
Quick Fix
Review every partner description and ensure it clearly explains:
What the partner will do
Which work packages and tasks they contribute to
Why they are the right organisation for that role
If you cannot explain a partner's unique value to the project in two or three sentences, either strengthen the justification or reconsider whether the partner is necessary in the consortium.
Mistake #14: No Risk Table or Superficial Risk Analysis
Every Horizon Europe proposal is expected to include a risk analysis, and evaluators pay far more attention to it than many applicants realise.
A risk table filled with generic risks such as technical failure, partner withdrawal, or project delays, all rated as low likelihood and low impact, does not inspire confidence. Neither do mitigation measures that simply state that the consortium will monitor the situation closely.
Evaluators recognise these as placeholder entries rather than genuine risk management.
Why This Matters
Research and innovation projects involve uncertainty.
Technologies may not perform as expected. Stakeholder engagement may be lower than anticipated. Data may prove difficult to obtain. Regulatory environments may change. Pilot activities may encounter unforeseen obstacles.
Evaluators do not expect you to eliminate these risks.
They expect you to recognise them and demonstrate that the consortium has a realistic plan for managing them.
A proposal with no meaningful risks often appears less credible than one that openly acknowledges challenges and presents practical mitigation measures.
Focus on Project-Specific Risks
The strongest risk tables are tailored to the project.
Rather than relying primarily on generic project management risks, focus on the issues that could genuinely affect delivery of the project's objectives.
Examples may include:
Methodological risks
Technology validation risks
Data availability challenges
Pilot site participation risks
Regulatory or policy uncertainties
Recruitment and stakeholder engagement risks
Interoperability or integration risks
The more closely the risks are linked to the project's activities, the more useful and credible the risk analysis becomes.
What Evaluators Want to See
A strong risk entry should clearly explain:
What could go wrong
Why it matters
Which work packages may be affected
The likelihood of occurrence
The potential impact
The mitigation measures that will be implemented
Most importantly, the mitigation measure should be actionable.
Evaluators want to know what the consortium will actually do if the risk materialises, not simply that it will continue monitoring the situation.
Be Realistic
One of the easiest ways to undermine a risk table is to classify every risk as low likelihood and low impact.
Experienced evaluators know that complex projects inevitably face meaningful challenges.
A risk table containing only low-risk entries often suggests that the consortium has not fully considered the uncertainties involved.
Moderate and high-impact risks are not a problem if they are accompanied by credible mitigation measures.
In many cases, their inclusion actually strengthens the proposal by demonstrating realistic planning.
Quick Fix
Include five to eight genuine, project-specific risks in your risk table.
For each one:
Be honest about the likelihood and impact
Explain the consequences for the project
Provide a concrete mitigation strategy
Identify any contingency measures where appropriate
Evaluators are not looking for risk-free projects.
They are looking for evidence that the consortium understands the challenges ahead and is prepared to deal with them effectively.
Mistake #15: Internal Inconsistency Across Sections
This is the mistake that can undermine an otherwise excellent proposal.
A proposal may contain strong science, convincing impacts, and a well-structured work plan. However, if those elements do not align with one another, evaluators quickly lose confidence.
When the objectives described in the Excellence section do not match the work packages in Implementation, when the impacts described in the Impact section have no clear delivery mechanism, or when a partner presented as critical to the project has no meaningful responsibilities, evaluators begin to question the coherence of the entire proposal.
Why This Matters
Evaluators do not assess Excellence, Impact, and Implementation in isolation.
They read the proposal as a single project story.
Strong proposals create a clear line of logic from:
The problem being addressed
The objectives being pursued
The methodology being applied
The results being generated
The impacts being created
The resources being allocated
When these elements reinforce one another, the proposal appears credible and well planned.
When they contradict one another, even small inconsistencies can create doubt.
How This Happens
Internal inconsistency is particularly common in large proposals written by multiple contributors.
The scientific team develops the Excellence section.
The communication or exploitation lead develops the Impact section.
The coordinator or project manager assembles the Implementation section.
Each section may be individually strong, but unless someone reviews the proposal as a whole, inconsistencies often emerge.
These are exactly the types of issues that experienced evaluators notice.
Think Like an Evaluator
As evaluators move through the proposal, they are constantly checking whether different sections support one another.
For example:
Does every objective appear in the work plan?
Do the deliverables support the expected results?
Do the expected results support the stated impacts?
Do the assigned resources match the proposed activities?
Do the consortium partners have roles consistent with their expertise?
The easier these connections are to follow, the stronger the proposal appears.
The Final Coherence Check
Before submission, verify that:
Every objective is addressed by at least one work package
Every deliverable supports a project result or objective
Every impact has a credible pathway and responsible actors
Every partner has clearly defined responsibilities
The budget is consistent with the planned activities
DEC activities described in Impact appear in the work plan
Milestones, deliverables, and Gantt chart dates align
Key numbers are consistent throughout the proposal
Quick Fix
Reserve at least three days before submission for a dedicated coherence review.
Ideally, this review should be conducted by someone who has not written any of the proposal sections. Fresh eyes are far more likely to identify inconsistencies that authors overlook after weeks of drafting.
Many proposals are rejected because of weaknesses in individual sections.
Others are rejected because the sections do not fit together.
The latter is often easier to fix — but only if you allow enough time to find the problems before submission.
Final Thoughts: Most Mistakes Are Fixable
The majority of the mistakes described in this post are not the result of bad science or weak ideas. They are the result of insufficient time, poor coordination between authors, or a lack of familiarity with what evaluators are actually looking for.
The good news is that all fifteen are fixable — if you catch them before submission. A structured review process, a coherence check, and an honest assessment of whether your proposal answers the evaluator's core questions in each section will eliminate most of them.
At SublimeHub, proposal review is one of our core services. We read your draft as an evaluator would — section by section, against the scoring criteria — and provide specific, actionable feedback. If you are preparing a Horizon Europe submission and want a second pair of expert eyes, we would be glad to help.
Writing a Horizon Europe proposal?
SublimeHub reviews and strengthens proposals at any stage — from first draft to final submission. We catch the mistakes before the evaluators do.
