What is a project deliverable? Definition and examples

Whatever your sector, you have heard the word “deliverable”. A deliverable is any tangible, verifiable result that a project produces and hands over — to a client, to another team, or to the organization itself. Every project has them, and handing over the last one is what marks the end of the project. Deliverables clarify the objective and the work required to reach it.

Internal and external deliverables

External deliverables are what the client receives: a product, a report, a trained team, a migrated system. Internal ones — a specification, a test plan, a migration script, a training kit — exist to make the external ones possible. Both need an owner and an acceptance criterion; the mistake is to track only the external ones and discover, three weeks from the deadline, that an internal deliverable nobody was responsible for is missing.

Deliverable, milestone or task?

The three are constantly confused. 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. A useful plan holds all three: the deliverable states what is owed, the tasks state how it will be built, and the milestone states when it is expected to be accepted.

Making acceptance explicit

A deliverable without acceptance criteria is a source of conflict. State how it will be judged complete, who signs it off and within how many days. That single line prevents most end-of-project disputes: without it, “finished” means delivered for the supplier and satisfactory for the client, and those two definitions rarely coincide.

Sizing them properly

A deliverable too large to be reviewed in one sitting will be accepted late and badly. One too small clutters the plan with formalities. The practical test is the review: if a competent reviewer can form a judgement in under two hours, the size is right. Splitting a large deliverable into successive versions — draft, reviewed, final — is often better than splitting it into pieces.

From deliverables to the work breakdown

Because deliverables are nouns, they make a far better basis for a work breakdown structure than activities do. Listing what the project owes, then decomposing each item until it can be estimated, produces a plan whose completeness can actually be checked against the contract or the scope statement.

Tying deliverables to the plan

In FoxPlan, deliverables are attached to milestones and tasks in the project plan, with their documents, decisions and risks alongside — so their status is visible in the same place as the schedule rather than in a separate file. Acceptance then becomes a fact recorded on the plan, not an email someone has to find again.