Work packages in Horizon Europe: how to structure and manage them 

Table of Contents

Ask any experienced Horizon Europe coordinator what determines whether a project is manageable or chaotic, and most will give the same answer: the quality of the work package structure.

Work packages are the operational skeleton of every Horizon Europe project. They organise the work, define responsibilities, anchor the budget, and provide the framework against which progress is reported. A well-designed work package structure makes execution traceable and reporting straightforward. A poorly designed one creates confusion from month one and evidence problems that compound over the entire project lifetime.

This article explains what work packages are, how they are structured, what goes wrong when they are not designed carefully, and what managing them looks like in practice across a multi-partner consortium.

What a work package is

A work package (WP) is a defined grouping of related tasks that together contribute to a specific objective within the overall project. Each WP has a title, a lead organisation, a set of participating partners, a budget, a timeline, a list of tasks, and a set of outputs — deliverables and milestones — that mark its progress.

Work packages are defined in Annex 1 of the Grant Agreement and are legally binding. The consortium commits to delivering the outputs of each WP by the dates specified. Changes to WP scope, lead partner, or key outputs require either formal notification to the Project Officer or, in more significant cases, a formal GA amendment.

Standard types of work packages

Most Horizon Europe projects include a combination of the following WP types, although the specific structure always depends on the project’s scope and work plan.

Research and innovation WPs

These contain the core scientific or technical work of the project. Their number, scope, and titles vary entirely depending on the project — there is no standard template. These WPs are typically the most resource-intensive and carry the highest delivery risk, and their names depend on the project’s activities.

Communication and dissemination WP

Required in nearly all Horizon Europe projects. Covers both the communication of the project to external audiences and the dissemination of results to the wider research and innovation community, as well as the planning for how results will be used, commercialised, or transferred. Often underestimated in terms of effort and compliance requirements.

Coordination and support WP

Covers the administrative and operational management of the entire consortium. Typically led by the coordinator. Includes reporting preparation, Steering Committee meetings, risk management, and internal governance activities. Coordinators frequently underbudget this WP — the administrative burden of running a multi-partner project over several years is significant.

What a work package contains

Each WP is composed of several structured elements:

Tasks

Tasks are the individual activities that together constitute the WP’s scope. Each task should have a clear description of what is being done, a named lead partner, named contributing partners, a timeline, and a clear link to the WP’s objectives.

Tasks are the level at which daily work actually happens, but they are not individually reported to the Commission. They exist to structure execution internally and to justify the assignment of effort and budget.

Deliverables

Deliverables are formal outputs that must be submitted to the Commission by a specified date. They can take many forms: reports, datasets, software, prototypes, publications, or any other tangible output defined in the GA.

Each deliverable has a unique reference number (e.g. D2.1), a title and description, a responsible lead partner, a due date, a dissemination level, and a type.

Late or incomplete deliverables trigger questions from the Project Officer. Missing deliverables — particularly in lump sum projects — can directly affect payment.

Milestones

Milestones mark significant points in the project’s progress — the completion of a phase, the achievement of a decision point, or the readiness of something for the next stage. Unlike deliverables, milestones do not require the submission of a document. They are verified through the technical report and sometimes through supporting evidence.

In practice, milestone management is often more loosely tracked than deliverable management. This is a mistake. Missed milestones are red flags in project reviews and can trigger increased scrutiny.

Common mistakes in work package design

Vague task descriptions. Tasks described as “coordination activities” or “technical work in WP3” without specificity create ambiguity about who is responsible for what. During a project review or audit, vague tasks cannot be evidenced.

Misaligned budgets. Assigning budget to a partner in a WP where their actual contribution is minimal — or failing to budget adequately for the real work — creates both financial reporting problems and partner motivation issues.

No clear completion criteria. This is particularly critical in lump sum projects. If the description of a task or deliverable does not make clear what constitutes successful completion, the consortium may find itself unable to demonstrate that the WP has been completed, regardless of the actual work done.

Underbudgeting the coordination WP. The administrative burden of running a multi-partner project over three to five years is significant. Underestimating it creates resourcing pressure from the beginning and leaves the coordinator without the capacity to manage the project properly.

Ignoring WP interdependencies. Many WPs have dependencies: WP3 cannot start until WP2 delivers a specific output. These dependencies need to be explicitly mapped and actively monitored. Untracked dependencies become surprises.

Managing work packages during execution

Designing work packages well is necessary but not sufficient. The management challenge is sustained over the full project lifetime.

Tracking progress across partners. In a consortium of 10 or 15 partners, each WP leader must actively collect progress updates from contributing partners, assess whether tasks are on track, and escalate delays to the coordinator before they affect deliverables.

Maintaining evidence. Every deliverable must be evidenced. In lump sum projects, task completion must be documented even when no formal deliverable is due. This means maintaining records continuously throughout the project, not at reporting time.

Managing changes. Scope creep, partner capacity issues, unexpected technical obstacles — these are normal in complex R&D projects. The critical question is not whether things change, but whether changes are formally managed within the WP structure or informally absorbed in ways that create documentation gaps.

Reporting accurately. The technical report submitted at each reporting period must accurately reflect what has been done in each WP. Inaccurate or vague reporting is a frequent cause of additional requests from Project Officers and can escalate into formal project reviews.

How Kronis PMO structures work package management

Kronis PMO is built around the work package structure of the Grant Agreement. It translates Annex 1 into an operational management layer — assigning tasks to partners, tracking deliverable status, monitoring milestone progress, and maintaining the evidence trail that reporting and audits require.

For WP leaders managing contributions from multiple partners, Kronis PMO provides visibility across all tasks and outputs in their WP in real time, without relying on email chains and shared spreadsheets. For coordinators managing the full project, it provides a consolidated view of progress across all WPs and flags risks before they become problems.

In lump sum projects particularly, where completion evidence is directly linked to payment, having a structured system for tracking and documenting WP progress is not a nice-to-have. It is the difference between a smooth reporting period and a payment dispute.

Final thoughts

Work packages are where the Grant Agreement meets reality. They are the structure through which a project either delivers on its commitments or falls short of them — and the quality of that structure is largely determined in the first weeks of the project, before execution begins.

Getting WP design right takes time. Defining tasks precisely, setting realistic timelines, mapping dependencies, and agreeing on completion criteria across a large consortium is not a quick process. But it is significantly less costly than managing the consequences of a weak structure over a three-to-five year project lifetime.

Kronis Software: The Solution to Navigating EU Funding Complexities

Scroll to Top