A project deliverable is any output created as the result of work done during a project. Defining, tracking, and managing project deliverables is one of the most important responsibilities of a project manager. This guide will help you understand project deliverables in more detail.

What is a Project Deliverable?

You might use the term “deliverable” casually at work every day.

In project management, however, it means something more definite: a specific output created as the result of work performed during the course of a project.

For any output to be classified as a “deliverable” within a project, it has to meet a few criteria:

• It must be within the scope of the project
• Stakeholders - external or internal - must agree to it
• It must be the result of deliberate work
• It must have a definite role in accomplishing the project’s objective

For example, a creative team might create a number of documents during the course of developing a new website.

Some of these - such as a designer’s casual sketches - are neither critical for the project’s objective, nor the result of deliberate work. Hence, you wouldn’t classify these as deliverables.

On the other hand, your developers can’t really proceed if they don’t have a website wireframe. Since the wireframe is a result of deliberate, objective-focused work, you would classify it as a deliverable.

Anything can be a deliverable in a project. A bicycle can be a deliverable, as well as the document outlining the plan to create it.

The deliverable can be massive and tangible, such as a stadium or a factory. It can also be tiny and intangible, such as a one-page marketing document.

Project deliverables can be created for both external and internal stakeholders. An example of the former would be the website you make for a client. A design requirements document would be an example of the latter.

Deliverables can also be “stacked”, i.e. one deliverable might have several of its own deliverables. A “website” might be your primary objective. To create it, you might have two additional deliverables - “website wireframe” and “website mockup”.

This also means that deliverables can depend on one another. You can’t create a website mockup unless you have a wireframe. And you can’t create the actual website until you’ve finalized the mockup.

Deliverables by themselves aren’t the project’s objective. Rather, they chart the path to reach it. The more deliverables you complete on time, the better your chances of meeting the project’s goals on schedule as well.

This is why project managers often focus obsessively on the deliverables - in defining, managing, and tracking them.

Internal vs External Deliverables

A common way to categorize deliverables is to divide them into “external” and “internal” deliverables. There’s an easy method for defining them:

• Any work done that is not a part of doing business with clients or customers is an internal deliverable
• Any work done to fulfill a client’s demands or to win more business is an external deliverable

You can think of internal deliverables as anything you create as a part of running the business. Doing taxes, keeping accounts, creating corporate documents - these are all internal deliverables. You need them to run the business, but they don’t really generate revenue.

As Nick Austin Lee of Flowbit says:

Most of the time you would know whether a deliverable is internal or external based on who it is created for. But if you’re unsure, just ask yourself: “is this deliverable going to leave the organization?”

If the answer is “yes”, then it would be an external deliverable.
Deliverables vs Milestones

Another source of confusion for new project managers is the difference between deliverables and milestones.

Milestones are checkpoints in the course of a project. You can insert them at any point to mark the completion of an important activity. They don’t have deadlines, nor do they have an impact on the project’s objectives. They are simply a way to keep track of the project’s progress.

You’ll create milestones to break down a complex deliverable into its constituent parts. For example, if your deliverable is to create a set of “high-level requirements”, one of your milestones might be “document current processes”.

 Gantt charts in Workamajig help you keep track of milestones

Milestones aren’t meant for clients; they’re meant for the internal project team. You can include them in the project status report but it’s not essential to do so.

Project vs Process Deliverables

There is yet another distinction you need to make when it comes to deliverables: project vs process deliverables.

Project deliverables are the big, client-focused accomplishments we talked about earlier.

Process deliverables describe the path that will help you create the project deliverables.

Think of all the documents you create in the course of managing a project. You'll start off with a project scope statement, create a project plan, and develop a work breakdown structure.

These documents are seldom client-facing. Instead, they're crated for internal stakeholders and the project team to help manage the project better. You can very well run a project without them, though you'll likely have a hard time reaching your objective.

All these documents are examples of process deliverables. Creating them isn't the goal of the project. But creating them does make reaching the goal much easier.

Some examples of process deliverables are:

• Statement of work
• Work breakdown structure
• Project scope statement
• Project governance plan

 A work breakdown structure (WBS) is an example of a process deliverable

Project Deliverables Examples

As you've seen so far, project deliverables can be of any type - tangible and intangible, big and small, internal and external. They can describe the project's goals or the path to reach those goals.

To help you understand them even better, there are a few examples of project deliverables:

• A SWOT analysis of a competitor to identify opportunities. Can be for internal or external stakeholders.
• A work breakdown structure created at the start of a house construction project.
• A project scope statement that will guide the internal project team and define the project for external stakeholders.
• A gap analysis report created to identify weaknesses and opportunities when compared to a competitor.
• A design presentation made for the clients to help them understand the project's goals.
• A website wireframe made for the development team.
• An inspection report created during a construction project that the client will use for compliance purposes.
• An eBook created by the marketing team to promote a new product.
• An whitepaper created by the development team to help clients understand a new product.
• A document detailing the quality control process a factory will use to ensure products are up to the client's standards.
• A Gantt chart created at the start of a project to define its timeline and milestones.

These are just some project deliverables examples. You can have virtually anything as a deliverable as long as stakeholders agree to it. If it is the product of deliberate work, and it helps you reach the project’s objective, it can be classified as a deliverable.

 A Gantt chart is an example of a process deliverable (if it isn’t shared with the client) as well as a project deliverable (if it is shared with the client)

In the next section, I’ll cover the more important parts: how to define project deliverables and how to manage them.

Defining Project Deliverables

All deliverables - project and process - have two components:

• The specific deliverable
• The acceptance criteria for the deliverable

For example, if you’re implementing a content management system (CMS) for a client, one of your deliverables might be:

