What Are Deliverables in Project Management? (Definition, Types & Examples)

A deliverable is any tangible output a project produces that someone outside the work agrees to check, use, or sign off on: a finished website, a signed contract, a shipped feature, a report handed to a client. If a project is the journey, deliverables are the concrete things you can point to and say “here it is, done.”

That is the formal definition, and the two words carrying the weight in it are unique and verifiable. Unique means it is one identifiable thing, not a category of effort. Verifiable means somebody can check it against an agreed standard and say yes or no. Anything you can’t check, you can’t deliver.

Deliverable vs. task vs. milestone vs. objective

These four get used interchangeably in most project plans, and mixing them up is the single most common source of a plan nobody can act on. They answer different questions.

A rule of thumb that settles most arguments: if you can hand it to someone and ask “does this meet what we agreed to?”, it’s a deliverable. If the honest answer to “who checks this?” is “nobody”, it’s a task. And if it’s a date rather than a thing, it’s a milestone.

The six types of project deliverables

Project deliverables get sorted along three axes: who they’re for, whether you can touch them, and whether they’re part of the finished product or part of running the project. Most projects produce all six kinds.

• Internal deliverables stay inside the team or organization. A test plan, an internal style guide, a budget approved by a manager. They still get accepted, just by someone who works with you rather than someone who pays you.
• External deliverables go to a client, customer or outside stakeholder: a shipped product, a signed-off design, a delivered training session. These are the ones that usually carry contractual acceptance criteria.
• Tangible deliverables are concrete artifacts you can inspect directly: a document, a piece of software, a physical build, a video file.
• Intangible deliverables are real but not physical: a completed training program, a migrated process, a certified team. These need written acceptance criteria more urgently than tangible ones, because there’s no artifact to point at.
• Product deliverables are what the customer actually gets: the feature, the campaign, the building.
• Process deliverables exist so the project can run: the project charter, the risk register, the QA report, the sign-off document. Nobody buys them, and skipping them is how a project loses the paper trail that settles disputes later.

A software launch can produce all six in a fortnight: an internal QA sign-off (internal, tangible, process), the live release itself (external, tangible, product), and a trained support rota (internal, intangible, process).

How do you identify your deliverables?

Most teams identify deliverables by listing what they plan to do and then relabelling the list, which produces verbs pretending to be nouns. The standard method runs the other way round, starting from the outputs and decomposing downward: a work breakdown structure, or WBS.

The governing principle of a WBS is the 100% rule: the structure has to contain all of the work in the project scope, and nothing that isn’t in it. Four steps get you there.

1. Write down the finished outcome first. One sentence describing the state of the world when the project is over. Not the work, the result. Everything below has to add up to this, which is the 100% rule in practice.
2. Split the project into phases or major components. Discovery, build, launch. Or by component: the API, the front end, the migration. Four to seven top-level groups is the usual landing spot, and this is the level where your milestones will sit.
3. Decompose each group until you reach something a person accepts. Keep breaking each branch down, and at every level ask: is there a named person who would review this and say yes or no? The moment the answer is yes, you’ve found a deliverable. Stop decomposing that branch once the remaining work is small enough for one owner to estimate and schedule.
4. Name every deliverable as a noun. “Migrated customer database” rather than “migrate the database”. The noun test is unglamorous and it catches more bad planning than any other single check, because a verb has no finish line and a noun either exists or it doesn’t.

What falls out of the bottom of the WBS is your task list. What sits at the branch points is your deliverable list. Working in this order means every task you end up with is attached to something somebody wanted, which is not true of a list built the other way round.

How to write a deliverable that’s actually trackable

Vague deliverables (“improve onboarding”) are where projects quietly stall, because nobody can say when they’re done. A trackable deliverable has four parts:

• A specific name. “Onboarding email sequence (5 emails, drafted and approved)” beats “onboarding improvements.”
• An owner. One person accountable for it existing, even if several people contribute.
• A due date. Tied to a milestone, not a vague “soon.”
• Acceptance criteria. What has to be true for it to count as done, agreed with whoever’s accepting it before work starts, not after.

That last one matters most, and it’s the one people fudge. A deliverable without agreed acceptance criteria isn’t planned, it’s a guess that someone will like what shows up. The fix is a sentence with a fixed shape:

The formula forces three decisions that vague criteria let you dodge: who the deliverable is for, what they must be able to do with it, and who says yes. If you can’t fill in one of the three blanks, the deliverable isn’t ready to be scheduled yet. Here it is as a block you can paste straight into a task description:

Deliverable:   <one thing, named as a noun>
Owner:         <one person, not a team>
Accepted by:   <one named person or role>
Due:           <date, tied to a milestone>
Accepted when:
  - <observable condition someone else can check>
  - <observable condition someone else can check>
  - <approver> has confirmed acceptance in writing

