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.

Most of what's published about them sorts deliverables into categories, and the categories are accurate enough. The part that goes missing is the sentence you actually have to write in a document a client signs, so the rest of this page covers the definition, the types worth knowing, and then the three things a deliverable line needs before it can settle an argument about money. There's a real $16,900 program running underneath the second half so the difference shows up in dollars.

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. The word covers a lot of ground on purpose. A brand guidelines document, a functioning checkout flow, a set of trained support staff and a signed compliance report 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. A round of testing is an activity, and the test report is a deliverable. The distinction sounds academic until you try to invoice for it, at which point activities turn out to be almost impossible to bill against and objects turn out to be easy, because an object can be looked at and either accepted or sent back.

That's also why deliverables belong at the center of the document you send a client rather than buried in a project plan. A scope of work is mostly a list of them with prices attached, and a statement of work wraps that list in dates and payment terms. Everything else in either document is context around the list.

What are the different types of project deliverables?

Three divisions come up in nearly every published definition, and they describe real differences. Tangible deliverables are things you can open, hold or run, such as a website, a printed report or a piece of software, while intangible ones are outcomes like an improved process, a trained team or a lifted brand awareness score. Internal deliverables are produced for your own team and external ones go to the client. Process deliverables such as project plans and status reports exist to move the work along, while product deliverables are the end results the client was actually buying.

Only one of those three 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 deliverables are yours to manage, and listing them in a document the client signs tends to backfire, because anything printed in a scope invites comments, and you don't want a client reviewing your test plan when they're paying for the thing the test plan produces.

Intangible deliverables cause the other predictable problem, and it's worth naming before it happens to you. Nobody can accept an outcome the way they accept a file, so a line promising better internal alignment or a smoother onboarding experience can never quite be 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 isn't a fixed set of five, and the articles offering you one are quietly counting different things: types of deliverable in one place, groups of example in another, whole sample projects somewhere else. Five is a round number that reads well in a headline, and it's been repeated often enough to look like a standard.

The question worth asking instead is how many deliverables your own project should have, and that one has a real answer: however many separate things the client is buying, which on agency work usually lands somewhere between three and eight. Fewer than three normally means one line is hiding several things inside it, and that's the condition that produces an argument in month two. More than eight normally means the plan has been broken down into internal steps that nobody outside your team needs to review or pay for separately.

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, which makes the document useful in week five rather than only in week one. The count is the part agencies skip most often. Writing "lifecycle emails" instead of "six lifecycle emails at $780 each" saves four words and gives away the only number that can answer a question about a seventh one.

The unit price does a second job that's easy to miss. Because $780 an email is printed on the page, the price of anything extra is agreed before anyone knows what the extra thing is, so a request months later is priced by arithmetic rather than by negotiation. That's the same mechanic that makes a priced exclusion work, and where the line between in scope and out of scope gets drawn is worth reading alongside this.

How do you tell a deliverable from a task?

Ask who's holding something at the end, and whether it can be reviewed. A task is work your team does and a deliverable is what your team hands over, so writing the emails is a task and the six built emails are the deliverable. The test holds up well because it's the same test the client applies without thinking about it, and their version of the question is simply what they got for the money.

The related question is where deliverables sit against dates, since project plans usually list both together and the two get treated as interchangeable. They aren't, and the difference decides which of them you can attach an invoice to. Deliverables and milestones pull apart along the same line as tasks and deliverables: a milestone is a moment the project passes through and a deliverable is an object somebody keeps afterwards.

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. Nobody had to argue about whether it was included, because there was a number on the page saying it wasn't.

Run the same week without the count and the conversation goes differently. The scope would have read "lifecycle email program", Erin would reasonably have understood a program to mean whatever the program needed, and the agency would be choosing between absorbing $2,340 of work or explaining after the fact why three more emails weren't part of something they'd described as a program. Neither of those is a good afternoon, and the second one costs the relationship more than it costs the invoice.

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. Those two requests together came to $4,440, a bit over a quarter of the original fee, and both of them landed as ordinary purchases because the rates were already written down. Absorbing them quietly would have cost exactly the same money, which is the arithmetic most agencies never sit down and 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 sentence saying that a deliverable is treated as accepted if no comments arrive within the review window sounds harsh written down and almost never gets used, since its real job is to give you something to point at when a file has been sitting unreviewed for three weeks and the next stage can't start. Pair it with a named approver, and the record of who approved what stops depending on anyone's memory of a call.

That paragraph is doing something the surrounding scope can't do on its own. The rest of the document says what you'll produce, and this is the only part that says when producing it stops, which is the difference between a project that ends and one that keeps generating small requests until somebody loses patience.

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 sitting next to each other: "lifecycle emails, 6 of them, at $780 each". That one line turned a week-five request into a $2,340 quote sent the same afternoon, and the matching revision line turned a second request into a $2,100 decision instead of two more unpaid passes. Write the same deliverable as a lifecycle email program and both of those conversations happen without a number in the room, which means they get settled by whoever is more willing to be difficult about it.

So the working test on any deliverable line you write is whether a stranger reading it could tell you how many of the thing the client is getting and what the next one costs. If they can't, 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