• Create a training program to help employees understand and use the CMS

Before this deliverable can be accepted, however, it must meet both the client’s and the internal stakeholder’s requirements:

• Internal requirements: Training program must have agency branding
• External requirements: Training program must be at least 20 hours long and include a questionnaire to evaluate user knowledge post-completion.

These requirements would be the deliverable’s “acceptance criteria”.

So how does one go about defining both the deliverables and their acceptance criteria?

I’ll share a process for doing so below:

Project Deliverables Definition Process

To define the project deliverables, you have to work backwards from the objective. Figure out what you need to do. Then figure out the requirements that will make the deliverable acceptable.

To define the deliverables, start by asking the following questions:

• What is this project trying to achieve?
• What is the purpose, goal, or end result the client wants once the project closes?
• What are the constituent parts of the project’s objective?
• What is the form and function of each of these constituent parts?
• How important is this part to the overall project?
• How will we create (or acquire) this part?
• What is the cost of production/acquisition of this part?
• How much time will it take to produce/acquire this part?

Essentially, you’re decomposing the project’s objective into smaller parts. At the same time, you’re evaluating the feasibility and priority of each constituent part. Refer to your work breakdown structure - if you have one - to help define the deliverables.

Gathering Requirements for Deliverables

You’ll find that defining the deliverables is fairly easy. The harder part is defining the requirements for each deliverable.

Requirements specify the criteria that makes a deliverable acceptable. If the requirements are incomplete, clients will request changes and revisions. This can increase the project’s scope and budget, eating into your profits.

A key step in the deliverables definition process, therefore, is gathering requirements.

For example, if you’re setting up a CMS, it needs to meet the following requirements:

• Create, edit, and manage documents
• Import existing documents
• Integrate with client’s existing email system
• Include training programs for end-users

If the deliverable, i.e. the CMS, does not meet these requirements, clients might reject it, leading to scope changes.

There are several tactics you can adopt to gather requirements. These can be simple (“user observations”) or complex (“quality function deployment”).

In creative projects, subjective processes such as interviews, user observations, questionnaires, etc. are particularly helpful in gathering requirements.

Regardless of the tactic you use, there are a few questions you should ask when evaluating the requirements for each deliverable:

• Who are the key stakeholders who need to sign-off on this deliverable?
• What are the stakeholder’s top priorities for this deliverable?
• Are these requirements within the project’s scope and budget? If not, how much will the scope/budget need to be expanded to accommodate them?
• Have we created similar deliverables in the past? What were their requirements?
• What is the industry standard for these deliverables?
• Who is the end-user for this deliverable? What will make it a success for them?
• What is the minimum quality criteria this deliverable must meet to be successful? How do you measure it?

Besides the specific requirements for each deliverable, there will also be some “universal” requirements. These are usually best practices followed across the industry or your agency.

For instance, if you’re creating a website for a client, it must pass W3C’s markup validation requirements.

Similarly, every marketing document must carry the agency’s branding and contact information.

.

Defining Process Deliverables

Apart from the above, you also need a number of process deliverables to create the project deliverables. You’ll use these to keep track of the deliverables and ensure that they meet all requirements.

Most agencies will already have standard practices when it comes to defining these deliverables. For instance, you might have a fixed templates for work breakdown structures, project plans, statements of work, etc.

Nevertheless, here are some questions you need to ask when you define process deliverables:

• What process deliverables will be required to complete the project’s objective?
• Who will be responsible for planning, implementation and maintenance of each deliverable?
• How will you track and manage each deliverable?
• When is each deliverable due? For recurring deliverables, what will be the frequency and date of each check-in?
• Who is responsible for signing-off on each deliverable?

For example, you need all stakeholders to sign-off on the statement of work (SoW), a key process deliverable. Asking questions like the above will help you figure out the specific stakeholders, their requirements, and the due dates.

Tips for Managing Project Deliverables

Following a these simple tips can make managing project deliverables easier:

• Define the deliverables before you start your work. Adding deliverables once the work has already started will change the project's scope and budget.
• Be thorough when gathering requirements for each deliverable. The better you understand the requirements, the easier it will be for stakeholders to accept the deliverable.
• Figure out whether a deliverable is meant for internal or external stakeholders. You have more leeway in case of the former.
• Decompose the project's objective to uncover your key deliverables. Before beginning work, however, make sure that you get stakeholders to sign-off on each deliverable.
• Involve stakeholders in the project initiation meeting and seek their input when defining deliverables and their acceptance criteria.
• Segregate deliverables into distinct phases to help you track them better.
• Question stakeholders as well as end-users to better understand the requirements for each deliverable.
• Identify the metrics you will use to measure the acceptability of each deliverable upfront. This will help avoid changes in the deliverables later.
• Identify the deadline for each deliverable. Tie these to milestones to ensure better tracking.
• Include a list of deliverables, their deadlines, and the project team responsible for each deliverable in the project plan.
• Use a project management software such as Workamajig to make tracking and managing project deliverables easier.
• Keep a clear distinction between deliverables and milestones, and between process and project deliverables.
• Whenever possible, use standardized process deliverables.
• When gathering requirements, ensure that they meet the SMART goals criteria.

This guide is by no means exhaustive. Every project manager must develop his own process for defining and managing deliverables. This will depend on your own working style as well as the limitations & capabilities of your project team.

One way to make managing deliverables easier is to use a project management software. For example, Workamajig breaks deliverables into “rounds” and “steps”. You send out deliverables for review (internally or externally) in “rounds”. Each revision request is handled in “steps” within each round.

This makes it easy to keep track of deliverables and ensure that they meet the acceptance criteria.

You can learn more about how Workamajig can help you improve operational efficiency below: