In project management, a deliverable is a product or service that is provided to the customer.
A deliverable usually has an expiration date and is tangible, measurable and specific. It is given to an external or internal customer and meets a milestone or a deadline that is created and produced in the project plan.
There may be one or more deliverables within a single project.
TABLE OF CONTENTS
- Know when a deliverable can be defined as such
- Internal vs external deliverables
- Difference between Deliverables and Milestones
- Project deliverables vs process delivarables
- Process of defining project deliverables
- Collection of requirements for deliverables
- Suggerimenti per la gestione dei risultati del progetto
Know when a deliverable can be defined as such
Deliverables are what drive the success or failure of each project. It is important, therefore, to know what they are and all the different forms they can take.
These measurable results confirm the achievement of the goals of the project. The results also demonstrate the adherence of the team’s work to the project requirements.
However, in the execution of a project, it also happens that some obtained results have little to do with the project itself. It is therefore necessary to have parameters in order to know when it is possible affirming that an output is a deliverable. An output, in order to be classified as a “deliverable” within a project, must:
- fall within the scope of the project
- be accepted by stakeholders – external or internal
- be the result of deliberate work
- have a precise role in realizing the goal of the project
The deliverable can be big and tangible, like a building or a factory, but it can also be small, like a one page document.
The deliverables, on their own, are rarely the final goal of the project, but rather trace the path to reach it.
This is why project managers often focus obsessively on their definition, management and monitoring.
Internal vs external deliverables
A common way to classify the final results is to divide them into “external” and “internal” deliverables. There is a simple way to define them:
- Any work done to satisfy customer requests or to fight competition is an external deliverable.
- Any work done that is not part of the business with customers is an internal deliverable. In short an internal deliverable is whatever is created as part of business management. Keep and monitor accounts, create business documents, etc. these are all examples of internal deliverables.
Difference between Deliverables and Milestones
Another source of confusion for some project managers, especially at the beginning of their career, is the difference between deliverables and milestones.
Milestones are checkpoints during a project and can be inserted at any point. They mark the completion of an important activity. They have no deadlines, but are simply a way to keep track of project progress.
Milestones are created to break down a complex result into its constituent parts.
Moreover, milestones are not meant for customers, but for the internal project team.
Project deliverables vs process delivarables
There is also another distinction to be made when it comes to deliverables: project deliverables vs process delivarables.
The deliverables of the project are the great customer-centered goals we talked about previously.
The process deliverables instead, describe the path that will help to achieve the project results.
All documents created during project management, such as the project scope statement, the project plan, and the work breakdown structure, are documents not addressed to the final customer. However, they are necessary documents for internal stakeholders and for the team in order to better manage the project.
All these documents are examples of process deliverables. Their creation is not the goal of the project itself, but they are fundamental for a successful conclusion.
Process of defining project deliverables
To define the deliverables of the project, it is necessary to have a look at the project goal and ask the following questions:
- What is the project trying to achieve?
- What is the purpose, goal or final result that the customer wants once the project closes?
- What are the constituent parts of the project goal?
- What is the form and function of each of these constituent parts?
- How important is this part for the overall project?
- How will it be possible to create this part?
- What is the cost of production / acquisition of this part?
- How long will it take to produce / acquire this part?
In essence, the goal of the project is being divided into smaller parts and, at the same time, the feasibility and priority of each constituent part is being evaluated.
Collection of requirements for deliverables
The probably most difficult part is defining the requirements for each deliverable. In particular, the requirements specify the criteria that make a deliverable acceptable – or not.
If the requirements are incomplete, customers will inevitably require changes and revisions and this can increase the scope and budget of the project, therefore affecting profits.
For this reason, a fundamental step in the definition of the deliverables is the collection of the requirements.
There are several methods that can be adopted to find the requirements.
Regardless of the tactics used, however, there are some questions that should always be asked:
- Who are the main stakeholders that need to accept this deliverable?
- What are the main priorities for this deriverable?
- Do these requirements fall within the scope and budget of the project? If not, how much additional time / budget is needed?
- Have we created similar deliverables in the past? What were their needs?
- 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 are the minimum quality criteria that this deliverable must meet in order to be successful? How will they be measured?
In addition to the specific requirements for each deliverable, there will also be some “universal” requirements, usually dictated by the best practices followed in the specific sector or organization.
Suggestions for managing project results
By following these simple suggestions, it is possible to simplify the management of the project deliverables:
- Define the deliverables before starting work. The addition of deliverables once the work has already begun could lead to a change in the scope and budget of the project.
- The better the requirements for each deliverable are understood, the easier it will be for stakeholders to accept it.
- Break down the goal of the project in order to discover the key points.
- Involve the interested parties in the project start-up meeting and seek their contribution in defining the final deliverables and their acceptance criteria.
- When collecting the requirements, make sure that they meet the SMART criteria.
- Separate the deliverables into distinct phases to better follow them.
- Identify in advance the metrics and data that will be used to measure the acceptability of each deliverable.
- Identify the deadline for each deliverable.
- Use a project management software to facilitate project tracking and deliverable management.
- Maintain a clear distinction between deliverables and milestones, and between process and project deliverables.
Every project manager must develop his own process to define and manage the deliverables in the best possible way. This will depend on the work style and on the limits and capabilities of the project team.
One way to make deliverable management easier is always to use a project management software.
This will simplify the tracking of the deliverables and make sure they meet the acceptance criteria.