The last post, How to know the project is done, covered 4 principles that could be used to help ensure that a project delivered the required outcomes. One of the principles being the use of a Deliverables Tracker to monitor and store key project outputs.
This post will expand on the practical components of the Deliverables Tracker.
Before you start
It is important that the project managers have taken the time to define the deliverables for the project. If not, it will be nearly impossible to populate a Deliverable Tracker. However, while this is in progress, you can create the template to capture and track the deliverables.
The Deliverable Tracker is simply a log of the deliverables that must be completed for each project. A simple solution is to use a spreadsheet application such as Microsoft Excel as this will allow the filtering and searching of data. It is also possible to build more sophisticated trackers using applications such as SharePoint. This will then allow the automation and integrated storage of deliverables.
Key Data Points
The following gives an overview of the data fields you should capture within your Deliverable Tracker.
Each deliverable should be assigned a unique reference. This will help make it easier to search for a specific deliverable, especially if the tracker contains deliverables for multiple projects and programmes. It will also help the traceability back to the original requirements.
Aim to use the same unique ID as what is used by the project. This will eliminate the risk of confusion and the need for cross reference tables.
Work Breakdown Structure (WBS)
It is good practice to use a WBS when structuring project plans. Therefore, you may wish to capture the WBS that has been assigned to a deliverable. However, take care when tracking multiple projects as there may be a risk that the same WBS may be used across different projects.
You can even consider using the WBS as the Unique ID if there is no risk that there will be duplicates.
This should be a clear and concise description that details the deliverable. It should allow for anyone to understand what is being delivered without having to refer to the underlying project. This is also useful if part of the process is for an independent review of each deliverable against the tracker.
Business / Function
For a large organisation you may wish to include a field to indicate what area of the organisation owns the deliverable. This will then allow the data to be filtered to create specific reports I.e view of deliverables for specific business. You may wish to have separate fields for each if it is possible to have Functions within a Business.
Region / Country
This allows for data to be filtered to give reports based on Country or Region. Again you may wish to use separate fields to allow better filtering and report production.
Project / Programme
If the tracker is being used for multiple projects, this field will allow the filtering by project.
This should be the ultimate owner for each deliverable. This is the person responsible for the final sign-off and acceptance of the deliverable. The deliverable should not be marked as closed unless it has been signed off by the owner.
Baseline Completion Date
In order to track progress, it is important to capture a target date for each deliverable. This will then allow the tracker to be filtered to highlight those that are past the due date so that action can be taken.
Actual Completion Date
This will capture when the deliverable has been completed. This is important so as to provide an audit trail if any questions come up in the future.
This field allows for progress to be captured. For example, it is good to know that the deliverable has been started as this will give more confidence that it will be completed by the required date. Likewise, it will allow for reports to be generated where deliverables have not been started but due in next 4 weeks, they may need attention.
This can be used to indicate if the deliverable is on track or not. While this is similar to Deliverable Status, it is useful for providing simple reports where each deliverable can be shown with the RAG status. Then the ones that are Red can be prioritised.
Using the above to construct a Deliverable Tracker will help you monitor progress and allow analysis of data to focus on exceptions. It is also a good idea to consider developing exception reports that are generated on a regular basis to send to the different owners. This helps propmt action by effectively delivering a “to do” list to each area.