How to Define Deliverables in Project Management (With Examples)
Have you ever written someone a letter and then it sat on your desk for a week because you didn’t get around to finding a stamp and putting it in the mailbox?
It’s so easy to mentally check something off as “done” before it’s “done done.”
Yet the intended purpose of something like a letter isn’t achieved until the other person receives it. In project management, these sort of tangible tasks are known as deliverables.
Every project involves completing them. Writing code, planning a budget and creating slides are all examples of deliverables. Service businesses like consulting have deliverables as well.
It’s only by handing these deliverables off to their intended recipient that a project can flow from one task to the next.
For this reason, creating good deliverables and bringing them to completion are integral to success in project management. In this post, we’re going to cover two methods for developing and completing deliverables. But first, let’s define just what deliverables are.
A Definition of Deliverables in Project Management
A deliverable is the completion of a specific and tangible amount of work that includes handing off the newly created increment to the appropriate person. For example, in software design, you might design some software, write it, debug it and do quality assurance, but the customer needs to receive it before it’s complete.
The Project Management glossary defines deliverables as:
“Any tangible outcome that is produced by the project. These can be documents, plans, computer systems, buildings, aircraft, etc. Internal deliverables are also produced as a consequence of executing the project, and are usually only needed by the project team. External deliverables are those that are created for customers and stakeholders.”
And so a deliverable, generally, is something that you can really touch and see. It’s a physical item or a file on a computer.
For many projects, the ultimate objective is a deliverable, such as a house or an airplane. However, smaller deliverables accrue throughout the entire project. They include things like reports, code repository and powerpoint slides.
Teams have deliverables they share amongst themselves. This could be something like debriefing the client, writing up a summary, then presenting the summary to the team.
Or at a retrospective, the team may create goals for the next sprint that are written up and shared with the project leader.
Examples of Deliverables
Deliverables look a lot different depending on the type of industry you’re in. Let’s look at some examples of deliverables within various types of projects.
Deliverables are easy to grasp in a visual, tangible setting. In construction, the final deliverable is whatever the project is set out to create: possibly a house, an office building or a parking lot.
But the team completes many smaller deliverables as it moves toward the end goal. In the initial stages, the architect submits plans to the client, and the contractor makes a bid. And throughout construction, each completed step is another deliverable. This includes laying the foundation, building the frame, adding wiring, electricity and insulation, mounting drywall, installing flooring and tiling, and finally things like appliances, cupboards and lights. Final deliverables are tests to ensure the building is up to code.
The final deliverable in a software project is usually something like an app, a website or an e-commerce site.
Many software teams complete projects in an agile framework these days. This means they select small individual batches of work to complete in one iteration which takes around two weeks. At the end of this iteration, they’ve created a deliverable, called increment, which is one small portion of the final deliverable. This increment is passed onto the client for review.
The team has many internal deliverables throughout a project as well. For example, if the project is running over budget one person may be assigned with coming up with a plan to rein in costs, then write it up and present it to the rest of the team.
Consulting, essentially, is giving advice. People come to a consultant when they have a pressing need and believe the consultant has more insight or expertise into the area than they do. The service, then, is the answers to questions that the consultant provides. Since advice isn’t tangible, this doesn’t qualify as a deliverable.
However, oftentimes this advice is presented in a tangible way. If you’re laying out a migration plan for a company to go from an old system to a new one, a deliverable may be a flow chart that visually represents the path and timeline you recommend the team follow.
In another instance, a consultant might advise a company on how to go mobile. This assignment would require a lot of research and interviews, and so the deliverable would be a report which summarizes the research and concludes with a recommendation.
And so even a project like consulting includes deliverables in its project planning.
In sum, deliverables look a lot different depending on the type of industry and the nature of the service provided. However, deliverables are always a tangible product. Many deliverables are completed in a short time frame of a week or two. And a large project is the compilation of a long series of deliverables.
Checklists for Deliverables
In its simplest form, a project is a list of tasks that leads to a desired outcome. Project management is about creating this list and developing a strategy to complete everything within the project’s budget and timeline.
This isn’t an easy job. When a task is too vague and includes only a few specifications, a team may create something different from what the client had in mind. It’s also easy for a team to mark something off as done before it’s really complete. This prevents a project from moving onto the next item on the list.
In order to prevent these two scenarios from occurring, it’s good to have some systems in place. Let’s look at two list exercises to assist with this; one for creating deliverables and another for completing them.
The “Is-is not” List
Have you ever asked someone to pick something up for you at the store, and what they brought back was the wrong brand or the wrong flavor? At this point, you realize that you needed to have explained your request more clearly.
The same thing happens in projects all the time. The client or project manager communicates a deliverable, but the team hears something completely different.
In order to keep a project on track, the parameters of a deliverable need to be outlined so that everyone understands the expectation. One easy way to do this is with an “is-is not” list.
This list entails making two columns on a sheet of paper, with “is” and “is not” written at the top of each column. The stakeholders in this particular deliverable then each contribute to determine what the deliverable will and won’t be.
If the deliverable is a marketing plan, for example, then some items in the “is” column might include: “under 30 pages,” “organized with headers to be readable and scannable,” “uses photos alongside text,” and “include a social media plan.”
The “is not” column might include: “no long paragraphs,” “no passive voice” and “no magazine ads.”
This list is useful in defining all sorts of deliverables. Even though it’s a simple exercise, it really gets everyone clear on the expectations.
The Done Checklist
Have you ever walked around an office looking for a report, and then someone pulls it from below a pile of papers and says they finished it last week?
If so, you’re not alone. It’s easy for all of us to think we’ve finished something, mentally check it off as done, and move on to another task entirely. However, as mentioned earlier, the deliverable isn’t complete until it’s been received by the intended recipient.
The Scrum methodology has created something called the “Definition of Done” to address this issue. Here is how Ken Schwaber’s organization, The Home of Scrum, defines it:
“Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born. The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review.”
(In this definition, “increment” means the same thing as “deliverable.”)
The Definition of Done, essentially, is a list of all the criteria that must be accomplished to mark a deliverable off as complete.
To this end, many teams create a “done checklist” around a deliverable, to ensure that everyone understands the hoops that need to be jumped through before calling it a day.
For example, on a software team, the “done checklist” might include: writing code, testing, debugging and quality assurance. The final item on this list always includes presenting the deliverable to the end user, who is either someone in the office or the client. The value really hasn’t been added until this final step is “done”!
In sum, deliverables need to be created with a lot of TLC, and it takes stick-to-itiveness to bring them over the finish line. Having processes in place helps to achieve this.
Final Thoughts on Deliverables
A deliverable is easy to see and touch and measure. For this reason, clients like to see deliverables in a project. For example, it adds some weight to include things like slide decks or reports to a consulting proposal.
This leads to a tendency for a team to define success around the deliverable. This isn’t always the best bullseye to aim for, however. The real objective in any project is adding value to the client. That’s ultimately what you’re working to deliver.
To this end, it’s usually good to plan small deliverables around shorter time frames. Clients may not entirely understand what they want in terms of a final deliverable at the beginning of a project. They may only be able to clarify their overall objective.
When a project is completed piecemeal, it creates an opportunity for the client to look at what has been developed and assess how the project is going.
And so rather than look at a deliverable as one enormous task, it’s generally much safer for the team to get into the practice of decomposing projects into smaller units that can be completed in a short time frame. Based on the feedback from the client, the team can then determine its next plan for deliverables.
A deliverable is a tangible product that a team creates during a project. Deliverables can be created for the client or internally for the team.
Deliverables add weight to a project’s proposal, but the project’s real objective isn’t completing them; it’s delivering value to the client.
In order to create useful deliverables, it’s helpful to do some brainstorming beforehand to clarify all the details and metrics around what the deliverable needs to be. Having a “done checklist” ensures that a deliverable is completed according to everyone’s expectations.
A project, in essence, is a series of deliverables. And so having processes around creating and finishing them allows a project to flow smoothly through to its successful completion.