Thousands of creative leaders manage their agencies with Workamajig.
Thousands of creative leaders manage their agencies with Workamajig.
Fortune 500 marketing departments run on Workamajig.
All-in-one marketing project management software for creative agencies & in-house teams
Marketing resource & traffic management tool schedules, tracks & assigns tasks all in one place
Track time & tasks for more transparency, more billable hours & keep projects right on schedule
Get real time insight on cash flow, budgeting & forecast revenue with custom reports
Fully integrated accounting and financial reporting tools make billing & invoicing a breeze
Capture new business opportunities & potential revenue with easy to use CRM for marketing
Workamajig is secure, compliant and ready to integrate.
Our pricing plans include all features for everyone, from small agencies to large corporations
Get fully customized pricing and features for your team of 100+ Users
Get weekly tips on marketing project management & running an efficient agency.
Get answers to the most common questions about Workamajig.
Get customer support for existing Workamajig Users.
Have questions about Workamajig? Get in touch!
Listen to Kelly Campbell's podcast on what it means to lead a creative agency.
Post job openings on the completely free job board just for creatives.
See the platform in action, ask as many questions as you'd like, and discuss your specific needs with our friendly and knowledgable sales team. Demos typically run for about an hour.
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.
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:
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.
A common way to categorize deliverables is to divide them into “external” and “internal” deliverables. There’s an easy method for defining them:
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.
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.
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:
A work breakdown structure (WBS) is an example of a process deliverable
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:
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.
All deliverables - project and process - have two components:
For example, if you’re implementing a content management system (CMS) for a client, one of your deliverables might be:
Before this deliverable can be accepted, however, it must meet both the client’s and the internal stakeholder’s requirements:
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:
To define the project deliverables, you have to work backward 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:
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.
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:
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:
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.
.
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:
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.
Following a these simple tips can make managing project deliverables easier:
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.
Get all our templates, tips, and fresh content so you can run effective, profitable, low-stress projects in your agency or team.
The Workamajig© name and the Workamajig© logo are the exclusive trademarks of Creative Manager, Inc. Creative Manager, Inc. is not affiliated with any other software applications that may have the “amajig" in their names... but we do love them all dearly. All rights in this website and our software are reserved. ©2022 Creative Manager Inc. dba Workamajig. Privacy Policy.