What are project deliverables, and what makes one billable?

Project deliverables are the specific things a client ends up holding when the work is finished: the files, documents, pages, screens, systems or trained people you hand over and they keep. They're what the project produces, as opposed to the tasks, calls and reviews that produce them. On paid client work they're also the units your fee is divided into, which is why a deliverable written without a count and without a definition of finished stops being a promise and turns into an opinion.

What are project deliverables?

A project deliverable is any output the project is committed to producing and handing over, whether that's a physical object, a file, a working system or a completed service. A brand guidelines document, a working checkout flow and a trained support team are all deliverables, because in each case somebody outside the project team ends up with something they didn't have before.

The cleanest way to separate a deliverable from everything else on a project plan is to ask what survives the work. A discovery workshop is an activity, and the written summary that comes out of it is a deliverable. The distinction sounds academic until you invoice for it, because an object can be accepted or sent back and an activity can't. That's why a scope of work is mostly a list of deliverables with prices attached, and a statement of work wraps that list in dates and payment terms.

What are the different types of project deliverables?

There are seven types in common use, and they come in pairs plus one:

1. External. Handed to the client, and the ones the fee is attached to.
2. Internal. Produced for your own team, such as research notes, test plans and handover checklists.
3. Product. The end results the client is buying, such as a website or a set of emails.
4. Process. Material that moves the work along, such as project plans and status reports.
5. Tangible. Things you can open, hold or run, such as a printed report or a piece of software.
6. Intangible. Outcomes rather than objects, such as a trained team or an improved process.
7. Digital. Files and systems delivered electronically, which on agency work is nearly all of them.

Only one of those divisions changes what you write in a client document, and it's the internal and external one. External deliverables carry the fee, so each needs a name, a number and a rule for when it's finished. Internal ones stay out of the client's document, because anything printed in a scope invites comments, and you don't want a client reviewing your test plan.

Intangible deliverables cause the other predictable problem: nobody can accept an outcome the way they accept a file, so a line promising a smoother onboarding experience is never quite finished. Where you genuinely are selling one, attach it to something countable that stands in for it: the trained team becomes two training sessions and a recorded walkthrough, and the smoother onboarding becomes a specific number of screens.

Activities are almost impossible to bill against. Objects are easy, because an object can be accepted or sent back.

What are the 5 key deliverables of a project?

There's no official set of five, but nearly every agency project hands over the same five things, and each belongs in the scope by name:

1. The signed scope. The document listing every other deliverable with a count, a price and an approver.
2. The work product. The emails, screens, pages or campaign the client is buying, which carries most of the fee.
3. Acceptance records. A written sign-off on each item, which is what an invoice points at.
4. The change record. Every request that added to the work, with its price and the client's approval.
5. The handover package. Source files, credentials, documentation and any training, so the client can run what they bought.

Inside the second item, the useful count is however many separate things the client is buying, which on agency work usually lands between three and eight lines. Fewer normally means one line is hiding several things, and more normally means internal steps have leaked into a document the client pays against.

What does a countable deliverable actually look like?

It looks like a short line naming the thing, the quantity and the unit price, and it reads more like a price list than a plan. Dunmore Athletic Co. sells running gear direct to consumers and hired an agency to build the customer education program that new buyers get after their first order. The scope ran seven weeks for a total fee of $16,900. It's marketing work priced as a fixed project; the same deliverables written for a monthly retainer are worked through in our marketing scope of work template.

Every line names the object, counts it and prices the unit. The count is the part agencies skip most often, and the unit price means anything extra is priced before anyone knows what it is, the same mechanic that makes the line between in scope and out of scope hold.

How is a deliverable different from a task, milestone or objective?

Ask who's holding something at the end, and whether it can be reviewed. The four terms get used interchangeably on project plans, and the difference decides which of them you can attach an invoice to:

The handover test is also what separates the client deliverables that belong on the signed list from working material that never leaves your side, and deliverables and milestones pull apart on the same line.

Who pays when a client asks for more of a deliverable?

Whoever the count says pays, which is why the count is worth the four extra words. In week five Erin asked for three more lifecycle emails aimed at a second group of customers, the ones who buy shoes rather than apparel. The scope said six emails at $780, so the request was three emails the fee had never covered, and the quote went back that afternoon at $2,340 with a week added to the schedule.

Without the count, the scope would have read "lifecycle email program", Erin would reasonably have taken a program to mean whatever it needed, and the agency would be choosing between absorbing $2,340 and explaining after the fact why three more emails weren't part of it.

Revision rounds work the same way and get skipped just as often. When Erin later wanted a third pass on all five tour screens, the line saying a third round costs $420 an item made it a $2,100 decision she could weigh rather than an assumption she'd already made. Together the two requests came to $4,440, a bit over a quarter of the fee, and both landed as ordinary purchases. Absorbing them quietly would have cost the same money, which is the arithmetic most agencies never do.

What makes a deliverable finished?

An acceptance rule, written next to the deliverable and naming the person who applies it. Without one, a deliverable is finished when the client stops sending comments, and clients stop sending comments at wildly different points. The version that works on agency projects has four parts: one named approver, a review window of about five business days, a fixed number of revision rounds, and a price for a further round.

Silence needs an answer too, because it's the most common way a project stalls. A deemed-acceptance sentence sounds harsh and almost never gets used; its job is to give you something to point at when a file has sat unreviewed for three weeks. Pair it with a named approver, and the record of who approved what stops depending on anyone's memory of a call.

If Erin rejects a screen, she names the criterion it misses and the fix is included; a change to the wireframe she already approved is a new request, quoted before anyone starts it. The rest of the scope says what you'll produce, and this is the only part that says when producing it stops.

Why a deliverable without a count is just a description

The line that saved the Dunmore project money was a count and a unit price side by side. Write the same deliverable as a lifecycle email program and both of Erin's requests get settled without a number in the room, by whoever is more willing to be difficult about it.

So the working test on any deliverable line is whether a stranger could tell you how many of the thing the client is getting and what the next one costs. The same test works as a register you keep for the life of the project, one row per deliverable:

If a row can't be filled in, the line describes your work rather than committing to it. Writing the scope section by section shows the vague version next to the rewritten one for each part of the document, and a project scope filled in as a sample has the counts already in place if you'd rather start from something finished.

Frequently asked questions