The Implementation Section Explained
Work Packages, Tasks, and Deliverables
How to design and write the Implementation section that evaluators trust — and that actually works once you are funded
Of all the sections in a Horizon Europe proposal, the Implementation section is the one that most directly determines whether a funded project succeeds. The Excellence section makes the scientific case. The Impact section makes the value case. But the Implementation section makes the feasibility case — it answers the question every evaluator is asking: can this team actually deliver what they are promising?
And yet the Implementation section is also the one where proposals are most likely to be structurally weak. Work packages that do not map to objectives. Deliverables that describe activities rather than outputs. Gantt charts that contradict the task descriptions. Risk tables filled with generic entries. These are not signs of bad science — they are signs of a proposal that was assembled rather than designed.
This post explains how to design and write an Implementation section that holds together: from the logic of work package structure, through the discipline of task and deliverable definition, to the Gantt chart, the risk table, and the resource justification. Each element is explained with concrete examples of what strong and weak practice look like.
What Evaluators Are Looking for in Section 3
Evaluators assess the Implementation section by asking three fundamental questions.
First, does the work plan logically follow from the objectives defined in the Excellence section? Evaluators should be able to trace every objective through to specific work packages, tasks, deliverables, and milestones.
Second, is the proposed plan realistic? This includes the budget, timeline, resource allocation, and consortium composition. Evaluators want confidence that the proposed activities can actually be delivered within the available time and resources.
Third, has the consortium thought carefully about risk? Strong proposals identify the most significant scientific, technical, operational, and management risks and present credible mitigation measures.
Key point: The Implementation section is where evaluators look for internal consistency. Objectives, work packages, deliverables, milestones, resources, timelines, and budgets should all tell the same story. The strongest proposals feel as though every element was designed as part of a single coherent plan rather than assembled independently.
Work Plan Structure
A strong work plan should provide a clear and logical route from project objectives to project results.
Evaluators expect work packages to be organised around the project's goals and methodology. Each work package should have a clear purpose, well-defined tasks, and identifiable outputs that contribute directly to the project's objectives.
A common weakness is designing work packages around individual partners or disciplines rather than project logic. When this happens, the work plan can appear fragmented and difficult to follow.
Task Descriptions
Tasks are the building blocks of the work plan and should explain exactly what work will be carried out.
Strong task descriptions are specific, actionable, and include clear responsibilities and outputs. Evaluators should understand what will be done, who will do it, and what the task will produce.
Weak task descriptions often focus on activities rather than outcomes. Statements such as "coordination meetings will be organised" describe an action but not the purpose or expected result of that action.
Deliverables
Deliverables are one of the primary ways evaluators assess whether a project has a credible implementation plan.
Strong deliverables are concrete, verifiable outputs with a clear purpose and due date. They should provide evidence that progress is being made and that the project is generating meaningful results.
Weak deliverables often consist primarily of internal reports or management documents. While these may be necessary, they rarely demonstrate scientific, technical, or societal progress on their own.
Milestones
Milestones should represent meaningful decision points or significant achievements during the project.
A good milestone signals that a critical stage has been completed, validated, or approved. It provides evaluators with confidence that progress can be monitored throughout the project lifecycle.
A common mistake is treating milestones as duplicate deliverable deadlines. Milestones should mark important moments in the project's development, not simply indicate that a document has been submitted.
Gantt Chart and Timeline
The Gantt chart should reflect the actual sequence of activities described throughout the proposal.
Evaluators often compare the narrative description of the work plan against the timeline. Any inconsistencies can raise questions about the quality of planning.
The strongest proposals use the Gantt chart to demonstrate dependencies between tasks, logical sequencing of activities, and realistic timing for key outputs.
Team and Resources
Evaluators assess not only whether the consortium has the right expertise, but also whether effort has been allocated appropriately.
Each partner should have a clearly defined role that contributes directly to the project's objectives. Resource allocation should be justified by the activities each partner is expected to perform.
A common weakness is providing lengthy partner descriptions that read like generic CVs without clearly explaining why each organisation is essential to the project.
Risk Analysis
Risk management is one of the most overlooked parts of the Implementation section.
Strong risk analysis identifies specific risks, assesses their likelihood and potential impact, and presents realistic mitigation measures. Evaluators want evidence that the consortium has considered what could go wrong and has a plan for responding.
Weak risk tables often rely on generic statements such as "the consortium will monitor the situation closely" without explaining what actions will actually be taken if a risk materialises.
The best risk analyses demonstrate preparedness, realism, and a clear understanding of the project's critical dependencies.
The Architecture of Work Packages
Work packages are the structural units of a Horizon Europe project. They are how the project is organised, funded, managed, and reported. Getting the WP architecture right is the most important single decision in the Implementation section — because every other element (tasks, deliverables, milestones, budget, team roles) flows from it.
The standard WP architecture for a collaborative RIA/IA
Most successful Horizon Europe collaborative projects follow a broadly standard WP architecture, with variations depending on the project's scope and the call requirements:
WP1 Project Coordination and Management
Lead: Coordinator | Duration: M1–M42 | Budget: ~6–8% of budget
Consortium governance, reporting, quality assurance, financial management, ethics compliance, and communication with the Commission.
WP2–WPn Research, Development, and Innovation
Lead: WP leader (per WP) | Duration: Varies — typically M1–M30 | Budget: ~60–75% of budget
The scientific and technical core of the project. Each WP represents a coherent stream of activity — a research phase, a technology development track, a validation campaign — with its own objectives, tasks, and deliverables.
WP(n-1) Pilots, Validation, or Demonstration
Lead: Industry or end-user partner | Duration: Typically M13–M36 | Budget: ~10–15% of budget
Real-world testing and validation of results. Where the project transitions from development to demonstration, this WP provides the evidence base for impact and exploitation claims.
WP(n) Dissemination, Exploitation, and Communication
Lead: Coordinator or communication lead | Duration: M1–M42 | Budget: ~8–12% of budget
All DEC activities: publications, datasets, communication channels, exploitation planning, policy engagement, clustering, and stakeholder activities.
How Many Work Packages?
One of the most common questions in proposal development is how many work packages (WPs) a project should contain. There is no universal answer, but there are some practical guidelines.
Too few work packages can make the project difficult to manage. When a single WP covers a large amount of work, it becomes harder to assign responsibilities, monitor progress, and demonstrate logical project structure.
Too many work packages create the opposite problem. An excessive number of WPs increases coordination effort, introduces unnecessary complexity, and can make the proposal appear fragmented.
Small Research and Innovation Actions (RIAs)
For smaller RIAs, typically with budgets of €1–2 million, three to five partners, and durations of around 36 months, a structure of approximately five to seven work packages is often appropriate.
A common structure includes:
One Project Management WP
Two or three research and development WPs
One pilot, demonstration, or validation WP
One Dissemination, Exploitation, and Communication (DEC) WP
Medium-Sized RIAs and Innovation Actions (IAs)
For projects in the €3–5 million range involving six to ten partners and lasting around 48 months, seven to ten work packages is often a reasonable target.
These projects typically include:
One Project Management WP
Four or five technical or research WPs
One or two pilot, validation, or demonstration WPs
One DEC WP
Large-Scale Innovation Actions
Large projects with budgets above €6 million, ten to fifteen partners, and durations of four to five years often require ten to fourteen work packages.
This allows sufficient structure to manage multiple technical streams, large-scale demonstrations, stakeholder engagement activities, and project-wide coordination.
A typical structure might include:
One Project Management WP
Five to seven research, development, or innovation WPs
Two or three pilot or demonstrator WPs
One DEC WP
Coordination and Support Actions (CSAs)
CSAs generally require fewer work packages than research projects because they focus on coordination, networking, policy support, stakeholder engagement, and capacity building rather than scientific research.
In many cases, four to seven work packages is sufficient, including:
One Project Management WP
Two to four thematic activity WPs
One DEC WP
A Practical Rule
The number of work packages is less important than the logic connecting them.
Evaluators rarely ask whether a project has seven or nine work packages. Instead, they ask whether the structure is easy to understand, whether responsibilities are clear, and whether the work packages collectively deliver the project's objectives.
A well-structured project with seven coherent work packages will almost always score better than a project with twelve work packages that exist primarily because different partners wanted their own WP.
The WP Design Principle: One Coherent Goal per Work Package
A common mistake in Horizon Europe proposals is trying to fit too much into a single work package.
Each work package should represent a coherent stream of work with a single overarching objective — something that can be planned, monitored, delivered, and evaluated as a distinct part of the project. This principle is particularly important under the lump sum model, where work packages are the basis for planning, reporting, and payment.
When a work package contains several unrelated activities, it becomes difficult for evaluators to understand its purpose. It also becomes harder to define meaningful deliverables, milestones, and success criteria.
Signs That a Work Package Is Too Broad
A work package may have become too broad if it includes activities that do not naturally depend on one another.
For example, a work package that combines literature review, technology development, stakeholder engagement, policy analysis, and dataset preparation is likely trying to achieve too many different things at once. Although each activity may be important to the project, they do not necessarily belong within the same work package.
When reviewing a work package, ask yourself a simple question:
Can I summarise the purpose of this WP in a single sentence?
If the answer requires a list of several unrelated objectives, the work package may need to be divided or restructured.
What a Focused Work Package Looks Like
A strong work package has a clearly defined objective and a logical sequence of tasks that contribute directly to that objective.
For example, a work package focused on sensor development and laboratory validation might include:
Development of the sensor prototype
Calibration under controlled conditions
Laboratory testing against reference equipment
Validation of performance metrics
All activities contribute to a single outcome: a validated sensor prototype ready for field deployment.
Because the objective is clear, the deliverables, milestones, resources, and budget are also easier to define and justify.
Why EvaluatorsCare
Evaluators use work packages to understand how the project will be implemented. When each WP has a clear purpose, the project appears organised, manageable, and credible.
By contrast, work packages with broad or incoherent scopes often create confusion. Evaluators may struggle to understand how activities relate to one another, whether resources are allocated appropriately, or how progress will be measured.
A useful rule is simple:
One work package should answer one major project question or deliver one major project result.
If a WP appears to be doing several unrelated jobs at once, it is usually a sign that the structure needs refinement.
How to Write Tasks That Actually Mean Something
Tasks are the building blocks of a work package. They are the specific activities that collectively deliver the WP objective and provide the foundation for deliverables, milestones, budgets, and timelines.
Writing strong tasks is often harder than it appears. Many proposal writers naturally describe activities rather than outputs, producing tasks that explain what people will do but not what the task is intended to achieve.
The Task Design Discipline
A well-designed task should contain four key elements:
A specific task title that indicates what is being produced or achieved
A concise description of the work to be carried out
A clearly identified lead partner
A defined timeframe, including start and end months
The task title itself is important. Strong task names describe an output, process, or achievement. Weak task names simply describe an activity.
Avoid Activity-Based Task Titles
Many proposals contain task names such as:
Sensor testing activities
Stakeholder consultation
Coordination of pilot activities
Dissemination
While these describe activities, they do not clearly communicate the purpose or output of the task.
When an evaluator reads a task title, they should immediately understand what the task is intended to deliver.
Focus on Outputs and Results
Strong task titles are more specific and outcome-oriented.
For example:
Sensor calibration and performance benchmarking
End-user requirements analysis
Pilot site deployment and operational monitoring
Scientific publication programme
These titles immediately communicate the purpose of the task and provide a clearer connection to project objectives and deliverables.
The accompanying task description should then explain what work will be performed, who will lead it, what outputs will be generated, and how success will be measured.
Make Tasks Traceable
Each task should contribute directly to a work package objective and, ultimately, to one or more project objectives.
When evaluators read a task description, they should be able to answer three questions:
What is being produced?
Who is responsible?
How does this contribute to the project?
If any of these questions remain unclear, the task probably needs refinement.
Task Numbering and Naming Conventions
Use a consistent numbering system throughout the proposal, such as:
T3.1
T3.2
T3.3
This makes it easier to cross-reference tasks across work packages, deliverables, milestones, Gantt charts, and risk tables.
Naming conventions should also remain consistent. Wherever possible, use noun phrases that describe outputs, achievements, or processes rather than generic activities.
Practical Tip
A useful test is to read the task title on its own.
If the title immediately suggests a clear output or achievement, it is probably well designed.
If the title simply describes people doing something — such as research activities, coordination activities, or stakeholder engagement activities — it is likely too vague.
As a rule of thumb, task titles should read almost like deliverable titles. The best tasks naturally imply what will be produced, making the work plan easier for evaluators to understand and assess.
Deliverables: The Evidence That Your Work Packages Are Complete
Deliverables are the formal outputs submitted to the European Commission. They provide evidence that a work package has been completed and that the project is producing the results it promised.
Under the lump sum model, deliverables play an especially important role because they are one of the primary mechanisms used to demonstrate that work has been successfully carried out. Even in non-lump-sum projects, evaluators use deliverables to assess whether the implementation plan is credible and whether the proposed outputs are realistic.
Broadly speaking, deliverables fall into two categories.
Scientific and technical deliverables include outputs such as datasets, software tools, methodologies, validated protocols, technical reports, and research findings. These are the deliverables that demonstrate scientific and innovation progress.
Management and administrative deliverables include outputs such as data management plans, ethics deliverables, communication plans, periodic reports, and governance documents. These support project implementation but are generally not the primary evidence of scientific achievement.
The Anatomy of a Strong Deliverable
A well-designed deliverable contains several important elements.
Deliverable Number
Deliverable numbering should follow a clear and consistent structure throughout the proposal, typically using the format D[WP].[number] (e.g., D3.2 or D5.4).
Inconsistent numbering creates confusion and makes it difficult for evaluators to cross-reference deliverables with work packages and tasks.
Deliverable Title
The title should clearly describe the output being produced.
Strong deliverable titles are specific and informative. Rather than using generic titles such as WP3 Report or Technical Deliverable 3, focus on what the deliverable actually contains.
A title such as Validated Soil Moisture Sensor Calibration Protocol for Three Climatic Zones immediately communicates value and purpose.
Deliverable Type
The European Commission requires deliverables to be classified according to their type, such as:
Report
Dataset
Software
Other
The chosen type should accurately reflect the output. A dataset should not be classified as a report simply because it is accompanied by documentation, and software tools should not automatically be categorised as reports.
Dissemination Level
Each deliverable must include a dissemination level that determines who can access it.
Common classifications include:
Public
Consortium
Restricted
Evaluators increasingly expect scientific and technical outputs to be publicly accessible whenever possible. Marking everything as consortium-only can raise questions about openness and exploitation potential.
Due Date
The due date should reflect the actual sequence of work.
Evaluators often check whether deliverable deadlines align with the timing of tasks and milestones. A deliverable cannot realistically be submitted before the activities required to produce it have been completed.
Strong proposals demonstrate clear logical links between tasks, milestones, and deliverable due dates.
Deliverable Description
The short description included in Part B is more important than many applicants realise.
Rather than using a single generic sentence, provide a concise explanation of:
What the deliverable contains
How it will be produced
Why it is important to the project
These descriptions help evaluators assess both quality and credibility.
Common Deliverable Mistakes
Many proposals weaken their Implementation section through poorly designed deliverables.
Common problems include:
Generic deliverable titles
Inconsistent numbering structures
Incorrect deliverable classifications
Unrealistic due dates
Minimal descriptions that provide little useful information
Excessive reliance on management reports rather than project outputs
A Simple Rule
Every deliverable should answer one question:
What tangible evidence will demonstrate that this part of the project has been successfully completed?
If the answer is clear, specific, and verifiable, the deliverable is probably doing its job.
How Many Deliverables per Work Package?
There is no universal rule for the number of deliverables a work package should contain. However, there are some practical guidelines that can help create a structure that evaluators find credible and easy to follow.
As a general principle, each major phase of work within a work package should produce at least one deliverable. Deliverables provide evidence that progress is being made and allow evaluators and project officers to assess whether the work is advancing as planned.
A work package that runs for 36 months but produces only a single deliverable at the end often raises concerns. Without intermediate outputs, there is little evidence of progress throughout the project lifecycle.
A useful rule of thumb is to aim for at least one deliverable every 12–18 months within each major work package.
For work packages that span the entire project duration, consider aligning deliverables with key phases of work. For example:
A requirements or design report following the initial planning phase
A validation or pilot report following testing activities
A final synthesis report at project completion
The goal is not to maximise the number of deliverables but to provide meaningful evidence that important stages of work have been completed.
Deliverables vs Milestones: The Distinction That Matters
One of the most common mistakes in Horizon Europe proposals is confusing deliverables and milestones.
Although both are used to monitor project progress, they serve different purposes.
Deliverables
A deliverable is a tangible output that is formally submitted to the European Commission through the Funding and Tenders Portal.
Examples include:
Reports
Datasets
Software tools
Methodologies
Protocols
Guidelines
Deliverables provide evidence that specific work has been completed and are often used by evaluators to assess project quality and progress.
Milestones
A milestone is not a document. It is a control point that marks the achievement of an important objective, decision, or stage in the project.
Milestones are verified through a means of verification rather than through the submission of a deliverable.
Examples include:
Completion of pilot site deployment
Ethics approval received
Successful completion of system validation
Go/no-go decision following testing activities
Completion of stakeholder recruitment
Milestones help demonstrate that the project is progressing according to plan and that critical dependencies have been successfully addressed.
Choosing the Right Means of Verification
Every milestone should have a clear and credible means of verification.
Depending on the milestone, this may include:
Signed meeting minutes
Ethics approval documents
Pilot deployment records
Training attendance records
Technical validation results
Written confirmation from responsible partners
The means of verification should provide sufficient evidence that the milestone has genuinely been achieved.
A Common Mistake to Avoid
A frequent weakness in proposals is listing the same event as both a deliverable and a milestone.
For example, if a validation report is submitted as a deliverable, there is usually no need to create a milestone on the same date simply stating that the report was completed.
Deliverables and milestones should complement one another, not duplicate each other.
A useful distinction is:
Deliverables prove that work has been completed.
Milestones prove that progress has been achieved.
Strong proposals use both strategically to demonstrate a clear and credible implementation pathway.
The Gantt Chart: More Than a Visual Decoration
Many proposal writers treat the Gantt chart as a formatting exercise completed shortly before submission. Evaluators do not.
In a Horizon Europe proposal, the Gantt chart is one of the most important consistency checks in the entire application. It provides a visual representation of the work plan and allows evaluators to verify whether the narrative, tasks, deliverables, milestones, and timeline all align.
If your task descriptions state that a task runs from Month 7 to Month 12, but the Gantt chart shows it running from Month 1 to Month 6, evaluators will immediately notice the discrepancy. Even small inconsistencies can undermine confidence in the quality of project planning.
For this reason, the Gantt chart should be built from the work plan, not the other way around. Define the work packages, tasks, deliverables, and milestones first. Only then should the Gantt chart be created as a visual representation of those elements.
What a Good Gantt Chart Shows
A strong Gantt chart provides more than a timeline. It demonstrates how the project will actually be delivered.
Evaluators should be able to see:
Every task within each work package
Accurate start and end dates for all activities
Deliverable due dates clearly marked
Milestone dates clearly marked
Dependencies between activities where relevant
Partner involvement and leadership responsibilities
A good Gantt chart tells the same story as the rest of the proposal, but in a visual format.
Common Gantt Chart Mistakes
Tasks Running for the Entire Project
One of the most common mistakes is showing large numbers of tasks running continuously from Month 1 to Month 42 or Month 48.
This often suggests that tasks have not been properly defined or prioritised. Most activities have a natural beginning and end. When everything runs for the full project duration, evaluators may struggle to understand the sequencing of work.
Define realistic start and end dates based on when inputs become available and when outputs are expected.
Deliverable Dates That Do Not Match Task Completion
Deliverables should generally appear after the tasks required to produce them have been completed.
If a deliverable is scheduled before the corresponding task finishes, evaluators may question whether the work plan has been carefully designed.
A useful practice is to review the deliverables table and Gantt chart together, ensuring that dates are fully aligned.
Missing Dependencies
Projects rarely consist of independent activities.
Many tasks depend on the completion of earlier tasks. For example, pilot deployment may depend on successful system development, while validation may depend on pilot implementation.
Where important dependencies exist, make them visible. Evaluators want to see evidence of logical sequencing rather than a collection of unrelated activities.
No Visible Partner Contributions
The Gantt chart should help evaluators understand who is responsible for the work.
Including partner participation or leadership information allows evaluators to assess workload distribution and identify whether resources have been allocated appropriately across the consortium.
Different Names Across Proposal Sections
Task names, deliverables, and work package titles should be identical throughout the proposal.
A surprisingly common mistake is using one name in the narrative, another in the Gantt chart, and a third in the deliverables table. This creates confusion and gives the impression that different sections were developed independently.
Consistency is essential.
A Practical Rule
The Gantt chart should never introduce new information.
Instead, it should provide a visual summary of information that already exists elsewhere in the proposal.
If an evaluator can move between the narrative, the work package descriptions, the deliverables table, the milestones table, and the Gantt chart without finding contradictions, your Implementation section is probably in good shape.
The Risk Table: Showing You Have Thought About What Could Go Wrong
The risk table is one of the most important — and most frequently underdeveloped — parts of the Implementation section.
Evaluators are not expecting a project with no risks. In fact, a proposal that claims to have no meaningful risks can appear unrealistic. What evaluators want to see is evidence that the consortium understands the challenges it may face and has credible plans to address them.
This is particularly important under the lump sum model, where failure to complete a work package can have direct financial consequences.
What Belongs in the Risk Table?
A strong risk table should contain between five and eight project-specific risks.
These should be risks that arise directly from your project's methodology, technologies, pilot activities, stakeholder engagement strategy, regulatory environment, or consortium structure.
Examples might include:
Technology performance below expected thresholds
Pilot site withdrawal or low stakeholder participation
Regulatory changes affecting project activities
Delays in ethics approval
Data availability challenges
Failure to achieve validation targets
Generic risks such as budget overruns, partner withdrawal, or staff turnover can be included where relevant, but they should not dominate the table.
The strongest risk tables focus on the risks that are genuinely unique to the project.
What Makes a Good Risk Description?
A useful risk entry should answer five questions:
What exactly could go wrong?
Which work packages would be affected?
How likely is it?
What would the impact be?
What will the consortium do if it happens?
The more specific the risk description, the more credible the mitigation strategy becomes.
For example, a risk such as "technical failure" is so broad that it provides little useful information. By contrast, a risk stating that sensor accuracy may fall below required thresholds under Mediterranean summer conditions immediately tells evaluators what the problem is, where it may occur, and why it matters.
Writing Effective Mitigation Measures
Mitigation measures should be practical, concrete, and directly linked to the risk.
Strong mitigation measures often include:
Backup methodologies
Alternative pilot sites
Additional data sources
Contingency resources
Decision points and review milestones
Alternative implementation pathways
A mitigation strategy should explain not only how the risk will be monitored, but also what action will be taken if the risk materialises.
Avoid Generic Risk Entries
One of the most common weaknesses in Horizon Europe proposals is the use of generic risks paired with generic mitigation measures.
Statements such as:
"Risk: Technical failure. Mitigation: The consortium will monitor progress closely and address issues as they arise."
provide little confidence that the consortium has genuinely considered the problem.
Evaluators want to see risks that are directly connected to the project and mitigation measures that demonstrate preparation and foresight.
A Better Way to Think About Risks
The strongest risk tables are built around critical project assumptions.
Ask yourself:
What must go right for this project to succeed?
What assumptions are we making?
What happens if those assumptions prove wrong?
The answers to these questions often reveal the most important risks in the proposal.
A Practical Rule
A risk table should not read like a generic project management template.
It should read like evidence that the consortium understands the project's specific challenges and has a realistic plan for dealing with them.
If the same risk table could be copied into ten different Horizon Europe proposals without modification, it is probably too generic to score highly.
Team Description and Resource Justification
The final major component of the Implementation section focuses on the project team and the resources requested to deliver the work.
These two elements are closely connected. A strong team description demonstrates that the consortium has the expertise required to deliver the project, while a strong resource justification demonstrates that sufficient effort and resources have been allocated to achieve the proposed objectives.
Evaluators assess both together. A budget request is only credible if the people requesting it have a clearly defined role and the expertise needed to perform the work.
Describing the Team
Many proposals make the mistake of writing generic partner descriptions that could be copied into almost any application.
Statements such as "Partner X is a leading institution with extensive experience in the field" tell evaluators very little about why that organisation is important to this specific project.
Instead, partner descriptions should answer three questions:
What expertise does the partner bring?
What role will they play in this project?
What evidence demonstrates they can deliver?
The strongest descriptions connect expertise directly to project responsibilities.
For example, rather than simply highlighting previous publications or project participation, explain which work packages the partner leads, which tasks they are responsible for, and how their previous experience supports those activities.
Evaluators should be able to understand not only who the partner is, but also why they are essential to the success of the project.
Avoid Generic Partner Descriptions
A common weakness is treating the consortium section as a collection of mini-biographies.
Evaluators are not primarily interested in a partner's entire institutional history. They want to understand how the partner contributes to the proposed work.
Strong partner descriptions are project-specific. They link expertise, previous achievements, and project responsibilities into a single coherent narrative.
Resource Justification
Resource justification explains why the requested budget and person-month allocation are necessary to deliver the planned activities.
Under the lump sum model, this justification is typically provided at work package level and should cover the major resource categories, including:
Personnel effort
Travel
Equipment
Subcontracting
Other direct costs where relevant
The objective is not simply to explain what the consortium wants to spend. It is to demonstrate why those resources are required to deliver the work.
Match Resources to Complexity
As a general rule, the work packages requiring the greatest effort should receive the largest share of resources.
If a technically demanding work package has a smaller budget than project management or communication activities, evaluators may question whether the budget allocation reflects the actual workload.
Resource allocation should be consistent with the scale, complexity, and importance of the activities being performed.
Justify Person Month Allocations
Person-month allocations should be linked directly to project activities.
Rather than simply stating that a partner requires a certain number of person-months, explain what work those person-months will support.
For example, effort allocated to field deployment, pilot monitoring, stakeholder engagement, software development, or data analysis should be clearly connected to the corresponding tasks and expected outputs.
The stronger the connection between effort and activities, the more credible the resource justification becomes.
Use Subcontracting Carefully
Subcontracting should be reserved for clearly defined activities that require expertise unavailable within the consortium.
Evaluators generally expect the core project work to be performed by consortium members. Large subcontracting budgets can therefore attract additional scrutiny, particularly if the rationale is unclear.
Whenever subcontracting is proposed, explain:
Why the activity cannot be performed internally
What expertise is being procured
How the subcontracted work contributes to project objectives
The justification should demonstrate necessity rather than convenience.
A Practical Rule
Every resource request should answer a simple question:
Why is this effort, cost, or resource necessary to deliver the work described?
If evaluators can clearly see the connection between resources, tasks, outputs, and objectives, the resource justification is likely to be convincing. If the budget appears disconnected from the work plan, questions about credibility will quickly follow.
The Implementation Section Coherence Check
Before finalising the Implementation section, run a full coherence check. This is the most important quality assurance step you can take — and it should be done by someone who did not write the section, reading it as an evaluator would.
The four coherence tests:
1. Objective traceability: can every objective from Section 1 be traced to at least one WP, at least one task within that WP, and at least one deliverable that evidences its achievement? Build a simple matrix if needed.
2. Timeline consistency: do the task start and end months in the narrative match the Gantt chart, which match the deliverable due dates, which reflect the actual logical sequence of dependencies?
3. Resource coherence: does the budget distribution across WPs reflect the actual weight of activities? Does the person-month allocation per partner reflect their actual role? Are there partners who contribute significantly in the narrative but minimally in the resource table — or vice versa?
4. DEC integration: do the dissemination, exploitation, and communication activities described in Section 2 (Impact) appear as tasks and deliverables in the DEC work package? If not, they are commitments without a delivery mechanism.
Checklist: final review of the Implementation section
□ Every objective from Section 1 maps to at least one WP
□ Every WP has a clearly defined objective, named lead, start/end date, and budget
□ Every task has a specific name, description, lead partner, and timeframe
□ Every deliverable has a specific title, type, dissemination level, and due date
□ Deliverables are outputs, not activities — their titles imply a product
□ Milestones are distinct from deliverables and have verifiable means of verification
□ The Gantt chart matches the task descriptions exactly (same task names, same months)
□ The risk table contains 5+ project-specific risks with realistic probability/impact ratings
□ Each risk has a concrete, project-specific mitigation strategy
□ The team descriptions justify each partner's role in specific WP terms
□ The resource justification explains person-months and budget at WP level
□ DEC activities from Section 2 are present as tasks in the DEC WP
□ All numbers are consistent across Part A tables, Part B narrative, and Gantt chart
Final Thoughts: Implementation Is the Architecture of Credibility
The Implementation section is where the credibility of a proposal is built or lost. Excellence can make an evaluator excited about your science. Impact can make them believe in its value. But only a coherent, specific, and well-reasoned Implementation section makes them believe your consortium can actually deliver it.
The work of building a strong Implementation section is the work of designing the project itself — not just describing it. The most common reason for weak Implementation sections is that the work plan was assembled at the end of the proposal process, around a scientific case that had already been written, rather than being designed from the start as the architecture that the science will be executed within.
Build the implementation logic first — the WP structure, the task flow, the deliverable schedule, the resource allocation. Then write the Excellence and Impact sections as arguments for why this specific plan, executed by this specific team, will produce the specific results the programme is looking for. That is how the strongest Horizon Europe proposals are built.
At SublimeHub, work plan design and Implementation section writing is a core part of our proposal development service. If you are structuring a work plan and want expert support — from WP architecture to deliverable definition to final coherence review — we would be glad to help.
Need support writing your Implementation section?
SublimeHub designs work plans, WP structures, and deliverable frameworks for Horizon Europe proposals — building the implementation logic that evaluators trust and projects can actually deliver.
