What are project deliverables? Examples and a practical checklist

A deliverable is an output you can identify and evaluate

Project deliverables are the specific outputs a project is expected to produce. They may be files, physical items, working software or an agreed service such as a training session. A useful deliverable definition tells the recipient what they will receive and how they can determine whether it meets the agreement.

Atlassian distinguishes internal outputs, client-facing outputs and intermediate outputs that support the final result. For a freelancer, that distinction prevents an internal draft from becoming an accidental promise. Not everything you create while working is automatically something the client is entitled to receive.

Deliverables are not activities, milestones or business goals

“Interview stakeholders” describes an activity. “Research findings report” names an output. “Findings report accepted” marks a milestone. “Increase customer retention” is a business goal that the report may support, not necessarily a result the freelancer can control or guarantee.

A timeline shows when the activities, reviews and handoffs should happen. A scope of work establishes broader boundaries, responsibilities and exclusions. The deliverable list concentrates on the things being produced. Use it inside the wider agreement rather than expecting a list of file names to settle every commercial question.

Services need the same clarity as files. “One remote training session covering the agreed workflow, with a participant handout” is more concrete than “team enabled.” Attendance can prove that a session occurred; it does not by itself prove that every participant mastered the material.

Examples of internal, intermediate and final outputs

Internal deliverables help your team do the work: a risk log, quality checklist or production plan. They can be important without being client handoffs. State whether they are internal or shared, especially when they contain rough notes, estimates or third-party information.

Intermediate deliverables support a later output: a wireframe, outline, storyboard or prototype. If a client must approve one before production continues, identify it as a reviewable deliverable with its own version and acceptance conditions. “Intermediate” does not mean disposable or exempt from clear expectations.

Final deliverables fulfill the promised handoff: an approved copy deck, print-ready artwork, a configured website or a completed workshop and its materials. A copywriter might deliver final text without uploading it; a designer might deliver artwork without buying print production. Name that boundary rather than letting the recipient infer it.

Worked example: a freelance presentation package

This fictional example concerns a freelancer, Rowan, producing a sales presentation for a small consultancy. The consultancy supplies approved copy and its existing brand assets. The agreed final output is a 12-slide editable presentation plus a PDF export of the same version, with one consolidated revision round.

The editable presentation is one deliverable with a specified slide count and format. The PDF is a second handoff format that must match it. Layout work, internal proofreading and export preparation are activities, not extra deliverables to list as if they were client products.

Acceptance criteria include all 12 agreed slides being present, supplied copy appearing correctly, text remaining editable in the agreed application, and the PDF matching the accepted presentation. The client approver receives the named version for review. Rowan records the final file names, delivery location and dated acceptance response.

The client later asks for a separate investor deck. That is a new output, not a correction to the promised sales presentation. By contrast, fixing a missing agreed slide addresses a failure against the existing criteria. The difference depends on the agreement, not on whether the request sounds small.

Write a deliverable definition someone else can use

Use concrete nouns and observable requirements. “Brand support” and “website improvements” leave too much unresolved. A recipient should be able to identify the intended output without reading every message from the project.

Copyable wording: “Deliverable: final sales presentation, 12 slides, supplied as an editable presentation file and matching PDF. Inputs: approved client copy and brand assets. Review: one consolidated round from the named approver. Acceptance: agreed slides present, copy correct, text editable and exports matching. Handoff: identified final version in the agreed shared location.”

1. Name the output and its purpose without promising an uncontrolled business outcome.
2. Specify quantity, format, required contents and any agreed technical requirements.
3. Identify the producer, recipient and authorized approver.
4. Record required client inputs and dependencies that affect readiness.
5. Define acceptance criteria and the evidence used to evaluate them.
6. State review arrangements, the due date and the final delivery location.
7. Clarify related exclusions, such as implementation, source assets or ongoing maintenance, in the agreement.

Keep submission, acceptance and evidence separate

Submission means you made an output available for review or handoff. Acceptance means the authorized person confirmed it under the agreed process. Evidence connects those events to a specific version. A sent email may show submission without showing acceptance; a generic “looks good” may be unclear if several versions were in circulation.

Use distinct states such as in progress, ready for review, changes requested and accepted. Record the version, reviewer, date and relevant criteria when a decision arrives. If the client accepts only part of a package, identify that part rather than marking the entire engagement accepted.

For intangible services, agree evidence before delivery. A workshop might use the agenda, delivered materials and a completion acknowledgment. Do not substitute a recording for acceptance, assume recording permission, or claim learning outcomes that were never assessed. The right evidence depends on what was actually promised.

Resolve missing outputs and new requests differently

When feedback arrives, compare it with the agreed deliverable definition and acceptance criteria. A missing export or broken promised file format may be a correction. A new language version or additional format may be an addition. Confirm the classification with the client instead of automatically billing every comment or absorbing every request.

Keep earlier accepted versions and document which version supersedes them. Avoid sending an unlabeled folder containing drafts and finals together. At handoff, explain what is included, where it can be found and what remains open.

If a promised input is late, update the timeline and state which deliverable is affected. If the output itself changes, agree that change through the commercial process. A schedule update alone should not silently change the list of things the client expects to receive.

Audit the next handoff, not the entire project at once

Choose the next item you plan to send a client. Check that it has a clear name, identified version, acceptance criteria, authorized reviewer and delivery location. Ask whether your evidence would let another person understand what was delivered and accepted without reconstructing the conversation.

Moolamochi separates commercial agreement, delivery acceptance and payment, and private work is not automatically shared. That supports a useful discipline: deliberately distinguish internal material from a client handoff, and never treat an invoice as proof that an output was accepted. New access is currently waitlist-only.