What is a deliverable?

Definition is a test, not a description

A deliverable that reads final report is not defined, because two reasonable people will produce different documents from that phrase and a third will reject both. A defined deliverable states its form, its scope and its standard: a written report of fifteen to twenty five pages covering the four workstreams named in section two, supplied as a fixed format file, addressing each of the six questions in appendix A. That is longer and it is the difference between a review and an argument. The useful discipline is to write the acceptance criterion first and the deliverable second, because the criterion forces precision. If nobody can write down how they would test it, the deliverable is not yet defined and no amount of effort will make it acceptable.

Deliverable against milestone

A milestone marks a point in the plan and is often used interchangeably with the thing being delivered, which causes two problems. It lets a payment attach to the passage of time rather than to an output, since phase two complete can be asserted without anything changing hands. And it obscures partial delivery, because a phase containing four deliverables is either complete or not, when in reality three arrived and one is late. Keep the two separate in the documents: deliverables are named things with owners and criteria, milestones are dates that group them, and payments attach to deliverables being accepted. Then a slipped item delays one payment rather than blocking a quarter of the fee.

Who accepts it, and against what

Name a person by role, not a committee, and name a deputy. Acceptance by the client, unqualified, means acceptance by whoever is least willing to commit, which in practice means nobody. State the criteria next to each deliverable rather than in a general clause, because generic criteria such as fit for purpose and to a professional standard are unmeasurable and both sides know it. Give a review window in business days and say what silence means. Where a deliverable is rejected, require the rejection to identify the criterion not met, so the supplier can fix a defined gap instead of guessing at dissatisfaction. That single sentence converts most rejections into a day of rework rather than a fortnight of meetings.

Interim deliverables, and why they are worth the overhead

On anything longer than about eight weeks, waiting until the end to hand something over is a risk both sides carry. An early interim deliverable, even a small one, tests the whole chain: whether the reviewer exists, whether the criteria are workable, whether the format suits the client's systems, whether the approval takes three days or three weeks. Discovering that the nominated approver is on leave for a month is far cheaper in week two than in week sixteen. Interim items also give the client visible progress, which is what most often prevents the anxious mid project intervention that turns into scope change. Price them into the schedule so the administrative cost is funded rather than absorbed.

Deliverables that are not documents

Training, support, facilitation and advice all resist definition because the output is a state rather than an object. The way through is to define the evidence instead. Training becomes a delivered session on a named date with an attendance record and a materials pack. Support becomes a stated number of hours within a period, with response times and a log. Advice becomes a written recommendation, because the artefact is what can be accepted. Where a client genuinely wants availability rather than output, that is a retainer, and it should be priced and documented as one rather than dressed as a deliverable nobody can sign off.

Tracking them once the work starts

Use the same names and numbers everywhere: in the schedule, in status reports, on invoices and in acceptance emails. That sounds like administration and it is the mechanism by which a payment query is answered in one search rather than by reconstructing history. Keep a single list showing each deliverable, its owner, its due date, its review status and the date it was accepted, and review it in every status meeting. The list also makes drift visible. When a deliverable has been redefined twice by email, the register shows it, and somebody can ask whether that should have been a variation rather than a conversation.

Questions people ask