How to Design Effective Work Packages in Horizon Europe
How to structure work packages that are coherent to evaluate, deliverable to manage, and credible enough to win — and survive — a Horizon Europe project
Work packages are the architecture of a Horizon Europe project. Everything else — tasks, deliverables, milestones, budget, team roles, risk management, reporting — is built on top of the WP structure. Get the architecture right, and the rest of the proposal and the project flows from it. Get it wrong, and every subsequent element will be fighting against a structural problem that cannot be patched later.
This post goes deeper into WP design than most guidance does. It is not a general introduction to what work packages are — Post #5 in this series covers the basics of the Implementation section. This post is specifically about the design decisions that distinguish work packages that work from those that look fine on paper but create management problems once the project starts.
Those problems — WPs that cannot be delivered as defined, deliverables that do not reflect the actual outputs of the work, budget allocations that leave WPs underfunded for what they are asked to produce — are almost always visible in the proposal if you know where to look. This post shows you how to see them, and how to design WPs that avoid them.
The WP as a Contract with Yourself
Under Horizon Europe's lump sum model, the work package is a contract in a very direct sense: the Commission agrees to pay a fixed amount for a WP when that WP is delivered. The WP description in your proposal defines what 'delivered' means. If the deliverables are vague or the scope is unclear, that ambiguity will create problems during Grant Agreement negotiation and during implementation.
But even under the older cost-based model, a WP that is poorly defined is a liability. Poorly scoped WPs are harder to report on, create disagreements between partners about who is responsible for what, and make it difficult to demonstrate to project officers that the project is on track.
Key point
The fundamental test of a well-designed WP: if a new project manager joined the consortium in Month 6 and read only the WP description, would they know exactly what the WP is trying to achieve, which tasks they need to manage, which partners they need to coordinate with, and which deliverables they need to produce and when? If yes, the WP is well designed. If not, keep refining.
Six Design Principles for Effective Work Packages
Well-designed work packages share a number of common characteristics. Although every project is different, the strongest work packages are built around the same six design principles. If one of these principles is missing, it often creates problems elsewhere in the proposal—from unrealistic budgets to vague deliverables or difficult project management.
1. One Coherent Goal
Every work package should have a single, clearly defined objective that can be expressed in one sentence. All tasks within the work package should contribute directly to achieving that objective.
Test yourself: Can you explain what this work package achieves in one sentence? If it takes two or three sentences, it may be trying to do too much.
2. Verifiable Completion
A work package should have a clear finish line. Completion should be demonstrated through specific deliverables and milestones that allow the Project Officer to determine objectively whether the work has been completed.
Test yourself: If you were the Project Officer, could you confidently decide whether this work package was complete? If the answer depends on interpretation, your deliverables probably need to be more precise.
3. Managed from Within
A work package leader should be able to manage and deliver the work package without constantly waiting for outputs from other work packages. Some dependencies are inevitable, but they should be limited and carefully planned.
Test yourself: Does this work package depend on another work package finishing before meaningful work can begin? If so, the dependency should be identified and managed as a project risk.
4. A Proportionate Budget
The budget should reflect the actual effort required to complete the planned activities. Work packages that appear significantly over- or under-resourced are likely to raise questions during evaluation.
Test yourself: If the budget were reduced by 25%, could you still deliver everything promised? If the answer is yes, the budget may be too generous. If the answer is clearly no, the allocation is probably realistic.
5. Clear Partner Roles
Every partner should have a clearly defined responsibility within the work package. Avoid listing organisations as general contributors without specifying exactly what they will do.
Test yourself: For every partner involved, can you identify the task they are responsible for and the contribution they will make? If not, their role needs to be better defined.
6. A Realistic Timeline
Tasks should follow a logical sequence that reflects how the work will actually be carried out. Activities should not begin before the information or outputs they depend on are available.
Test yourself: Does the task sequence shown in the Gantt chart reflect the real workflow? If not, revisit the timeline before submission.
Key Takeaway
Strong work packages are focused, measurable, realistic, and internally coherent. If each work package satisfies these six principles, your overall implementation plan will be far easier for evaluators to understand—and far more likely to convince them that the project can be successfully delivered.
The Four Common WP Design Failures
Most WP design problems fall into four recognisable patterns. Understanding them makes it easy to identify and correct them before submission.
Failure 1: The Umbrella WP
The umbrella WP is one that contains everything that did not fit neatly elsewhere. It typically has a broad title ('Cross-cutting activities' or 'Integration and coordination of research') and a wide scope that mixes themes, partners, and activities that would be better separated into distinct WPs.
The signal is a WP objective that requires two or three sentences to state, or a WP that contributes to every other WP in the project without having a coherent independent goal of its own.
✗ Umbrella WP (too broad)
WP4 — Integration, Communication and Validation Activities: This WP covers the integration of research findings from WP2 and WP3, the communication and dissemination of project results, stakeholder engagement activities, the organisation of project events, the validation of results in real-world conditions, and the preparation of policy briefs.
✓ Focused WP (coherent scope)
WP4 — Real-World Validation and Pilot Assessment: This WP deploys the validated sensor system from WP3 at 12 pilot farms across three climatic zones, collects 18 months of operational data, and produces the field validation evidence required for the commercial deployment and policy adoption claims in the project's exploitation plan.
Failure 2: The Partner WP
The partner WP is one that is defined around a partner rather than around a project objective. Instead of designing the WP around what needs to be achieved and then assigning the right partner to lead it, the WP is created to give a specific partner something to lead — and the objective is fitted around the partner's capabilities.
The signal is a WP title that matches a partner's institutional identity more than a project need: 'WP3 — Policy and Regulatory Analysis (Lead: Policy Institute X)'. The problem is not that Policy Institute X is not needed — it probably is. The problem is that when the WP is defined around the partner rather than the work, the scope tends to expand to fill whatever the partner is good at, rather than focusing on what the project actually needs.
Design WPs around project needs first. Then assign the partner best suited to lead each one. Not the other way around.
Failure #3: The Sequential Bottleneck
A sequential bottleneck occurs when the structure of the work plan creates a critical dependency that has not been properly considered.
For example, WP3 may depend on a key output from WP2, yet WP3 is scheduled to begin months before that output will be available. Alternatively, a pilot work package may require two years of continuous data collection but is expected to deliver its main results immediately afterwards, leaving no contingency if anything slips.
Sequential dependencies are not a problem in themselves. Most Horizon Europe projects have them.
The problem arises when those dependencies are not acknowledged, planned for, or reflected in the project timeline and risk analysis.
Hard Sequential Dependencies
Some work packages genuinely cannot begin until another work package has produced a specific output.
If this is the case, make the dependency explicit in both work package descriptions, include it in the risk table, and build a small buffer between the completion of the first work package and the start of the second.
Soft Sequential Dependencies
Other work packages can begin in parallel but rely on outputs from another work package before they can complete their core activities.
In these cases, explain the overlap clearly and ensure the Gantt chart reflects both the parallel work and the later dependency.
Resource Bottlenecks
Dependencies are not always technical.
Sometimes the same partner—or even the same individual—is expected to contribute heavily to several work packages at the same time.
Review your person-month allocations carefully to ensure the planned workload is realistic.
External Dependencies
Some activities depend on factors outside the consortium's control, such as ethics approvals, regulatory decisions, access to pilot sites, or external datasets.
These should be treated as project risks, with appropriate mitigation measures and contingency plans where possible.
Key Takeaway
Dependencies are a normal part of complex collaborative projects.
The important thing is to identify them early, reflect them accurately in the work plan, and demonstrate that the consortium has realistic plans for managing them if delays occur.
Failure 4: The Deliverable Vacuum
The deliverable vacuum is a WP that runs for 24 or 36 months with only one deliverable, due at the end. From an evaluation perspective, this means there is no intermediate evidence of progress for the majority of the project duration. From a management perspective, it means the WP leader has no formal accountability point until it is potentially too late to course-correct.
Every WP that runs for more than 12 months should have at least one intermediate deliverable — a report, a dataset, a software release — that marks the completion of a significant phase of work. This is not bureaucratic overhead. It is the mechanism by which the consortium and the Commission can verify that the WP is on track.
How to Design the WP Structure: Starting from Objectives
The most reliable way to design a coherent WP structure is to start from the project's objectives and work backwards to the activities required to achieve them, rather than starting from the available partners and trying to define WPs around their capabilities.
Step 1: List the project's objectives
Take the numbered list of objectives from your Excellence section. Each objective represents a specific outcome that the project will achieve. These become the anchor points for your WP structure.
Step 2: Group objectives into coherent streams
Look for natural groupings among the objectives — streams of work that share a methodology, a partner, a set of activities, or a phase of the project lifecycle. These groupings become the candidates for your technical WPs. A good grouping is one where all the objectives in the group can be pursued by largely the same team, using largely the same methods, producing related outputs.
Step 3: Add the mandatory structural WPs
Almost every Horizon Europe collaborative project requires three structural WPs in addition to the technical ones:
A project coordination and management WP (WP1): covering governance, reporting, quality assurance, financial management, and communication with the Commission. Led by the coordinator.
A DEC WP (last WP): covering all dissemination, exploitation, and communication activities. Led by the coordinator or a designated communication partner.
Optionally, a pilots and demonstrators WP: covering the real-world testing and validation of results from the technical WPs. Particularly important in Innovation Actions where the demonstration of market-ready results is a core project objective.
Step 4: Check the coverage and gaps
Once you have a draft WP structure, run a coverage check: for each objective, identify which WP addresses it. Every objective should have at least one WP. If an objective is not covered, either add it to an existing WP or create a new one. If an objective is covered by three different WPs, consider whether the objective is too broad or the WP structure is too fragmented.
Step 5: Assign leaders and contributors
For each WP, identify the partner best suited to lead it based on their expertise, their capacity, and their centrality to the WP's objective. Then identify the contributing partners whose specific expertise is needed for individual tasks within the WP. A WP leader should be genuinely engaged with the WP's scientific or technical substance — not merely administratively responsible for it.
Writing the Work Package Description
The work package description is one of the most important parts of your proposal.
It is used by evaluators to assess the credibility of your implementation plan, by the European Commission during Grant Agreement preparation, by Project Officers during implementation, and by your own consortium as the project progresses.
A good work package description should therefore be clear, specific, and easy to follow.
Every Work Package Should Include
Although the exact format varies slightly between calls, every work package should clearly describe:
The work package number, title, lead partner, duration, and budget.
A concise objective explaining what the work package will achieve.
The partners involved and their specific responsibilities.
A breakdown of the tasks, including who leads them, when they take place, and what they produce.
The deliverables that will be submitted to the Commission.
Any milestones used to monitor progress and verify successful completion.
Together, these elements provide a complete picture of what the work package will deliver and how it will be managed.
A Typical Work Package
A typical technical work package might include:
Objective: Validate an integrated sensor system under real field conditions across three European climatic zones.
Tasks: Prepare pilot sites, collect field data, validate the results, and assess usability with end users.
Deliverables: A pilot deployment report, a validated dataset, and a documented calibration protocol.
Milestone: Confirmation that all pilot sites are operational and collecting data.
Notice how every activity contributes directly to the work package objective and produces a tangible output.
Practical Tip
Avoid writing vague task descriptions such as "explore", "investigate" or "support project activities."
Instead, make every task answer three simple questions:
Who will perform the work?
What will be produced?
When will it be completed?
The more clearly you answer these questions, the easier it is for evaluators—and later your own project team—to understand exactly how the work package will be delivered.
Work Package Budget Design: Making the Numbers Work
Under the lump sum model, each work package is assigned a fixed budget that is agreed before the Grant Agreement is signed. Getting that budget right is essential—not only for convincing evaluators, but also for ensuring the project remains financially sustainable during implementation.
Build the Budget from the Bottom Up
The most reliable approach is to estimate the resources required for each task and then combine them into a single work package budget.
Although this detailed calculation is not submitted with the proposal, it should always be prepared internally. It provides the evidence needed during Grant Agreement negotiations and helps the consortium manage the project once it begins.
Estimate Each Resource Category
A robust work package budget should consider:
Personnel: Estimate the person-months required for each partner using their actual institutional cost rates.
Travel and fieldwork: Calculate consortium meetings, site visits, workshops, conferences, and other planned travel using realistic assumptions.
Equipment and consumables: Identify the specific items required rather than using generic categories such as "equipment."
Subcontracting: Clearly define which activities will be outsourced and estimate costs using realistic market prices.
Indirect costs: Apply each organisation's approved overhead rate rather than assuming the same rate across the consortium.
The more transparent your internal calculations are, the easier it will be to justify the work package budget if questions arise.
Avoid Common Budgeting Mistakes
Many budget problems originate from overly simplified assumptions.
Examples include:
Using the same monthly personnel rate for every partner.
Underestimating travel for projects with multiple pilot sites.
Including vague equipment costs without identifying what will actually be purchased.
Allocating excessive subcontracting without a clear justification.
Applying identical overhead rates across all organisations.
These issues may not prevent funding, but they often generate questions during evaluation or Grant Agreement preparation.
Balance the Budget Across Work Packages
The way your budget is distributed also sends a message to evaluators.
The largest share of the budget should normally support the project's core scientific or technical work. Work packages involving extensive piloting or validation also require substantial resources, while coordination and dissemination activities should be appropriately funded without dominating the budget.
There is no universal formula, but the overall budget allocation should reflect the real priorities of the project. If the proposal claims that large-scale pilot validation is central to its success, the budget should clearly support that ambition.
Practical Tip
When you have finished preparing the budget, compare the resources allocated to each work package with the activities described in the work plan.
Ask yourself:
"If I only looked at the budget, would I identify the same priorities that the proposal describes?"
If the answer is no, revisit the allocation before submission. Evaluators often notice these inconsistencies immediately.
WP Design for the Lump Sum Model: Special Considerations
The lump sum model — now standard for most Horizon Europe RIA and IA calls — creates specific requirements for WP design that did not apply under the older cost-based model. These are not just administrative differences. They change what makes a good WP design.
WP boundaries must be financially clean
Under the lump sum model, you cannot reallocate budget between WPs without a formal Grant Agreement amendment. This means that WP boundaries need to be genuinely clean — activities that could reasonably belong to either of two adjacent WPs should be firmly assigned to one, and the budget should reflect that assignment.
A common problem is designing two WPs that share a research team, where the team's time is split between both WPs. If the team ends up spending more time on WP3 than planned and less on WP2, the consortium has effectively reallocated budget between WPs — which under lump sum rules requires an amendment. Minimise cross-WP allocation of the same personnel where possible.
Deliverables must be genuinely verifiable
Under lump sum, deliverables are the primary mechanism through which WP completion is verified. A deliverable that cannot be objectively assessed as complete or incomplete is a problem. 'Report on project activities during Month 1–18' is not a verifiable deliverable — it can always be submitted regardless of whether the underlying activities were completed.
A verifiable deliverable has a specific scope that can be checked: a protocol that either covers the defined use cases or does not; a dataset that either meets the FAIR criteria and the specified size or does not; a software release that either passes the defined acceptance tests or does not. Build the verifiability criteria into the deliverable descriptions.
WPs must be independently completable
Under lump sum, payment for a WP is conditional on delivery of that WP. If WP3 cannot be completed because WP2 was delayed, you may receive no payment for WP3 even though the reason for non-delivery was outside WP3's control. This makes the management of cross-WP dependencies more consequential than under the cost-based model.
Where possible, design WPs to be independently completable — able to deliver their core outputs even if inputs from other WPs are delayed. Where hard dependencies cannot be avoided, flag them explicitly in the risk table with specific mitigation plans.
The WP Design Quality Checklist
For each work package in your proposal, confirm:
□ The WP objective can be stated in one sentence
□ All tasks within the WP serve the WP objective
□ The WP completion criteria are unambiguous — a project officer could confirm completion without judgment calls
□ Every contributing partner has at least one named task and one named deliverable
□ The task sequence in the Gantt chart reflects actual logical dependencies
□ There is at least one deliverable every 12–18 months for WPs running longer than 12 months
□ All deliverables are specific, tangible outputs — not activity reports
□ The WP budget is justified by the activities and resources described
□ The budget allocation reflects the WP's actual importance in the project
□ Cross-WP dependencies are explicitly acknowledged and risk-mitigated
□ The WP can be delivered independently if an adjacent WP is delayed
For the overall WP structure, confirm:
□ Every project objective from Section 1 maps to at least one WP
□ Every WP has a distinct, non-overlapping scope
□ The number of WPs is appropriate for the project scale (not too few, not too many)
□ The budget distribution across WPs reflects the project's stated priorities
□ The DEC WP covers all activities described in the Impact section
□ The management WP is realistically resourced for the coordination burden of this consortium size
□ A new project manager reading only the WP descriptions could manage each WP
Final Thoughts: Work Packages Are the Project
In Horizon Europe, the work plan is not a description of the project. It is the project. The objectives, the outputs, the timeline, the responsibilities, the budget, the risk management — all of it lives inside the work package structure. A proposal with outstanding Excellence and Impact sections but a poorly designed work plan is a proposal that should not be funded, and evaluators with experience know why.
The investment required to design a genuinely good WP structure — clear objectives, specific tasks, verifiable deliverables, realistic budgets, acknowledged dependencies — is significant. It requires the whole consortium to engage, not just the proposal writer. It requires the scientific leadership to translate their research plan into a manageable structure. It requires the project manager to think through what implementation will actually look like in Month 18, not just Month 1.
That investment pays dividends twice: in a higher evaluation score, and in a project that is significantly easier to manage when the funding arrives.
At SublimeHub, WP architecture design is one of our most requested services — both at proposal stage and for funded projects that need to restructure their work plan after the Grant Agreement. If you want expert support on WP design, we would be glad to help.
Need support designing your work plan and WP structure?
SublimeHub designs work package architectures, task flows, and deliverable frameworks for Horizon Europe proposals and active projects — building the implementation logic that evaluators trust and project teams can actually manage.
