How to Structure Work Packages for EU Proposals
A work package can look complete because it has a title, a leader, several tasks and a neat Gantt chart. That is not the test an evaluator applies. When assessing how to structure work packages, the question is whether the implementation logic makes the promised results credible: can this consortium deliver the work, in this order, with these resources, while managing the risks it has created?
For Horizon Europe, Digital Europe and Erasmus+ proposals, work packages sit mainly within Implementation. But they also carry evidence for Excellence, Impact, consortium capacity and value for money. A weak work package structure therefore costs more than a point under one criterion. It can make a methodology appear generic, an impact pathway speculative, or a consortium assembled around partner names rather than necessary capability.
You only get one chance to submit. Before the final version is locked, treat the work plan as an evaluator would: not as a calendar of activity, but as a testable chain from inputs to outputs and outcomes.
Start with the call, not the standard template
A standard set of work packages - management, technical development, pilots, dissemination and exploitation - is often a convenient starting point. It is not a design rationale. In some calls, that familiar sequence fits the expected intervention logic. In others, it conceals the actual critical path and leaves the proposal with broad activities but no credible route to the required results.
Read the destination, scope, expected outcomes and expected impacts together. Then identify what the project must produce before its claimed outcome can reasonably occur. A Digital Europe deployment action may require a staged route through requirements, technical integration, validation, operational uptake and scale-up. A Horizon Europe research and innovation action may require research questions, method development, demonstration and replication. An Erasmus+ cooperation partnership may depend on co-design, piloting, validation with users and transfer into participating organisations.
The evaluation form matters too. Award criteria, sub-criteria, weightings and thresholds vary by programme and action type. Do not import an Implementation narrative from another proposal without checking the published form for the current call. A work plan that is technically sound may still fail to answer the sub-criterion being marked.
Admissibility and eligibility are separate questions. Page limits, required annexes, participant eligibility and call conditions can remove a proposal before award criteria are scored. A well-structured work plan does not repair a formal defect.
Build the work package architecture from dependencies
The practical method is to begin with results, then work backwards. For each expected outcome, ask what output must exist immediately before it, what activity creates that output, and what input or decision permits the activity to begin. This exposes dependencies that a flat task list hides.
A credible architecture usually separates work that has materially different purposes. Management should govern delivery rather than absorb substantive research or technical work. Ethics, data management, standardisation and communication may be horizontal functions, but they still require defined outputs, timing and ownership. Piloting should not begin before the component being piloted has passed a stated readiness or quality gate.
Do not split work packages merely to give each major partner a leadership role. Evaluators can see when the organisational chart has dictated the methodology. One partner may lead more than one package if that reflects genuine responsibility. Conversely, a partner with a small budget may be indispensable to a narrowly defined task because it supplies a facility, user group, dataset or regulatory expertise that no other beneficiary has.
The key test is whether each package has a distinct purpose and a clear handover. If two packages could be merged without changing dependencies, governance or outputs, they probably should be. Too many small packages create coordination overhead and make the Gantt chart unreadable. Too few create oversized blocks in which delays and accountability disappear.
How to structure work packages that can be scored
Each work package should answer six questions in language that can be checked against the rest of the proposal: what is being achieved, why it is necessary, who does what, when the work occurs, what it produces, and what could prevent delivery.
Define an objective that describes a result
“Developing an innovative platform” describes activity, not an objective. “Delivering a validated platform specification and demonstrator that meets the agreed user and interoperability requirements” gives the evaluator something to assess.
The objective should connect to the proposal’s methodology and impact pathway. If the project claims a policy, market, scientific or societal effect, the work package needs to show its contribution to the intermediate result on that path. Do not claim impact in a work package solely because it includes dissemination activity.
Make tasks specific enough to reveal the method
Tasks are where generic implementation claims become visible. A task called “data collection and analysis” tells an evaluator very little. State the population or source, approach, responsible participants, decision point and output. The proposal need not reproduce an operating manual, but it must provide enough detail for the method, feasibility and resource assumptions to be judged.
Tasks should be sequenced rather than merely numbered. Explain which task starts only after another has delivered an input, and where parallel work is deliberate. If WP3 depends on a prototype from WP2, the timeline, deliverable dates and risk register must agree. Contradictions between these sections are a common source of evaluator doubt.
Distinguish deliverables from milestones
A deliverable is a tangible item submitted or produced at a stated point: a report, protocol, software release, dataset, training package or validated model. It should have a useful title, a realistic due month and a clear connection to one or more tasks.
A milestone is a decision or control point. “Pilot completed” is often too vague. “Pilot sites approved to proceed after demonstrating 90% completion of the agreed interoperability tests” is a meaningful milestone because it establishes a condition for the next stage.
Do not create milestones from routine meetings or label every output a deliverable. Excessive administration can signal that the consortium has not identified the real technical or operational gates. Equally, a proposal with no credible milestones offers little evidence that it can detect failure early enough to respond.
Match person-months to the work described
Resource allocation is an evaluator’s consistency check. A large technical task assigned to one person-month, or a minor coordination task consuming substantial senior effort, weakens confidence even where the arithmetic is correct.
Explain the logic behind the allocation where it may not be obvious. This is especially necessary where a partner leads a work package with limited person-months because most execution sits with contributors, or where a specialist partner has a concentrated but high-value role. Budget tables do not explain themselves.
The same applies to subcontracting, financial support to third parties, equipment and other cost categories where relevant. If an external resource is essential to delivery, its relationship to tasks, procurement or selection process, and accountability should be clear. A work package cannot outsource its own governance.
Test ownership and interfaces across the consortium
A named work package leader is not sufficient evidence of control. Identify task leaders and the contributions expected from other beneficiaries, affiliated entities or associated partners. Responsibility should be singular where a decision must be made, even if delivery is collaborative.
Pay particular attention to interfaces. The handover from research to demonstration, from technical development to user validation, or from pilot evidence to exploitation often carries the proposal’s greatest risk. If the work package descriptions do not state what is transferred, in what form, and against what acceptance criteria, the dependency is only implied.
This is also where consortium capacity becomes testable. The partner description may claim experience in deployment, stakeholder engagement or commercialisation. The work plan should show that experience being used in a defined task with adequate effort. Otherwise the capacity claim reads as background information rather than delivery evidence.
Treat risks as part of the work plan
Risk tables are often completed late and detached from the actual work packages. Evaluators notice. A risk is useful only if it relates to a dependency, assumption or decision in the implementation plan.
For each material risk, state the trigger, likelihood, severity, mitigation owner and contingency. “Technical delays” is not a risk description. “The selected interface may not meet performance requirements during integration testing in month 10” is. The mitigation might be an early compatibility test; the contingency might be an alternative interface already assessed in WP2.
Not every risk deserves equal space. Focus on those that could alter delivery of an expected result, compromise a pilot, delay access to data or users, or undermine uptake. A long list of generic risks can look less credible than a short list tied closely to critical path activities.
Run an evaluator consistency check before submission
Read the implementation section separately from the rest of the proposal. Then ask whether an evaluator can trace every major claim. Can the stated methodology be found in tasks? Can each key performance indicator be measured through a defined activity? Does each expected outcome have a named output, owner and route to use? Do dates, person-months, deliverables, milestones and risks tell the same story?
This is not a cosmetic check. A score band is affected by whether the plan is merely plausible or sufficiently detailed and credible. A significant weakness may arise not because the consortium lacks expertise, but because the proposal leaves the evaluator to infer how that expertise will be converted into delivery.
An independent reading is useful here because the authors already know what they meant. BidShark’s automated assessment is designed to surface criterion-specific weaknesses and quote the passage on which each finding rests; it is not a human panel verdict, and it cannot rewrite the work plan or change the call requirements. The value lies in finding disagreement and unsupported assumptions while revisions are still possible.
A work package structure earns confidence when it makes the next question easy to answer. What happens next, who is accountable, what proves completion, and what happens if the assumption fails? If the document answers those questions without relying on the evaluator’s goodwill, it has done its job.