A project deliverable is a unique and verifiable product, result, or capability that a project must produce to complete a process, phase, or project. A deliverable has an owner, acceptance criteria, and an approver. Examples include a project charter, a tested software release, and a training program.
What Is a Project Deliverable?
A project deliverable is any unique and verifiable product, result, or capability that the project must produce to complete a process, phase, or project. PMI uses this definition. A deliverable is verified by the team and accepted by the customer.
A deliverable has 4 attributes:
- Unique: The output differs from other outputs in the project.
- Verifiable: A test, inspection, or review confirms that it exists and meets requirements.
- Required: The scope baseline lists it as part of the project.
- Accepted: An authorized person signs off on it against acceptance criteria.
A deliverable is an output, not an activity. “Design the interface” is a task. “Approved interface design document” is a deliverable.
What Are the Types of Project Deliverables?
Project deliverables fall into 4 classification dimensions: audience (internal or external), position (interim or final), form (tangible or intangible), and category (product, service, result, or document). One deliverable holds one value in each dimension.
| Dimension | Types | Definition | Example |
| Audience | Internal | Supports the project team; the customer does not receive it | Risk register |
| Audience | External | Handed to the customer or end user | Live website |
| Position | Interim | Produced mid-project to validate direction | Prototype |
| Position | Final | The main output the project exists to produce | Released mobile app |
| Form | Tangible | Physical or directly measurable output | Printed manual, hardware unit |
| Form | Intangible | Non-physical capability or result | Trained staff, improved workflow |
| Category | Product | A thing the project builds | Software release |
| Category | Service | A capability the project creates | 24-hour support desk |
| Category | Result | An outcome or approval | Regulatory approval |
| Category | Document | A written artifact | Requirements specification |
Intangible deliverables cause the most acceptance disputes. A trained team has no physical form, so the project defines the acceptance test in advance, such as “90% of trainees score 80% or higher on the assessment.”
What Are Examples of Project Deliverables?
Every industry produces deliverables with measurable acceptance criteria. Software produces tested releases, marketing produces campaign assets, construction produces inspected structures, and operations projects produce documented processes.
The criteria below are illustrative.
| Industry | Deliverable | Type | Acceptance Criterion |
| Software | Tested checkout feature | External, product | 0 critical defects; 95% of test cases pass |
| Software | Product requirements document | Internal, document | Signed by the sponsor and 3 stakeholder leads |
| Marketing | Campaign landing page | External, product | Loads in under 2.5 seconds on mobile; tracks 5 conversion events |
| Marketing | Campaign performance report | External, document | Compares 8 KPIs against targets |
| Construction | Foundation inspection certificate | Interim, result | Passed by the municipal inspector |
| Healthcare | Staff training program | External, service | 90% of staff complete training and score 80% or higher |
| Operations | Process documentation | Internal, document | Reviewed by the process owner; covers 100% of steps |
| Manufacturing | Pilot production run | Interim, product | 500 units at a defect rate under 1% |
What Is the Difference Between Deliverables, Milestones, Tasks, and Objectives?
A deliverable is an output. A milestone is a zero-duration point on the schedule. A task is an activity that consumes time. An objective is the measurable goal the project achieves. Each term answers a different question.
| Term | Answers | Duration | Example |
| Objective | What result does the project achieve? | Spans the project | Cut onboarding time from 10 days to 5 days |
| Deliverable | What does the team produce? | Produced over time | Redesigned onboarding workflow |
| Task | What work creates the output? | Hours to days | Draft the workflow map |
| Milestone | When does a key event occur? | 0 days | “Workflow approved” |
A prototype is a deliverable. “Prototype complete” is the milestone. Drafting the prototype is the task. Every deliverable supports at least 1 objective, and every task supports at least 1 deliverable.
How Do Deliverables Connect to the Work Breakdown Structure?
The work breakdown structure (WBS) decomposes the project scope into deliverables, then into work packages. The WBS 100% rule requires that the WBS contains all deliverables and no work outside them. Each work package belongs to one deliverable.
The decomposition has 3 levels:
- Project: The total scope.
- Deliverables: Major outputs, such as “Mobile app” and “Training materials.”
- Work packages: The lowest level; each package has an owner, a cost, and a duration.
A deliverable-oriented WBS names each element with a noun, such as “Test report,” and not a verb, such as “Test the system.” Verbs describe tasks, which belong in the schedule. The full structure and levels are covered in Work Breakdown Structure (WBS): Definition, Levels, and Example.
How Does a Deliverable Move From Creation to Acceptance?
A deliverable passes through 4 states: created, verified, accepted, and transitioned. The team creates it, quality control verifies it, the customer accepts it through scope validation, and operations receive it at handover.
| State | Activity | Owner | Output |
| Created | Team executes the work packages | Project team | Deliverable |
| Verified | Quality control checks it against requirements | Quality lead | Verified deliverable |
| Accepted | Customer or sponsor validates it against acceptance criteria | Customer or sponsor | Accepted deliverable |
| Transitioned | Team hands it to operations or the user | Project manager | Handover record |
Verification asks, “Did we build it right?” Acceptance asks, “Did we build the right thing?” A deliverable that passes verification can still fail acceptance. The control methods are covered in Project Scope Management: Definition, Importance, Benefits, and How It Works.
How Do You Identify and Define Deliverables?
Identify deliverables in 6 steps: state the objective, name the final output, decompose it, assign owners, set acceptance criteria, and confirm with stakeholders. Each step produces a written record in the scope documents.
- State the project objective in measurable terms.
- Name the final deliverable the project must produce.
- Decompose the final deliverable into interim deliverables and work packages through the WBS.
- Assign one owner to each deliverable.
- Write acceptance criteria for each deliverable.
- Confirm the list with stakeholders and record it in the scope baseline.
A worked example uses the objective “cut onboarding time from 10 days to 5 days.” The final deliverable is a redesigned onboarding workflow. Interim deliverables are a workflow map, updated interface designs, a training guide, and a launch checklist.
How Do You Write Acceptance Criteria for a Deliverable?
Write each acceptance criterion as a pass-or-fail statement with a number or a named standard. A criterion names the measure, the threshold, and the method of verification. Vague words such as “good” or “fast” fail the test.
| Weak Criterion | Strong Criterion |
| The page loads quickly | The page loads in under 2.5 seconds on a 4G connection |
| The report is complete | The report covers all 8 agreed KPIs |
| Staff are trained | 90% of staff complete the course and score 80% or higher |
| The system is reliable | The system records 99.9% uptime over 30 days |
A deliverable description records the full set of fields:
| Field | Example Entry |
| ID and WBS code | D-07 / 1.3.2 |
| Name | Campaign landing page |
| Owner | Web lead |
| Due date | 15 June |
| Acceptance criteria | Loads under 2.5 seconds; tracks 5 conversion events |
| Acceptance authority | Marketing director |
| Status | Verified |
Which Project Documents Define Deliverables?
5 documents define deliverables: the project charter, the scope statement, the WBS, the requirements documentation, and the project schedule. The scope statement and WBS together form the scope baseline.
| Document | Role for Deliverables |
| Project charter | States high-level deliverables and objectives |
| Project scope statement | Lists deliverables, acceptance criteria, and exclusions |
| WBS and WBS dictionary | Decomposes deliverables into work packages and describes each |
| Requirements documentation | Records the requirements each deliverable satisfies |
| Project schedule | Places deliverables and milestones on the timeline |
A requirements traceability matrix links each requirement to the deliverable that satisfies it. The link proves that no requirement is missing and no deliverable lacks a purpose.
What Mistakes Do Teams Make With Deliverables?
5 mistakes cause most deliverable failures: listing tasks as deliverables, vague criteria, missing owners, no stakeholder confirmation, and skipping interim deliverables. Each mistake has a direct fix.
| Mistake | Consequence | Fix |
| Listing tasks as deliverables | Progress measures effort, not output | Name deliverables with nouns |
| Vague acceptance criteria | Disputes at acceptance | Write numeric pass-or-fail criteria |
| No owner | Delays; nobody resolves blockers | Assign 1 owner per deliverable |
| No stakeholder confirmation | Rework after delivery | Obtain sign-off on the list before execution |
| Skipping interim deliverables | Late discovery of defects | Add review deliverables at each phase |
FAQs About Project Deliverables
What Is the Difference Between a Deliverable and an Output?
A deliverable is a verifiable output that the project must produce and the customer accepts. An output is any result of an activity. Every deliverable is an output, but not every output is a deliverable.
What Is a Key Deliverable?
A key deliverable is a major output tied to a milestone or a payment. Key deliverables carry contractual or strategic importance. The sponsor and customer track them in status reports.
Who Approves Project Deliverables?
The customer or sponsor approves deliverables. The scope statement names the acceptance authority for each deliverable. The project manager collects the sign-off and records it in the project documents.
Are Deliverables Always Tangible?
No. Deliverables are tangible or intangible. A building is tangible. A trained team and an improved process are intangible. Intangible deliverables require explicit acceptance tests.
How Do You Define Deliverable Requirements and Acceptance Criteria?
Define requirements through elicitation with stakeholders, record them in the requirements documentation, trace each to a deliverable, and write a pass-or-fail acceptance criterion for each. Business analysis techniques structure this work.
Requirements analysis and traceability are core business analysis skills. The Professional Business Analyst Training from PMI Authorized Training Partner PMTI teaches how to elicit requirements and turn them into verifiable deliverables.
