Project deliverables: definition, examples and milestones

A project deliverable is a concrete, verifiable result that a project produces and hands over to someone: a client, an internal department, management. The word is everywhere in project management, yet it stays vague in most plans: activities disguised as deliverables, deliverables without acceptance criteria, milestones confused with what they mark. This guide gives the definition, examples by sector, the difference between a deliverable, a milestone, an objective and a task, and a method to define, describe, accept and track the deliverables of a project.

Deliverable definition in project management

By definition, a deliverable is any product, service or measurable result a project must provide to reach its objective. It is unique, identifiable, and it exists once a piece of work is finished: you can show it, test it, read it, count it. Handing over the last deliverable marks the end of the project. Four characteristics set it apart from a mere activity:

• It is tangible or at least verifiable: a document, a piece of software, a building, a trained team, a documented decision.
• It has a recipient: someone receives it, uses it or signs it off.
• It is the result of work, not the work itself: “audit report delivered” is a deliverable, “audit” is a task.
• It is subject to acceptance criteria: you know in advance what will allow it to be declared compliant.

Internal or external, tangible or intangible deliverables

Deliverables are usually classified along two axes. The first is the recipient. External deliverables are what the client or sponsor receives: a product, a report, a migrated system. They are often contractual. Internal deliverables — a specification, a test plan, a migration script, a training kit — exist to produce the external ones; they stay within the team but everything else depends on them. The second axis is the nature of the result.

• Tangible: an object or a file that can be handed over — mock-up, prototype, structure, application, design file.
• Intangible: a real but non-material result — a trained team, a deployed process, a certification obtained, a decision arbitrated. It is made verifiable through evidence: attendance sheet, certificate, minutes.
• The classic mistake is to track only external deliverables and discover, three weeks before the deadline, that an internal deliverable nobody was responsible for is missing.

Examples of project deliverables by type of project

Deliverables depend on the sector, but the logic is the same everywhere: each phase of the project produces a result that someone is waiting for. Here are common examples.

Deliverable, milestone, objective or task: what is the difference?

The four notions are constantly confused, and the confusion shows in the plan. A deliverable is a thing produced — a noun. A task is the work that produces it — a verb. A milestone is a date that marks a state and carries no work of its own. An objective is the expected benefit, which deliverables make possible without guaranteeing it. A useful plan holds all four: the deliverable says what is owed, the tasks say how it will be built, the milestone says when it is expected, the objective says why.

Defining project deliverables from the WBS

Because they are nouns, deliverables make a far better basis for breaking down a project than activities do. The work breakdown structure (WBS) starts from what the project owes, then decomposes each item until it can be estimated. The method takes six steps.

1. Re-read the scope: contract, project charter, requirements document. Every written commitment corresponds to at least one external deliverable.
2. List the external deliverables, then, for each one, the internal deliverables needed to produce it (studies, specifications, tests, training).
3. Break down deliverables that are too large into work packages until you get items whose effort and duration can be estimated. That is the WBS itself.
4. Check the 100% rule: the sum of deliverables and work packages must cover the whole scope, no more, no less.
5. Assign a single owner to each deliverable and an approver on the sponsor’s side.
6. Date each deliverable and attach it to a milestone in the schedule: that link is what will later allow progress to be tracked.

Writing a deliverable sheet: the template to reuse

A well-defined deliverable fits on a one-page sheet. It serves as the reference throughout production and avoids end-of-project arguments. Here are the minimum sections.

• Name: short, singular, phrased as a result (“User manual v1”, not “Writing the manual”).
• Description: what the deliverable contains, what it does not, its format and medium (file, application, structure, session).
• Acceptance criteria: the objective conditions that allow it to be declared compliant — completeness, tests passed, compliance with a standard, maximum error rate.
• Owner: the one person who answers for its production.
• Approver: the person or body that accepts it, and the approval lead time.
• Date: due date and associated milestone.
• Dependencies: deliverables or decisions that must exist beforehand, and those that depend on it.
• Version: draft, reviewed, final. Splitting a large deliverable into successive versions is often better than splitting it into pieces.

Accepting a deliverable: acceptance criteria and sign-off

