Project Deliverables: Definition, Examples and Tracking

Ask three project managers to define deliverables and you'll hear three answers, usually mixed up with milestones and tasks. It's not a small problem. If a team can't say what it's actually handing over, it can't say whether it's finished either.

This guide gives you a plain definition, examples from different kinds of projects, and a simple way to track deliverables on their own, without tangling them up with the rest of the plan.

What are project deliverables?

Project deliverables are the tangible or intangible outputs that a project must produce and hand over to a client, a stakeholder or another team. A deliverable can be a document, a piece of software, a design, a trained group of people, or a process that's now up and running. The key word is output. It's something you can point to.

A good test: could someone receive it? If you can hand it over and the other party can check it, it's a deliverable. If it's just activity, it isn't.

Deliverables vs milestones vs tasks vs outcomes

Here's the relationship. Tasks produce deliverables. Deliverables usually mark milestones. And outcomes are what everyone really wants, which often show up well after the project ends.

Types of deliverables

Internal and external

External deliverables go to the customer or client. Internal ones stay inside the team or company, like an architecture document or a risk register. Internal ones are easy to forget, and they're often what keeps the external ones on track.

Tangible and intangible

Tangible deliverables you can see or open: a report, a prototype, a software release. Intangible ones are harder to point at, like a trained support team or a new process. Even those need a way to check they've been delivered, such as a signed off training attendance list.

Examples of deliverables by project type

Software project

• Requirements document

• Design mockups

• Working feature released to production

• Test report

• User documentation

Marketing campaign

• Campaign brief

• Content calendar

• Landing page

• Email sequence

• Results report

Construction or facilities project

• Approved drawings

• Permits

• Completed building phase

• Inspection certificate

• Handover pack

How to write a good deliverable

A deliverable needs enough detail that two people would agree whether it's done. Here's a simple formula: a name, a short description, an owner, a due date, and acceptance criteria.

Take "user guide." That's vague. "User guide covering setup and the five most common tasks, reviewed by support and published on the help site by 20 November" is something you can check.

A simple framework for tracking deliverables

Keep deliverables in their own list, separate from the daily task list. Mixing them is how projects end up with a hundred tasks and no clear view of what's being delivered. For each one, record:

• Name and short description

• Owner

• Due date

• Acceptance criteria, meaning what must be true for it to be approved

• Dependencies on other deliverables

• Status, such as not started, in progress, in review or accepted

• Who approves it

Review this list in your weekly meeting. It takes five minutes and tells you more about project health than a long task report.

A worked example: a customer portal project

Let's make it concrete. A team is building a customer portal. Here's how the pieces separate.

Notice how each level answers a different question. The outcome says why we're doing this. Deliverables say what we'll hand over. Milestones say when we'll know we're on track. Tasks say who does what this week. Once a team sees these as separate layers, planning meetings get shorter.

Deliverables in agile projects

People sometimes think agile teams don't have deliverables. They do, they just deliver in smaller pieces. Each sprint should end with a working increment, which is a deliverable of its own, plus anything else that sprint promised, like updated documentation.

The difference is in how you plan. Instead of one big handover at the end, you agree on what each increment must achieve and review it with stakeholders regularly. Tracking is the same, just in smaller chunks and more often.

Acceptance and sign off

A deliverable only counts when someone accepts it. To keep that painless:

• Agree the acceptance criteria before work starts, in writing

• Name one approver, with a backup for holidays

• Set a deadline for review, such as five working days

• Record the decision and any changes requested

What if a deliverable is rejected?

It happens. Check the result against the written criteria first. If it misses them, fix it and resubmit. If it meets them but the client wants something different, that's a change request, and it needs its own conversation about scope and time. Without written criteria you can't tell which of the two you're facing, which is why they matter so much.

Where deliverables fit in your project structure

Deliverables become much easier to manage when your project has a clear hierarchy. Our guide to the 4-tier project management hierarchy shows one way to organize work so that tasks roll up into deliverables and deliverables roll up into projects.

Handling deliverables in Sanplex

If you use Sanplex, the product documentation covers deliverables step by step. The Sanplex deliverables guide (product docs) and the project deliverables guide (product docs) are the places to look for how it works in the tool.

Dependencies between deliverables

Deliverables rarely stand alone. The user guide can't be finished until the feature is stable. The training session needs the user guide. The launch needs the training. Write these links down, because a late deliverable at the start of a chain quietly delays everything after it.

A simple trick is to add a "needs" column to your tracking list and name the deliverable that must be accepted first. In the weekly review, look at anything that's late and ask what it's holding up. That one question finds most of the real risks.

Reporting deliverables to stakeholders

Executives rarely want to read a task list. They want to know which deliverables are done, which are at risk and what's coming next. A short table with status colors does the job in half a page. Keep the wording honest. A deliverable that's late is late, and the sooner people hear it, the more options you have.

A quick check before you call it a deliverable

• Can we name it in a few words?

• Can we hand it to someone?

• Can that person check it against written criteria?

• Does one person own it?

Four yeses and it belongs on the list. Anything less, and it's probably a task or a wish in disguise.

Mistakes to avoid

Treating tasks as deliverables

"Do testing" is activity. "Signed off test report" is a deliverable.

Skipping acceptance criteria

Without them, approval turns into opinion. The client says it isn't what they wanted, and you have nothing written to point to.

Forgetting who approves

A deliverable isn't finished until the right person says so. Name them upfront.

Too many tiny deliverables

If your list has eighty items, most are tasks. Aim for a list you could read in a minute or two.

Frequently asked questions

What are project deliverables?

They are the tangible or intangible outputs a project produces and hands over, such as documents, software, designs or a trained team.

What is the difference between a deliverable and a milestone?

A deliverable is a thing that gets produced, while a milestone is a point in time that marks progress. A deliverable's completion often triggers a milestone, but they aren't the same.

What is the difference between a deliverable and a task?

A task is a piece of work someone does. A deliverable is the result of that work, handed over and checked against acceptance criteria.

How many deliverables should a project have?

There's no fixed number. Keep the list short enough to review in a couple of minutes. If it runs to dozens, many items are probably tasks.

Who approves a deliverable?

Usually the client, sponsor or product owner who asked for it. Name the approver for each deliverable at the start, so there's no confusion at handover.