What are Deliverables?

Internal vs External Deliverables

Deliverables come in two types, and mixing them up creates confusion:

• External deliverables — outputs handed to clients or stakeholders; these are typically what the contract or SOW specifies: the finished website, the campaign report, the app build
• Internal deliverables — outputs the team produces for their own use; technical specs, design mockups, test plans, meeting notes; clients usually don't see these but they gate the work
• Interim deliverables — work-in-progress outputs at specific milestones; wireframes before design, design before development, staging before production

Deliverables vs Milestones

These terms are often confused. A milestone is a point in time — a checkpoint or date. A deliverable is a thing — the output at that checkpoint.

Example: "Submit first draft" is a milestone. "The first draft of the annual report" is the deliverable. The milestone is the event; the deliverable is what you bring to it.

Not all milestones have deliverables (a kickoff meeting is a milestone without a tangible output), and not all deliverables land on named milestones (a team might produce internal technical specs without a formal checkpoint).

How to Define Deliverables Well

A well-defined deliverable answers four questions:

What is it? Name the output specifically: "5-page WordPress website" not "a website".

What does done look like? Define acceptance criteria: "passes cross-browser testing in Chrome, Firefox, Safari; mobile-responsive; loads under 3 seconds".

When is it due? Attach a date or milestone.

Who accepts it? Name the stakeholder who has authority to say the deliverable is complete.

For agencies, including this level of detail in the SOW eliminates most handover disputes. "It's not what I expected" becomes much harder to say when the acceptance criteria were agreed in writing at project start.

Deliverable Sign-Off Process: Step by Step

Sign-off is the moment a deliverable becomes officially complete. Without a formal process, projects accumulate ambiguity about what's done and who approved it.

Step 1: Deliver the output. Share the completed deliverable with the client in the agreed format. Include a short summary of what was completed and what feedback you need.

Step 2: Set a review window. Give a specific deadline in writing. 'Please review by Thursday at 5pm' not 'let us know when you've had a chance to look.'

Step 3: Address revision rounds. Two revision rounds is standard for most deliverables. After round 2, additional changes go through a change request.

Step 4: Get written approval. An email that says 'This looks good, approved to proceed' is sufficient. Verbal approval on a call is not sign-off.

Step 5: Log it. Record the approval date, who approved, and which version was approved.

Step 6: Update the project tracker. Move the deliverable to 'complete.' The next phase can begin.

• Written approval beats verbal approval every time — follow up every call with a written summary
• Review windows need end dates, not open-ended requests for feedback
• Log the approved version number, not just the approval
• Revision rounds belong in the contract, not in a conversation at the first revision

Common Deliverable Failures and How to Prevent Them

Most deliverable problems trace back to the same root causes.

Unclear acceptance criteria. The deliverable was done by the team's standard but not by the client's. Fix: define acceptance criteria for every deliverable before work begins.

Scope drift during execution. The team adds features or detail not in the original brief. Fix: check deliverable scope against the brief before starting, not after finishing.

Missing review time in the schedule. The client needs 2 weeks to review but the plan allows 3 days. Fix: map review windows into the schedule before committing to a deadline.

Wrong format. The client expected an editable file but received a PDF. Fix: agree on deliverable format in writing at kickoff.

No single owner. Fix: every deliverable has one named owner, responsible for its completion and delivery.

Feedback too late. The client sees the final version for the first time at sign-off and wants major changes. Fix: build informal check-ins into long deliverables — show a draft at 50% complete.

• Acceptance criteria written before work starts prevent disputes after work is done
• Client review windows are project time, not free time — block them in the schedule
• One named owner per deliverable — if ownership is shared, it belongs to no one
• Show work at 50% complete — early feedback is cheap, late feedback is expensive

Deliverables in Agile vs Waterfall

Deliverables work differently depending on your methodology. Mixing the two without telling the client creates friction.

In waterfall, deliverables are defined upfront. Completing a deliverable unlocks the next phase. The client reviews completed work at defined checkpoints, not continuously.

In agile, deliverables are smaller and more frequent. Instead of one final design document, you produce 3-4 design iterations across 6 sprints. Sign-off is less formal.

The problem with mixing them without alignment: if a client expects waterfall-style deliverables (formal, complete, signed off) but your team runs agile, they'll feel like they're approving half-finished work.

Set expectations at kickoff. Tell the client: how many formal deliverables there are, when they'll see them, and what sign-off means in your process.