Deliverable

How Deliverables Work

A deliverable is a tangible or verifiable output produced during or at the end of a project. It is the answer to the question every stakeholder asks: what am I getting? Deliverables can be physical objects (a building, a manufactured component), digital artifacts (a deployed application, a design file, a report), or intangible results (a trained team, an approved process, a signed contract).

Deliverables are defined during the planning phase as part of the scope statement and work breakdown structure. Each deliverable should be specific enough for a neutral third party to verify whether it has been completed. “Redesign the website” is not a verifiable deliverable. “Deliver 12 responsive page templates in Figma with mobile, tablet, and desktop breakpoints” is verifiable because someone can count the templates, check the formats, and confirm the breakpoints exist.

The quality and specificity of deliverable definitions directly determines how smoothly a project runs. Vague deliverables lead to scope disputes, endless revision cycles, and payment conflicts. Specific deliverables create shared expectations and clear completion criteria.

Internal vs External Deliverables

External deliverables are the outputs delivered to the client, sponsor, or end user: the final product, the report, the training materials, the deployed system. Internal deliverables are the intermediate outputs the project team produces along the way: the project plan, the risk register, the test cases, the meeting minutes. Internal deliverables support the process. External deliverables satisfy the business case. Both should be defined, but external deliverables receive more rigorous acceptance criteria because they represent the project’s value to the organization or client.

When to Define Deliverables

Deliverables are defined during the planning phase as the core of the scope statement. Every project should have a deliverables list before work begins. For client engagements, deliverables are documented in the statement of work and often tied to payment milestones. For internal projects, deliverables are documented in the project plan or project charter.

In predictive (waterfall) projects, the full deliverables list is defined upfront and changes only through the change control process. In adaptive (agile) projects, high level deliverables (features, capabilities) are defined at the roadmap level while specific deliverables (user stories, increments) emerge through iterative planning. Even in agile, the sprint produces a defined deliverable: a potentially shippable increment.

Projects with formal procurement (vendor engagements, government contracts) require the most precise deliverable definitions because deliverables are contractual obligations. Ambiguity in a deliverable definition on a fixed price contract transfers financial risk to the provider if the client interprets the deliverable more broadly than intended.

When Not to Define Deliverables

Exploratory work (research spikes, proof of concept builds, discovery phases) may not have predefined deliverables because the purpose is to determine what the deliverables should be. In these cases, the deliverable is the output of the exploration itself: a recommendation, a feasibility assessment, or a prototype. Define the format and acceptance criteria for the exploratory output even if you cannot define the content in advance.

Ongoing operational work (support, maintenance, managed services) is better governed by service level agreements with performance metrics than by deliverable lists. The output of operational work is continuous availability and performance, not discrete artifacts.