Deliverable

A deliverable is a specific, tangible output a professional services firm commits to producing for a client as part of an agreed engagement scope, accepted against defined criteria.

What counts as a deliverable

Deliverables take many forms depending on practice area:

• Documents: strategy reports, assessments, process maps, specifications
• Systems: configured software, integrations, data pipelines, dashboards
• Experiences: workshops, training sessions, facilitated reviews
• Decisions and recommendations: audit findings, go/no-go recommendations, financial models

The common requirement: a deliverable must be something the client can review, evaluate, and formally accept or reject.

How to define a deliverable

A deliverable is only well-defined when you can answer all four questions:

1. What is it? (Name and format)
2. What does “done” look like? (Acceptance criteria)
3. When is it due? (Target date, linked to milestone)
4. Who accepts it on the client side? (Named approver)

A deliverable defined only by name (“strategy document”) without format, criteria, and approver is a future dispute waiting to happen. Vague deliverables are the primary driver of scope creep because both sides fill the gap with different assumptions.

Deliverables and billing

In milestone-based billing, deliverable acceptance is the trigger for invoice release. In time-and-materials engagements, deliverables may not be billing triggers but still serve as quality and progress gates.

Either way, every deliverable should be formally accepted in writing before the engagement closes. Unsigned deliverables at close-out are the most common cause of payment disputes.

Deliverables vs. tasks

A task is a unit of work performed by the team. A deliverable is the output that work produces. Multiple tasks combine to create a single deliverable. The client reviews and accepts deliverables; the delivery team manages tasks internally. Confusing the two in an engagement leads to work that is busy but not measurably progressing toward acceptance.

In project plans and WBS structures, deliverables sit at the top of the breakdown; tasks are the leaf nodes beneath them. Keeping this distinction clear prevents teams from invoicing for effort rather than outcomes.

Common pitfalls

• Defining deliverables in activity terms (“provide support”) rather than output terms
• No named client approver identified before delivery begins
• Accepting verbal approval without a written record
• Including too many deliverables to track effectively (five to ten is a manageable range for most engagements)
• Omitting a delivery date from the deliverable definition, which makes milestone tracking meaningless

A statement of work should list every deliverable with its format and acceptance criteria before work begins. Servantium’s SOW template includes a deliverable register section for this purpose.