Deliverables and milestones are the key elements of a Horizon Europe proposal workplan. They are part of the Work Breakdown Structure (in Work Packages (WPs) and tasks) and will be scrutinized by the evaluators to assess the credibility of your proposal. When your proposal is accepted, both deliverables and milestones become important tools for project management, as they will be used by all stakeholders (consortium members and the European Commission) to assess the progress of different project tasks.
Difference between deliverables and milestones in Horizon Europe
As stated in the template for proposals, a deliverable is “a report that is sent to the Commission or Agency providing information to ensure effective monitoring of the project. There are different types of deliverables (e.g., reports on specific activities or results, data management plans, ethics requirements, or security requirements). Still, even if your deliverable is a Demonstrator or a Prototype, you will be asked to submit a written report detailing the characteristics of the demonstrator/prototype and the process to build it.
On the other hand, according to the template for proposals, milestones are “control points in the project that help to chart progress. Milestones may correspond to the achievement of a key result, allowing the next phase of the work to begin. They may also be needed at intermediary points so that, if problems have arisen, corrective measures can be taken. A milestone may be a critical decision point in the project where, for example, the consortium must decide which of several technologies to adopt for further development. The achievement of a milestone should be verifiable”.
When do you need a deliverable?
Deliverables must be defined with care, and you must provide a sufficient number of them to reassure evaluators of the project’s seriousness. It is generally considered good practice to have at least one deliverable per task (in most cases, at the end of the task) to assess the quality of the work and justify funding. For long tasks (more than 18 months), an intermediary deliverable can be helpful.
Deliverables can be classified into three different categories:
- Deliverables are often used to report, with project members providing more details about the implementation of a specific task than in the interim and final reports.
- However, winning proposals often include more interesting deliverables that we will call “key deliverables”. These key deliverables do not merely report on progress but are also considered concrete results of the project. This is the case of prototypes or policy reports, for example.
- Finally, some deliverables are produced to support the project’s development, such as specification deliverables or preliminary analyses. In these cases, the deliverable is of peculiar importance because it will influence the rest of the project.
Note also that deliverables are instrumental in keeping your consortium involved in the project. Therefore, all partners should be responsible for at least one deliverable and contribute to some others. It is also essential to make sure that the workload required by deliverables is balanced and matches the number of person-months allocated to each partner.
Planning deliverables
Discussing and writing deliverables will be the essence of many projects, and there is a high risk of being overwhelmed. To prevent this, try to schedule project deliverables evenly throughout the project (for example, one or two per month). It is also advised not to schedule deliverables during the two months allocated to interim and final reporting. Even better, try not to plan deliverables in the two months leading up to the end of a reporting period. In this case, if one of the deliverables is late, you will have time to remedy the issue before your interim/final report is sent (or before a review).
Note: The same applies to a summer break (nobody likes writing deliverables in August).
Figure 1: This graph shows the cumulative number of deliverables over a 36-month project (starting on the 1st of January). The deliverable plan includes breaks during the summer and during reporting periods.
When do you need a milestone?
As previously mentioned, milestones are control points for the project. At any given moment in the project, you can check whether you are ahead or behind schedule relative to the proposal’s milestone plan. If you are behind schedule, appropriate measures should be taken to remedy the situation.
These control points should generally be placed at the end of essential work packages or tasks. Overall, it is a good practice to have 3-5 milestones per year, not more.
Milestones can, however, be used for any other key moment with essential consequences on the rest of the project, such as:
- A key decision (generally made during a project meeting)
- A key deliverable
- The compliance (or not) with internally defined indicators
Unlike deliverables, which must be linked to a specific WP (ideally a particular task), milestones can be assigned to several WPs simultaneously.
Finally, because deliverables are often produced at the end of a task, they can have the same due date as milestones and serve as proof that the milestone has been reached.
In a nutshell, deliverables and milestones are project management tools against which your Project Officer will assess the progress of your project. You should pay particular attention to evaluating their feasibility and the resources needed when defining them.
You therefore need to start worrying about deliverables and milestones quite early in the project, as soon as your tasks are well defined. It is also recommended to highlight them in visual representations of the work plan, such as the Gantt chart.
