Deliverable

Origin & evolution

The definition is the Project Management Institute's. In the PMBOK Guide, a deliverable is "any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project." Three properties hold it together: it is unique (a specific named artefact, not a category), it is verifiable (there is a test, not an opinion), and it is required (it was in scope and agreed before work began).

Practice has sharpened the distinction between a deliverable and a plain output. An output becomes a deliverable when a stakeholder🧑‍💼StakeholderTeam & OrganisationA person with influence over the productView reference → formally accepts it against agreed acceptance criteria. The acceptance step is what converts "we built a thing" into "we built the thing that was asked for, and the asker agrees." Without criteria written in advance, verification collapses into negotiation after the fact.

The seventh-edition PMBOK pushed the conversation one layer up, toward outcomes🏆OutcomeStrategyA desired business or user outcomeView reference →. A deliverable is the tangible thing produced; the outcome is the change in the world it was meant to cause. A shipped reporting dashboard🎛️DashboardData & AnalyticsAn analytics dashboardView reference → is a deliverable; analysts making faster decisions⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → because of it is the outcome. Confusing the two is how teams celebrate launches that change nothing.

How it works in practice

A project commits to a deliverable: a customer-facing API for order history. The acceptance criteria are written before a line of code: documented endpoints, p95 latency under 200ms, OpenAPI spec published, and a passing integration suite against three client applications.

Eight weeks later the endpoints exist and respond. That is an output. It becomes a deliverable only when the product owner runs the criteria and signs off: latency measured at 180ms, spec live, all three clients green. A fourth client team had requested webhook support midway through; because that was never in the accepted criteria, it is correctly treated as a separate change request✏️Change RequestProgram ManagementA request to change project scopeView reference →, not a reason to withhold acceptance. The criteria, fixed up front, are what keep the deliverable from becoming a moving target.

Deliverable vs. its neighbours

• Milestone⛳MilestoneProgram ManagementA key date or achievementView reference →: A milestone is a point in time, a marker that something significant has happened, and it has zero duration. A deliverable is a thing with substance that the milestone often marks the completion of. The milestone is the date on the calendar; the deliverable is what had to exist by then.
• Outcome: An outcome is the benefit or behaviour change the deliverable enables, measured after delivery. The deliverable is verifiable on acceptance; the outcome is only observable later, in use. A team controls its deliverables and merely influences its outcomes.
• Feature⭐FeatureProduct SpecificationA product capability or featureView reference →: A feature is a unit of product capability users experience. A deliverable is the agreed unit of project output that may contain or ship one or more features. The same feature can be the payload of a deliverable and, separately, a long-lived part of the product.

In the graph

In the Unified Product Graph, a deliverable sits in the delivery region as the verifiable unit of output. It links back to its source through project_produces_deliverableProjectproducesDeliverablehierarchy, forward to the value it carries through deliverable_ships_featureDeliverableshipsFeaturecross-domain, and is time-bounded by milestone_gates_deliverableMilestonegatesDeliverablecross-domain, which makes a milestone a gate the deliverable must clear rather than a loose label. A fourth edge, workflow_artifact_references_deliverableWorkflow ArtifactreferencesDeliverablecross-domain, ties operational artefacts to the deliverable they concern. Keeping the deliverable distinct from both the feature it ships and the milestone that gates it is what lets the graph answer the question status reports📄Status ReportProgram ManagementA project status reportView reference → usually fudge: not whether the date arrived, but whether the verifiable thing that was due by it actually exists.