Project Management

What is a Project Deliverable?

Reading Time:
6 mins read
Ben Willmott
Founder

For a Project Manager, one of the most likely causes of confrontation on a project or when a project is closing are the project deliverables. 

They’re often misunderstood as they’re agreed upon in a pressured pre-project phase when creating the project's Statement of Work chasing that all-important signature! 

Plus as it’s at the start, you don’t truly know what’s needed as the project has to begin.

So the key to delivering a successful project is defining project deliverables that are clearly understood, bring value to the recipient and are achievable. 

A project deliverable can be many things for example; 

  • A report 
  • Working software 
  • Delivering a workshop 
  • Hardware 
  • A project plan 
  • Designs 
  • Documentation 
  • A training plan

Depending on the project methodology, Waterfall or Agile or something similar, the level of planning and tracking my differ when defining the deliverables. This post focuses more on projects that require more detailed planning with deliverables that are less likely to change.

What is the Difference Between Milestones and Project Deliverables?

A milestone is a target that must be met by a certain time, or a significant activity that is happening within the project timeline.  

For example, 

A board review meeting or the review of the training plan with the project’s stakeholder.

Milestones can form part of a deliverable if the deliverable is broken up into multiple parts. For example, if your deliverable is to create a training plan, it could be split up in the following way.

  1. The training plan structure is agreed by all parties involved 
  2. The training plan content is created and agreed 
  3. The training plan is presented back to the project’s stakeholders
  4. The approved training plan is delivered to the project’s stakeholders

Use milestones to help you move towards completing the project deliverables, but they’re not always directly related to a deliverable.

How to Define a Project Deliverable

To define a project deliverable, you have to ask a number of questions. Depending on the complexity of the deliverable and who you need to create it, getting the answers to these questions will vary in the time needed and the approach to get them.


Deliverable Checklist.png

No matter how well you think you know the answer to these questions, never make any assumptions.

Clarify and discuss each one with the relevant team members and stakeholders. 

Document this information and talk it through with the deliverable recipient so they’re fully aligned with the work being completed.

How to Track a Project Deliverable

When tracking a project deliverable, don’t do it in a silo as often project deliverables have interdependencies.  

As a team, review all the deliverables together as in some cases you’ll also find they’re closely linked and dependent on each other.

Plan them out in a logical order with the team delivering them to feeding into the work required to deliver each one. 

Make sure you book regular reviews with the internal and external stakeholders as well as the team.

Your internal stakeholders are critical to catching anything that may have been missed, provide suggested improvements and share potential questions that the external stakeholders may ask.

The first time a stakeholder gets to see a deliverable should not be when the project is finished

Regularly ask the team how they’re progressing towards the next project deliverable asking questions like;

  1. Are you still on track to finish deliverable X
  2. Is there anything that could stop you from finishing deliverable Y
  3. Have you made any assumptions on what’s needed?
  4. Do you have any questions or concerns?
  5. Do you need any help?

By using these prompting questions, it keeps the team thinking ahead and over time, the team start coming to you rather than you having to ask.

Managing Project Deliverables when Closing a Project

The majority but not all project deliverables are finished and shared at the end of the project. 

Wherever possible, you should have a completion date that is before the final day of the project. This is because the workload always increases towards the end of the project, so you need to plan for this.

When planning your deliverables timeline, not only plan them in a logical order but also take into consideration the workload for the team members involved. 

For example. 

As a Project Manager, you’ll need to have some involvement in the final reviews and handover, if these all fall on the same day, you’ll be stretched too thinly. 

Or do the project team have any other commitments, holidays, other projects, training etc.?

As you move closer to the deliverable deadline, use this as an opportunity to remind the recipients of the deliverable on what to expect. 

You would have hopefully had interim reviews and check-ins, but even with these its good practice to share the overview of the deliverable a few days before delivery.   

Cover what it is, the delivery date, format, who’ll be sending it and reasons for creating it. 

There are two reasons why this approach works well. 

  1. It helps prevent unplanned changes or misunderstandings upon receipt. Even if the recipient would like to make changes, they’re less likely to ask for them as the communications on what they’re getting have been regular and clear. 
  2. It highlights any acceptable small changes or information that maybe be required or needed ahead of time. For example, can you make sure you Cc: X stakeholder, or please can you add the additional detail of a particular decision we made as this will help with the final acceptance tests. 

Essentially, anything that creates a smoother delivery for you and the team.

What happens when you can’t complete a Project Deliverable 

Not being able to meet an agreed deliverable due date happens and in some cases, there is nothing you can do to prevent this even with all the planning in the world. 

For example 

  1. Key team members are sick, and you don’t have anyone to replace them or at least not immediately. 
  2. The client hasn’t upheld their responsibilities required to allow you to meet the agreed timelines. 

There are other examples of reasons why a deliverable might not meet the due date, where increased planning and communication is needed.

  1. The work planned has taken longer than expected 
  2. The deliverable agreed at the start no longer offers value for the client or the project

This is where being very transparent with your client works best, as in most case a reasonable client will understand if given the right information at the right time.

Too often, project teams try to hide the information scrambling for workarounds and reasons other than the truth for why a deliverable can’t be met. 

Creating Good Relationships

You need to develop good relationships with the client with all of the project team and not just the Project Manager. Make sure they get to know the team, so they can see the value everyone brings and put a face and a name to the role in the contract.

When there is an issue with the team like sickness, when the client knows the individual they’re more likely to show empathy and understanding.

Open Communications 

Make sure you have a regular and open dialogue on progress during the project with your client. Then as they see the progression throughout, and when an issue occurs, it’s not such a major shock as they have been involved in the work to date. 

Collaborative Decision Making

Involve the client in the decision making on what to do next if a deliverable cannot be met. Rather than thinking you need the perfect answer, discuss the options with them and make them part of the decision process. 

Through the team relationships you created, the open communications you have in place, the client, is far more likely to think logically and with some sympathy to help you to get to a new plan that works for everyone.  

The Bottom Line

Being a Project Manager is tough, especially when the project is struggling to meet its pre-agreed deliverables. 

The sole responsibility should never be on the Project Manager though, work with the team and client continuously keeping the communication and collaboration high.

The more you work on the team and client relationships, the more likely your project will be a success, or when you do have problems you know you’re not alone and have the people around you to solve it together.  

Ben Willmott
Founder
Ben is Delivery Director at the London based creative agency Wunderman Thompson where he creates bespoke ways or working for his clients and teams. Ben is also the founder of The PPM Academy specializing in coaching Project Management, Agile Delivery and how to be more productive at home and work.

More Blog Posts

Project Management

Using neutral thinking to increase performance”

There have been so many times when I wished I had used neutral thinking as a Project Manager. ⁠⁠The most obvious is getting a crappy email from a client or a not particularly helpful teammate or manager, and I’ve sent an angry or defensive reply straight away.

Read Article
Project Management

How to turn a problem into a solution and keep your client happy simultaneously.

No one likes a problem, and in some cases, the fix needed cannot be done for some time but with a client demanding change, this can be difficult to manage.Whether you work in an agency or client side, it doesn’t matter. Managing expectations is problematic as to get the expected solution; you might be held back by a lack of knowledge/skills, capacity in the team or just the budget or approval to do it.

Read Article
Project Management

The Power of the Checklist!

There are two types of checklists. The Process Checklist which removes the thinking, so you can do repetitive tasks faster, maintain quality standards and be consistent in everything you do. The Outlier Checklist which covers actions you might need to do, think of, and check but not consistently.

Read Article

Interested in the coaching programme? Book a FREE 1-2-1 Consultation With Ben Willmott, (subject to application)