Deliverable and milestone

A deliverable is a named output due on a named date: a report, a prototype, a dataset, a piece of software, a plan. It is listed in Annex 1 with a number, a title, a lead partner, a due month and a dissemination level, and each of those is contractual.

A milestone is different in kind. It is a control point that says whether the project is on course (a decision taken, a threshold reached, a component validated) with defined means of verification. Milestones are what the reviewers use to judge progress; deliverables are what they read.

Proposals routinely create too many of both. Forty deliverables across three years is forty documents that must be written, approved, uploaded on time and reported on, and every late one appears in the periodic report. Experienced consortia keep the number modest and make each one substantial.

The dissemination level matters more than it appears. Marking a deliverable public commits you to publishing something you may later wish to keep, and marking everything confidential invites reviewers to ask what the project is contributing to the community. Decide it deliberately per item.

A late deliverable is not fatal but a silent one is. Report it, explain it and give a new date in the periodic report; the reviewers have seen slipped schedules before. What damages a project is a reviewer discovering the gap themselves.