A deliverable is any tangible or intangible output a project must produce and hand over: a document, a product, a service or a result. If it can be checked off and accepted by someone, it is a deliverable.
Deliverables in project management get discussed loosely enough that the word causes real arguments at handover. This guide gives the definition, the types, worked examples by project type, and the distinction between a deliverable, a milestone and an objective, which is where most of the confusion sits.
What a deliverable is
A deliverable is a specific, verifiable output produced to complete a project or part of one. The test is simple: can somebody receive it, review it and say yes or no?
That test rules more things out than people expect. “Improve the onboarding process” is not a deliverable, because there is nothing to hand over and no moment where it is either done or not. “A documented onboarding process, approved by the HR lead” is one.
Three properties make something a deliverable rather than an activity:
- It is an output, not work. Writing the report is the activity. The report is the deliverable.
- It has a recipient. Somebody accepts it, whether that is a client, a sponsor or another team.
- It can be verified. There are criteria that decide whether it is finished, agreed before it is produced rather than argued about afterwards.
Types of deliverables in project management
Deliverables are usually split two ways, and the two splits are independent of each other.
| Split | Type | What it means |
|---|---|---|
| By audience | Internal | Produced for the team or organisation, such as a project plan or a status report. Nobody outside sees it |
| By audience | External | Handed to the client or end user, such as the finished website or the training delivered |
| By purpose | Product | Part of the thing being built, and the reason the project exists |
| By purpose | Process | Produced to manage the work rather than to be the work, such as a risk register |
A project plan is internal and process. A delivered mobile app is external and product. Training materials written for a client are external but arguably process, which is exactly the sort of edge case worth settling in the contract rather than at handover.
Deliverables can also be tangible or intangible. A printed manual is tangible; a completed migration or a trained team is intangible. Both are legitimate, but intangible deliverables need harder acceptance criteria precisely because there is no object to point at.
Examples of project deliverables
The quickest way to understand project deliverables is by project type, because what counts as one changes completely depending on what you are building.
| Project type | External deliverables | Internal deliverables |
|---|---|---|
| Software build | Working application, user documentation, deployed release | Technical specification, test plan, code review records |
| Website redesign | Live site, style guide, content migrated | Wireframes, sitemap, QA checklist |
| Construction | Completed building, as-built drawings, compliance certificates | Site survey, procurement schedule, safety plan |
| Marketing campaign | Published assets, campaign report, landing pages | Creative brief, media plan, budget tracker |
| Consulting engagement | Findings report, recommendations, workshop delivered | Interview notes, analysis model, engagement plan |
| Event | The event itself, attendee materials, post-event summary | Run sheet, supplier contracts, staffing rota |
Notice that the internal column looks similar across every row while the external column is entirely different. That is the useful pattern: process deliverables are largely the same job to job, which is why they can be templated, and product deliverables never are.
5 key deliverables every project needs
Whatever you are building, these five process deliverables in project management appear on nearly every project, and their absence is a reliable predictor of trouble.
-
Kick-off meeting.
The deliverable is not the meeting but its output: agreed objectives, named roles and a shared understanding of scope, recorded somewhere both sides can point at later. A project that starts without one usually discovers in month two that the client and the team defined success differently.
-
Project plan.
Scope, schedule, budget, resources and risks in one document. It is the reference every later decision is measured against, and it is what makes change requests possible: without a baseline, nothing can be identified as a change.
-
Communications plan.
Who gets told what, how often and in what format. It sounds like bureaucracy until a stakeholder complains they were not informed, at which point it is the thing that settles whether they should have been.
-
Meeting notes.
Decisions, owners and dates. The value is not the record of discussion but the record of what was decided, which is what prevents the same question being reopened three times.
-
Performance reports.
Progress against plan, with actual time and cost next to what was estimated. This is the deliverable that turns monitoring into something factual rather than a round of opinions about how things feel.
Deliverable, milestone or objective?
These three get used interchangeably and they are not the same thing. A deliverable is a what, a milestone is a when, and an objective is a why.
| Term | What it is | Example |
|---|---|---|
| Objective | The outcome the project exists to achieve | Reduce support response time by 30% |
| Deliverable | A tangible output produced along the way | New ticketing system, configured and live |
| Milestone | A point in the schedule, with no duration or output of its own | System go-live date reached |
| Task | The work performed to produce a deliverable | Migrate historical tickets |
The practical consequence: you can hit every milestone and still fail the objective, if the deliverables were accepted without meeting their criteria. Milestones measure schedule. Only deliverables measure whether anything was actually produced.
Acceptance criteria: what makes a deliverable done
Acceptance criteria are the conditions a deliverable must meet before the recipient signs it off. Without them, “done” is a matter of opinion, and the opinion that matters is whoever is paying.
Good criteria share three characteristics. They are written before the work starts, they are specific enough that two people would reach the same verdict, and they are agreed by the person who will accept the deliverable rather than by the person producing it.
Compare these two:
- Weak: “The report will be comprehensive and well presented.”
- Usable: “The report covers all six sites, includes cost data for the last 24 months, and is delivered as a PDF with an editable source file by 14 March.”
How to identify deliverables
Deliverables come out of the work breakdown structure rather than being listed from memory. The method is to decompose downwards until each item is something a single owner can produce and someone else can accept.
-
Start from the objective.
Write what the project must achieve, then ask what must exist for that to be true. Those are your top level deliverables.
-
Break each one down.
Split until you reach items that can be produced by one owner within a sensible period. Stop when further splitting produces tasks rather than outputs.
-
Separate internal from external.
Mark which are contractual and which are for your own use. Only the external ones need client sign-off, and confusing the two creates approval steps nobody needed.
-
Write acceptance criteria for each.
If you cannot write criteria, the deliverable is defined too vaguely to be worth listing. That is a useful signal rather than an inconvenience.
-
Assign an owner and a date.
A deliverable with no named owner is nobody’s job. A deliverable with no date competes badly against work that has one.
Once deliverables are defined this way, they become the unit you plan and track against. Recording time and cost per deliverable rather than per project is what lets you compare estimated against actual effort and find out which kinds of output you consistently underestimate.
actiTIME integrated well into our process
actiTIME is very robust, integrated well into your business process, and most important, helps you focus on your business instead of monkeying around with technology.
Frequently asked questions
What is an example of a deliverable?
A finished website handed over to a client, a training course delivered to staff, a findings report submitted to a sponsor, or a configured system running in production. Internally, a project plan, a risk register or a performance report. The common factor is that each one can be handed to somebody who then decides whether to accept it.
What are deliverables in a project?
Deliverables in project management are the outputs the project must produce, both the ones the client receives and the ones the team produces to manage the work. A project is effectively defined by its deliverables: the objective states why it exists, and the deliverables state what will exist when it is finished.
What are deliverables in the workplace?
Outside formal project management the word usually means the concrete outputs someone is accountable for producing in a given period, such as a report, a presentation or a completed process. The test is the same as in project management: an activity is not a deliverable, but the thing the activity produces is.
What is another word for deliverables?
Outputs is the closest general synonym, and outcomes is commonly used but means something different: an outcome is the effect a deliverable produces. Depending on context you will also see work products, artefacts, and in contracts, simply the goods or services. Prefer deliverable in a project document, because it is the term acceptance criteria attach to.
What is the difference between a deliverable and a milestone?
A deliverable is a thing produced; a milestone is a moment in the schedule. Milestones have zero duration and no output of their own, and usually mark that a deliverable has been accepted or a phase completed. You can hit a milestone on time and still have an unacceptable deliverable, which is why tracking both matters.
How many deliverables should a project have?
As many as it takes for each one to have a single owner and clear acceptance criteria, and no more. If a deliverable is too large for one owner to be accountable for, split it. If you have so many that nobody reviews the list, you have decomposed into tasks and should roll them back up.
Track the effort behind each deliverable
Defining deliverables well tells you what the project owes. Knowing what each one actually cost to produce is what makes the next set of estimates better than the last.
actiTIME records time against tasks and projects, compares estimated with actual effort, and flags budgets before they are exceeded. Start a free 30 day trial. No credit card required, and the free version covers up to 3 users afterwards.
