Work Packages in Horizon Europe: WPs, Deliverables and Milestones

Preliminary 2025 data from Science|Business puts the overall Horizon Europe success rate at around 12%. One in eight proposals gets funded; the rest comes back with reviewer comments. Read through enough Evaluation Summary Reports and a pattern emerges: a weak Implementation Section, and specifically, poorly constructed Work Packages.

There’s a second dimension that receives less attention. Once the European Commission signs the Grant Agreement, the same WP table you built for reviewers becomes Annex 1, a legally binding document. Your WPs, Tasks, Deliverables, and Milestones turn into contractual obligations. So if you over-estimated Person-Months or described unrealistic tasks, the problems don’t start at rejection. They start at implementation.

This article covers the practical anatomy of WP structure for RIA and IA projects: from the hierarchy of elements to distributing Person-Months across partners without inflating the budget.

How a Work Package works: the hierarchy from task to milestone

A Work Package is an autonomous unit of work with its own objective, budget, and timeline. Each WP breaks down into Tasks: the actual activities partners carry out. Those Tasks produce Deliverables and Milestones.

A Deliverable is a document or artefact submitted to the EC or Agency. Specifically, the official Horizon Europe annotated application template (RIA/IA, version 5.0, April 2025) defines it as “a report sent to the Commission or Agency to ensure effective monitoring of the project.” Even if your deliverable is a prototype or dataset, you will still submit a written report describing its characteristics and the process behind it.

A Milestone is a control point. The official definition: “control points in the project that help to chart progress.” A milestone can correspond to a key result or a critical decision, for example selecting the technology platform for further development. The key requirement is that a milestone must be verifiable.

The structural difference matters in practice. A Deliverable is always tied to a specific WP and ideally to a specific Task. A Milestone can span several WPs at once, which works well as a cross-package checkpoint where parallel workstreams converge.

WP structure serves two purposes. During evaluation, reviewers assess its logic, feasibility, and budget justification. After the Grant Agreement is signed, the WP becomes part of the Description of Action (DoA), Annex 1 to the contract. In Lump Sum projects, this goes further: completing a WP is the sole trigger for the EC to release its fixed payment share.

Standard WP architecture for RIA and IA: what reviewers expect to see

A typical RIA or IA project has 6-8 WPs. The official annotated Horizon Europe template (version 5.0) says it directly: “a typical project has 6-8 WPs that are balanced in size (budget and person-months).”

WP structure should reflect the project concept and idea already defined before writing the proposal. If the concept is unclear, no well-structured WP table will fix it.

The standard layout: WP1 Management (administrative, financial, and contractual oversight, led by the coordinator), WP2 through WPx for core technical work, and a final WP covering Dissemination, Exploitation, and Communication.

Two things reviewers pick up on immediately. First: no single partner should run an entire WP without others contributing. That pattern signals weak collaboration: one of the fastest ways to lose points on the Implementation criterion. Second: don’t list all partners in all WPs without clear role differentiation. When the full consortium appears everywhere equally, the structure looks artificial. The exception is horizontal WPs like Dissemination, where broad participation is logically justified.

The most effective way to show real collaboration is to map the workflow. For example: Task 3.2 in WP2 (Partner B collects experimental data) feeds directly into Task 1.1 in WP4, where Partners A and C run the analysis. That interdependency shows reviewers an actual working structure, not just a list of participants in a table.

Each WP needs a named leader. That leader’s role goes beyond their own contribution. They also coordinate and integrate results from all partners in the package. Both the WP description and the Person-Month allocation should reflect this.

WP titles matter too. “Research Activities” is a weak title. “Development and validation of the ML-based diagnostic module for clinical trial data” is specific and tells a reviewer exactly what to expect. Reviewers read WP titles before they read descriptions.

Deliverables and milestones: the right numbers and common mistakes

The core principle: enough deliverables and milestones to convince reviewers the project is serious, but not so many that the team drowns in reporting during implementation.

For deliverables: at least one per Task, with 2-3 per WP as the recommended range. If a Task runs longer than 18 months, add an interim deliverable. Each deliverable title should describe the actual output, not the activity. “D2.1: Technical specifications for the data collection protocol (M12)” tells a reviewer exactly what to expect at month 12. “Report on activities” tells them nothing.