Two conditions is usually enough. If a deliverable needs eight, it’s two deliverables in a trench coat, and splitting it will make both halves easier to accept.

Deliverable examples by project type

Deliverables look different in every discipline, but the acceptance test is identical everywhere. Here are concrete ones with the criteria that make them checkable.

A worked example: the pricing page launch

Say the project is “launch a new pricing page.” The deliverable is the live, published pricing page itself, not any single step toward it. The tasks underneath it might be: write the copy, design the layout, build it, get legal sign-off, QA on mobile. The milestone is the date the page goes live. The objective, the reason anyone funded it, might be “fewer pricing questions reaching sales.”

Written out properly, that deliverable reads: Live pricing page. Owner: Dana. Accepted by: the head of marketing. Due: 14 March, launch milestone. Accepted when a visitor can reach the page from the main nav and complete a signup from it, the three plans match the approved price list, and the head of marketing has confirmed acceptance in writing. One deliverable, five tasks, one milestone, one objective: four words doing four different jobs.

Who accepts a deliverable, and what happens if they reject it?

A deliverable needs exactly one named acceptor: a person, not a committee and not a department. Committees don’t accept things, they meet about them. If the acceptor is “the client” rather than a named person at the client, you don’t have an acceptor yet, and that is the most common reason finished work sits in limbo for three weeks.

The review loop itself is short. The owner submits the deliverable, the acceptor checks it against the acceptance criteria agreed up front, and the verdict is one of three: accepted, accepted with conditions (small fixes, no change to the schedule), or rejected with specific reasons tied to specific criteria. “I don’t love it” is not a rejection, it’s feedback arriving too late to be useful.

Rejection isn’t a failure of the process, it’s the process working. What makes a rejection expensive is discovering at that moment that the criteria were never agreed at all. PMI’s research into failed projects puts a change in project objectives and inaccurate requirements gathering among the top three causes of failure, and in practice both of those show up as a deliverable rejected by someone who wanted something different all along.

Can deliverables change mid-project?

Deliverables can change mid-project, and often should. What matters is whether a change goes through change control or just happens. The approved set of deliverables and their acceptance criteria is your scope baseline: the agreed version everyone works against, and the thing real progress gets measured from.

Changing a deliverable properly means raising a change request that names the deliverable, states the new acceptance criteria, and says what moves to pay for it: the date, the budget, or another deliverable coming out. Then the baseline is re-approved. Changing it improperly means the work quietly expands and nothing else moves, which is scope creep.

Scope creep is the normal case, not the exception. PMI found that 52% of projects experienced scope creep in the preceding 12 months, up from 43% five years earlier. Written acceptance criteria are the cheapest defence available, because they turn “can you just also…” into a visible request to change something specific, rather than an invisible addition to someone’s week.

Six mistakes that make deliverables slip

PMI puts the cost of poor project performance at 9.9% of every dollar invested, which is $99 million wasted for every $1 billion. A good share of that is deliverables that were never defined well enough to finish. These six account for most of it.

• The deliverable is a verb. “Improve onboarding” has no finish line. Fix: rename it as the artifact that would prove it happened.
• No named acceptor. Finished work waits for somebody to notice it. Fix: name one person before the work starts, not when it ends.
• Acceptance criteria written afterwards. Criteria invented at review time are opinions with better grammar. Fix: agree them in the same conversation where you agree the due date.
• A milestone standing in for a deliverable. “Phase 2 complete” isn’t something anyone can accept. Fix: list what has to exist for the phase to be over.
• One enormous deliverable at the end. Nothing gets verified until it’s too late to change. Fix: split it so something is accepted every few weeks.
• Verbal sign-off. Everyone remembers the meeting differently a month later. Fix: one written confirmation, however brief, against the criteria.

A deliverable log you can copy

A deliverable log is the whole tracking system most projects actually need: five columns, one row per deliverable, reviewed in the weekly check-in. Copy this structure into a spreadsheet or a task tool and it will do more for delivery than any Gantt chart.

The status column only needs four values: not started, in progress, in review, accepted. “Nearly done” is not a status, it’s a feeling.

Where deliverables live in Taskly

In practice most teams don’t need a separate deliverables system, they need their task manager to hold the distinction cleanly. In Taskly, a deliverable is usually a parent task with the acceptance criteria in its description and the supporting work underneath it as subtasks, so anyone can see at a glance what “done” actually means and who owns getting there.

Describe a project to Otto, our AI assistant, in plain English and it drafts that structure for you: the deliverable, its subtasks and a due date, as a proposal you review and approve before anything is created. If you’re weighing up tools for this kind of work more broadly, our breakdown of task management software for teams is a good next stop, and the companion piece on what a milestone is in project management covers the other half of this pair.

Frequently asked questions