What are project deliverables? Types, examples, and how to define them

A project deliverable is any unique, verifiable output (such as documents, products, service, or results) that a project must produce to be considered complete. Deliverables can be internal or external, tangible or intangible, and they’re agreed with stakeholders and defined at the very start of a project.

Put simply, project deliverables are the tangible or intangible results a team produces to satisfy the requirements set by clients or stakeholders. The Project Management Institute’s PMBOK Guide defines a deliverable as “any unique and verifiable product, result, or capability to perform a service” that’s required to complete a project.

Sounds confusing? Don’t worry, let’s take a step back and break it down.

Every project has an objective. To accomplish it, certain tasks and goals must be completed. And the final results must be delivered to the internal or external stakeholders.

Let’s take organizing a company’s annual client conference as an example project. The objective is clear—host a successful conference that strengthens client relationships. Within the scope of this project, three things are agreed upon and need to be done for it to succeed:

1. Book a venue and set the date
2. Line up speakers and build the agenda
3. Promote the event and manage registrations

So for the stakeholder to view this project as complete, they might ask to receive three things: a finalized event plan and agenda, an attendee registration list, and a post-event report. These are all examples of project deliverables.

What this guide covers:

• What project deliverables are (and the PMBOK definition)
• The main types of deliverables (internal vs. external, tangible vs. intangible, process vs. product)
• Real examples by project type
• Deliverables vs. objectives, tasks, and milestones
• How to define deliverables in four steps
• Common mistakes and a quick FAQ

What are deliverables in project management?

We can immediately pinpoint several things that define deliverables in a project:

1. They help accomplish the objective of the project
2. They are agreed upon by the project manager and the stakeholders
3. They are defined from the start

As such, project deliverables are useful for project managers to better organize the project and for clients to better oversee it.Let’s take a look at each of these points to better understand what are and aren’t project deliverables. 

1. Project deliverables help accomplish the objective of the project

As you can see, we’re distinguishing between the objective and the deliverables. Some of you may ask – are they not the same thing? 

They can be, but most of the time they’re not. It depends on the scope of the project. If the objective is simply to book a venue, then the objective and deliverable overlap—you hand over the signed venue booking and the project’s done.

But anything more complex than that will likely result in a multitude of deliverables that are different yet complementary to the objective. And, since our example (organizing a conference) involves multiple parts beyond simply booking a venue, it will accordingly have many multiple deliverables.

Project deliverables are the results you’re passing on to the client or stakeholder. As such, they can come in many forms:

• Reports about completed work
• Spreadsheets
• Project plans
• Design documents and images
• Presentations
• Strategy documents and recommendations
• Completed work items as articles, emails, business plans, signed contracts

2. Project deliverables are agreed upon by the project manager and stakeholders

Project deliverables help manage expectations—having objectives without deliverables can potentially lead to disagreements between parties. 

For example, if the project objective is to improve a host a successful conference, but no deliverables are outlined, then a stakeholder might be unhappy if turnout is lower than they’d pictured — even when the event itself ran smoothly.

That may not be the organizer’s fault, but the stakeholder could see the objective as incomplete and treat it as grounds for a dispute.

In this regard, project deliverables help with transparency, accountability, and defining the scope, and they must be agreed upon by both parties.

3. Project deliverables must be defined from the start

It’s essential that the agreement comes at the very start of the project. Clear-cut deliverables help organize the project, assign responsibilities, and define a timeline. 

Of course, they can change and evolve throughout a project if it’s mutually agreed upon by the involved parties. However, moving goalposts can lead to confusion and project derailment if mismanaged. The entire purpose of project deliverables is to ensure everyone is on the same page and works toward achieving a specific goal. When goals change, it can render some of the completed work obsolete, or teams might need to be restructured, or project plans might have to be reworked. 

So it’s often better to define more general deliverables that leave some breathing room than to set out with very specific deliverables that inevitably get changed later down the line.

A quick tip: use DeskTime’s project tracking to automatically track the time your team spends on each task, so your reports on deliverables stay accurate.

Types of project deliverables

Deliverables are usually grouped along three simple lines. Most real deliverables sit in more than one group at once—for example, when using the classification types below, a final report for the client would be described as an external, tangible, and a product deliverable.

Type	What it means	Example
Internal	Used within the team or organization to run the project	Project plan, status report, internal QA checklist
External	Delivered to the client or external stakeholder	Finished product, marketing campaign, signed final report
Tangible	A physical or concrete output	Prototype, printed report, hardware
Intangible	A non-physical result	Training program, a new process, a brand strategy
Process	Interim outputs that move the work forward	Wireframes, test results, design specifications
Product	The final goods or services the project exists to produce	Software app, website, user manual

Project deliverables examples by industry

Deliverables look different in every field. Here are typical examples by project type—useful as a starting checklist when you’re scoping your own work.