For milestones: around 5 for a 3-year project, adding 1-2 for longer projects. Because milestones need to be verifiable, write them as concrete achievements, not “progressing towards,” but “Decision on technology platform confirmed at PMC meeting (M18).”

Timing matters. Don’t schedule deliverables in August: nobody writes reports on holiday. Also avoid placing them in the two months before and during a reporting period. If a deliverable is late, that buffer gives the team time to fix it before the report goes to the EC.

The classic mistake is treating quantity as quality. A long deliverable list looks ambitious on paper. In practice it signals poor planning and creates an administrative burden that reviewers recognise. Two or three well-defined deliverables per WP satisfy reviewers and leave the team with time for actual research.

One more thing worth remembering: after the Grant Agreement is signed, both deliverables and milestones become contractual obligations. So realistic planning here carries real financial and operational consequences.

Person-Months: how to calculate without budget creep

What 1 PM means and how to calculate it

1 Person-Month is the effort of one full-time employee over one month, or two employees at 50% each. That sounds simple, but misinterpreting this is one of the most common errors in Horizon Europe proposals.

In Horizon Europe, personnel costs use a daily rate: annual personnel costs ÷ 215 working days = daily rate. That rate then multiplies by the number of days worked on the project. The most practical way to manage this calculation is to add a PM column to the GANTT chart for each partner and each WP. That gives a full picture of personnel effort and prevents the common situation where one researcher appears across four WPs at a combined 120%.

Typical allocation mistakes

The classic unrealistic allocation: 50 PMs for Project Management in a 2-year project. The arithmetic is straightforward: that’s 2 full-time staff dedicated solely to administration for 24 months. Reviewers see this immediately as an inflated budget.

A second weak approach is top-down allocation: take the total budget and divide it equally among partners. Reviewers read this as under-developed planning. The bottom-up approach, where each partner estimates actual effort for their specific tasks, and those figures get consolidated, produces a more accurate picture and reads far more convincingly.

The Horizon dashboard and unwritten rules

For Lump Sum calls, evaluators use the Horizon dashboard, a benchmarking tool for personnel costs. It shows the cost distribution from the 20th to the 80th percentile, broken down by country and organisation type. Costs above the 80th percentile need additional justification. Checking your figures against the dashboard before submission is worth building into the proposal preparation process.

Beyond the official rules, experienced proposal teams follow practical guidelines. Avoid concentrating more than 40% of the total budget on partners from a single country: that signals an unbalanced consortium. Subcontracting works best below 15-20% of the total budget, and core project tasks cannot be subcontracted. Purchase costs exceeding 15% of a partner’s personnel costs require detailed documentation in Table 3.1h.

One more detail that often gets missed: all partners should be responsible for at least one deliverable and contribute to others. An uneven deliverable distribution is a direct indicator of unbalanced effort, and reviewers notice it.

Lump sum in 2026-2027: why WP structure matters even more now

By 2026-2027, half of the Horizon Europe budget moves to the Lump Sum model. The logic is direct: the EC pays not for actual costs but for confirmed WP completion. Each WP gets a fixed share in the Grant Agreement, released after the consortium demonstrates that WP has been fully carried out. No invoices, no timesheets. Each WP must be completed in full.

According to a 2024 EC evaluation, the model cuts administrative costs by 14-30% and already saved over €60 million across early pilot projects. EU Research Commissioner Ekaterina Zaharieva described Lump Sum as “simpler and more accessible” for newcomers to Horizon Europe (Science|Business, February 2026). The European Court of Auditors added a note of caution: the intention to simplify EU financial management should not come at the expense of accountability and effectiveness.

In practice, this creates a new risk profile. Vague task formulations that might have passed under a cost-based model now become a problem. If you cannot demonstrate WP completion, the EC may not release the payment, regardless of the actual work done.

The practical rule for Lump Sum calls: structure each WP so that its completion can be unambiguously verified. Every deliverable, milestone, and Task description should name a specific, concrete output, not a process. “Conducted research” is not a WP output. “Published report D3.1 with field trial results” is.

WP structure has always been both an argument for reviewers and a plan for the team. Now it is also a direct financial trigger. That is reason enough to spend an extra day on it during proposal preparation. Fixing it after signature is a much harder conversation.