Project deliverables: what they are, with examples

A project deliverable is something the project has to produce and hand over: a report, a system, a building or a trained team. PMI defines it as any unique and verifiable product, result or capability that must be produced to complete a process, phase or project. The key word is verifiable. If nobody can check whether it is done, it is not a deliverable yet.

This guide gives examples, separates deliverables from milestones and outcomes, and shows how to define one and get it signed off. It ends with a worked example and where deliverables come up on the CAPM and PMP exams.

What is a project deliverable?

A deliverable is a thing you can point to. It might be physical, like a new office fit-out, or digital, like a data migration. It might be a document, like a business case. What makes it a deliverable is that the project is committed to producing it and someone can check it against an agreed standard.

Deliverables can be final or interim. The final deliverable is what the project exists to produce. Interim deliverables are the steps along the way, such as a design that has to be approved before construction starts.

Examples of project deliverables

Every kind of project has them:

• Software project: the working application, user guides, test results and a trained support team

• Construction project: the finished building, inspection certificates and as-built drawings

• Marketing campaign: the creative, the media plan and the campaign results report

• Event: the venue booking, the agenda, the registration system and the post-event report

• Internal change project: the new process, the updated policies and the training sessions delivered

Managing the project produces deliverables too: the project charter, the schedule, the risk register and the status reports. Most of these are internal, which is the next distinction.

Deliverables, milestones and outcomes

These three are easy to mix up:

• A deliverable is a product or result you hand over, such as a tested payroll system.

• A milestone is a significant point in the schedule, such as "payroll system goes live on 1 March". It marks a moment and takes no time itself.

• An outcome is the change the deliverable makes possible, such as staff being paid correctly with less manual work.

Tasks are different again. They are the work you do to produce a deliverable. "Test the payroll system" is a task; "test results signed off" is a deliverable.

A project can hit every milestone and hand over every deliverable without achieving the outcome. That is why PMI's newer guidance puts more weight on value and outcomes, not only on outputs.

Internal and external deliverables

External deliverables go to the customer or sponsor: the product, the system, the final report. Internal deliverables stay within the project team, such as the schedule, a test plan or the risk register. Both need an owner and a due date, but usually only external deliverables need the customer's formal acceptance.

How to define a deliverable well

A good deliverable definition answers four questions:

1. What exactly is it? Describe it so that two people would picture the same thing.

2. How will we know it is done? Write acceptance criteria that someone can check.

3. Who owns it? One named person is accountable for producing it.

4. When is it due? Tie it to the schedule and to any milestone it supports.

On larger projects, deliverables are broken into smaller pieces in a work breakdown structure (WBS), so that each piece can be estimated, assigned and tracked.

How deliverables are accepted

On a plan-based project, acceptance usually happens in two steps. First the team checks the deliverable against the quality standards, which PMI calls controlling quality. Then the customer or sponsor formally accepts it against the agreed scope, which PMI calls validating scope. Keep the signed acceptance: it is your evidence if anyone disputes the work later.

In agile, each increment has to meet the team's definition of done, and the product owner and stakeholders review it at the end of each sprint. Acceptance happens in small steps, which makes a late surprise less likely.

A worked example: deliverables for a website redesign

Say a company is redesigning its website. A clear list of deliverables might look like this:

• Site map and page templates: approved by the marketing lead before any build starts

• Content for 40 pages: written, proofread and loaded, with each page signed off by its owner

• Working website: passes the agreed browser, mobile and accessibility tests

• Analytics and tracking: set up, with a test enquiry recorded

• Training: two sessions for the staff who will edit the site

• Handover document: logins, hosting details and how to make common edits

The milestone is "new site live on 15 March". The outcome the company wants is more enquiries from the site. Notice that each deliverable says how it will be checked. "A new website" on its own would invite an argument at the end.

Where deliverables appear on the CAPM and PMP exams

Deliverables are core vocabulary on both exams. On the CAPM, fundamentals and core concepts make up 36% of the exam and predictive, plan-based delivery another 17%, which is where terms like deliverable, milestone and acceptance live.

On the PMP, PMI's 2026 exam outline includes the task "Develop and manage project scope", with enablers such as "Obtain stakeholder agreement on project scope" and "Break down scope", and a separate task to "Plan and optimize quality of products/deliverables".

If you are new to project management, our CAPM course teaches this vocabulary from the start: live, instructor-led CAPM training online from a PMI Authorized Training Partner (ATP #4456), with no work experience needed. Our guide to CAPM exam prep explains how the exam works. If you already lead projects, see our PMP course.