Project type	Typical deliverables
Software / IT	Product requirements doc, architecture diagram, working code, QA / test report, deployment and handoff docs
Marketing campaign	Strategy document, creative assets, landing pages, tracking setup, final ROI report
Website redesign	Sitemap, wireframes, design mockups, the live site, a content style guide
Consulting engagement	Statement of work, diagnostic findings deck, recommendations memo, knowledge-transfer session
Construction	Blueprints, permits, inspection reports, the finished structure
Research / academic	Research proposal, literature review, dataset, final report or paper

What project deliverables are NOT:

• Milestones: milestones help keep the project on track, but they are typically not deliverables in themselves. 
• Product deliverables: things like software and hardware, and finished physical products are typically referred to as product deliverables and differentiated from project deliverables. 
• Accomplishments outside of the scope of the project: things that are achieved during the project but were not defined as necessary for its successful completion. 

It’s easy to mix up deliverables with the related terms around them. Here’s how they differ, using the conference project example from earlier:

Term	What it is	Example (conference project)
Objective / goal	The outcome the project works toward	“Host a successful annual conference”
Task	An activity performed to create a deliverable	“Line up speakers and build the agenda”
Milestone	A checkpoint in time that marks progress	“Agenda approved”
Deliverable	The verifiable output that’s handed over	Final event plan + attendee list + post-event report

How to define project deliverables

Defining deliverables comes down to four steps:

1. Break the objective into sub-goals. Ask what needs to be done to fulfill the objective.
2. Define acceptance criteria. Specify the point at which each sub-goal is considered done—make it objectively measurable and verifiable, not a matter of opinion.
3. Confirm format, quantity, and owner with stakeholders. Agree what type of deliverable, in what format, how many, and who signs off.
4. Document them. Capture the deliverables in your scope statement or work breakdown structure (WBS) so everyone works from the same list.

To illustrate the process of defining project deliverables, let’s apply this logic to a different example—digital marketing. Here’s the thought process for creating brand new social media accounts for a brand.

• Objective: Establish a social media presence for a company.
• Process: Register profiles on Facebook, Instagram, LinkedIn, and X (formerly Twitter), then prepare content for each platform.
• Acceptance criteria: Profiles are created and filled out for all four platforms. One month of daily content is prepared for each.
• Project deliverables:
  • a document with the login information for the new accounts;
  • a content calendar with daily posts for one month. Once both are delivered, the project is finished.

Note how the project’s objective was to simply establish social media presence, not maintain it. The deliverables were selected based on the project’s scope. For example, if the objective was to grow these accounts, the deliverables would be different: it would more likely be performance reports, future content calendars, and similar documents.

Usually both parties work together to define deliverables. Sometimes a client brings a goal and looks to the provider to explain how it’ll be achieved; other times a knowledgeable client has a specific ask. Either way, what type, what format, and how many should all be outlined from the get-go.

Common mistakes when defining deliverables

A few patterns cause most deliverable disputes, and all of them are avoidable:

• Vague, unverifiable deliverables. “A strategy” could be a one-page memo or a 60-page deck. If there’s no objective condition for what is “done,” it’s not a deliverable yet.
• Confusing tasks or milestones with deliverables. Teams can complete every task and still miss the output the stakeholder actually expected. The deliverable must be clear so everyone knows what to expect.
• No acceptance criteria. Without agreed criteria, sign-off becomes an opinion, and opinions change.
• Undocumented scope changes. It’s normal for deliverables to change during the course of a project. But when any changes are made, both parties must be agree to them, and they must be documented in writing. Otherwise the team may be working on the newly changed deliverable, but the stakeholder who was not informed about the change will not accept it because it is different from what they expected.

Conclusion

Project deliverables are most often used by project managers to structure their work, but any project benefits from them: they define responsibilities and keep everyone aligned on what’s ahead. A deliverable can be anything from a report about the work done to the thing created in the process—the type depends on the project and the agreement in place. Define them clearly and from the start, and you give the project a much better chance of finishing on the same page it started on.

FAQ

What are project deliverables in simple terms?

Project deliverables are verifiable outputs (documents, products, services, or results) that a project has to produce to be considered complete. They are agreed with the stakeholders at the start of the project.

What is an example of a project deliverable?

A keyword research document, a finished website, a training program, or a signed contract are all deliverables. The exact ones depend on the project type and industry.

What’s the difference between a deliverable and a milestone?

A deliverable is an output you hand over to a stakeholder; a milestone is a checkpoint in time that marks progress. A milestone can coincide with a deliverable, but they’re not the same thing.

What are deliverables in a software or IT project?

Common ones include a product requirements document, architecture diagrams, working code, QA/test reports, and deployment or handoff documentation.

What’s the difference between internal and external deliverables?

Internal deliverables (like a project plan) help the team run the work; external deliverables (like the final product or report) are handed to the client or stakeholder.

Article written by

Viesturs Abelis

A fan of crunching complex topics into digestible bites, Viesturs helps tech companies – and startups in particular – convey their unique stories to broader audiences. In addition to his work on DeskTime’s blog, you’ll come across his writing in Tech.eu, The Next Web, Crunchbase, and more.