A deliverable without acceptance criteria is a source of conflict. Without them, “finished” means delivered for the supplier and satisfactory for the client, and those two definitions rarely coincide. Acceptance — user acceptance testing in IT and industrial projects — always follows the same path.

• The criteria are written before production, not at hand-over, and agreed by both parties.
• The approver is named: project manager on the client side, business owner, steering committee for structuring deliverables.
• The review is time-boxed: an approval lead time (often 5 to 10 working days) after which silence counts as acceptance, if the contract provides for it.
• The outcome is recorded: acceptance report, reservations listed and dated, decision logged.
• A rejected deliverable goes back into production with its reservations; it is not “almost finished”, it is in progress.

Tracking the progress of a deliverable

The progress of a deliverable is not measured by elapsed time but by its state. A simple life cycle is enough, provided it is applied the same way everywhere.

• Not started: the sheet exists, dependencies are not cleared.
• In progress: production has begun; progress is read on the tasks that produce it, in effort consumed or physical percentage.
• Handed over: the deliverable is passed to the approver, the review period starts.
• Under acceptance: reservations being processed.
• Accepted or rejected: decision recorded, with date and signatory.

On a medium-sized project, the list of deliverables with their state is often the best dashboard for the sponsor: it answers “where are we?” without exposing the detail of tasks. It is also the basis for reporting to the steering committee.

Common mistakes with deliverables

• The vague deliverable: “website” without saying which pages, which languages, which hosting. It will be delivered incomplete or over-specified.
• No acceptance criteria: approval turns into a negotiation.
• Confusing the deliverable with the activity: “weekly meetings” or “support” are not deliverables; the minutes or the support plan are.
• The oversized deliverable: impossible to review in one sitting, it is accepted late and badly. If a competent reviewer cannot form a judgement in under two hours, split it into versions.
• No owner, or several: with two owners, nobody answers.
• Forgetting internal deliverables: training, data migration, the cut-over plan show up at the last minute.
• Not linking the deliverable to the schedule: its due date lives in a separate file and drifts without anyone noticing.

In FoxPlan

In FoxPlan, deliverables are carried by the tasks and milestones of the Gantt schedule: each deliverable has a date, an owner and dependencies visible in the same place as the calendar. Files are attached to the task, requirements are tracked in their dedicated module, and progress is read on the task that produces the deliverable. Acceptance is decided in a steering committee session, with an agenda and a logged decision, which makes sign-off a fact recorded on the project rather than an email to dig up.

See how to do it in the FoxPlan documentation ↗

Frequently asked questions

What is a deliverable in project management?

A deliverable is a concrete, verifiable result that a project produces and hands over to a recipient: a document, a piece of software, a structure, a trained team. It differs from a task, which is the work needed to produce it. Each deliverable has an owner, a date and acceptance criteria.

What is the difference between a milestone and a deliverable?

The deliverable is a thing produced; the milestone is a date that marks a state of the project. The milestone “acceptance signed” has no duration and no work of its own; it records that the deliverable “tested application” has been accepted. In a schedule, an important milestone is almost always tied to the hand-over or approval of a deliverable.

What are examples of project deliverables?

In an IT project: requirements document, mock-ups, application in production, documentation. In construction: building permit, execution drawings, accepted structure. In marketing: brand guidelines, campaign launched, performance report. A deliverable can also be intangible, such as a trained team or a certification obtained.

How do you present a deliverable?

Present it from its sheet: the name, what it contains, the agreed acceptance criteria and the status of each, any reservations. Show the result itself rather than the work done, and end with the decision expected from the approver: accept, accept with reservations or reject.

Who approves a deliverable?

The approver is named in the deliverable sheet, before production: project manager on the sponsor’s side, business owner, or steering committee for structuring deliverables. They check the acceptance criteria and record their decision in an acceptance report, with any reservations.

Can a deliverable be intangible?

Yes. A training session delivered, a process deployed or a certification obtained are intangible deliverables. To keep them verifiable, they come with evidence: attendance sheet, certificate, published procedure. The acceptance criterion then applies to that evidence.

Go further with FoxPlan

• Planning and Gantt chart
• Project milestones
• Work breakdown structure (WBS)
• The steering committee