On the surface, "deliverables" may seem like just another way to say "project result". Until you look deeper. And once you do, you will find that "deliverables" go well beyond the actual results of a given project to also serve as the means by which projects are planned, managed and executed. If you want to be successful, you must be prepared to produce each and every deliverable type - project, process and more.
It Takes Two: Project and Process Deliverables
It takes two (2) types of "deliverables" to make any project happen - the project deliverable and the process deliverable. While each of these varied deliverables serves a specific purpose within the project management process, they also work hand-in-hand, and you can't overlook one for the other.
#1 Project Deliverables = Outcomes
- By definition, projects are initiated to produce specific, unique outcomes based on specific, unique needs (that's how they differ from day-to-day operations). That purpose and need must be expressed in some tangible form, whether it's a product, a process, a plan, a policy, or some other outcome. And that's the deliverable!
For example, in a software development project, the "software code" is the deliverable. In a project to develop and implement a "BYOD Policy" (Bring Your Own Device), the documented policy is the deliverable. The list of examples is endless, but the story is the same - project deliverables are project outcomes. But it doesn't end there.....
#2 Process Deliverables = Realizing the Outcome
- Process deliverables are the means by which projects are planned, managed and executed. In fact, for any given project, it may take multiple process deliverables to produce the type of timely, high quality project deliverables that are expected and required. In simple terms, if the project deliverable is the destination, the process deliverable is the roadmap used to get there. And every project needs it's own roadmap.
By way of example, here are a few of the key process deliverables used to make projects happen (click on the links provided to learn more about each specific deliverable type):
- Project Business Case: The process deliverable used to propose projects.
- Statement of Work: The process deliverable used to define projects and secure stakeholder acceptance.
- Governance Plans: The process deliverable used to define how the project will be managed.
- Project Schedules: The process deliverable used to define the project timeline and allocate the work effort according to reach designated deadlines.
- Project Budgets: The process deliverable used to define and allocate project funding.
- Project Reviews: The process deliverable used to evaluate and measure project results and performance (to discover lessons learned for continuous improvement).
The First Step: What deliverables do you need?
Project deliverables must be identified at the start - when the project is first proposed. As the project moves forward, and deliverables are further defined and specified, the need for one or more related process deliverables will come in to focus. As a whole, this is the deliverables definition process executed via the deliverables decision tree.
The deliverables decision tree (illustrated below) is made up of a series of questions used to identify and define required deliverables – both from a project and process point of view.
Step 1: Deciding on project deliverables.
These are the questions used in order to define the types of project deliverables required for a given project.
- What is the nature, form, function of the planned deliverable?
- How important is it to the overall purpose of the project?
- How will it be produced (and/or acquired) and do we have the capabilities required?
- How much will it cost and is it cost-feasible?
- How much time will be required to get it completed (or acquired)?
- Are there any alternatives to this deliverable and what are the relative advantages and disadvantages of each?
Step 2: Deciding on process deliverables.
These are the questions used to define the types of process deliverables required for a given project.
- What types of process deliverables will be required to complete this project?
- How much time will it take to produce each required deliverable?
- When is each due?
- What formats will be used?
- Who will be responsible for planning, production and implementation?
- Who must accept and approve?
- How will each deliverable be updated and maintained?
Even under the best of circumstances, management is a challenge. When you learn to fast track, you’ll learn to work smarter, not harder. And that’s the value of every lesson, resource and template available at Fast Track Manage Learning. We teach you how to fast track your way to successful projects, committees and more. Learn More
The Key to All Deliverables: Get Them Defined!
You can't deliver something that isn't defined. If deliverables are to serve their intended purpose (whether project or process), they must be properly and fully "defined" so they can be created (or acquired). In short, the deliverables definition process serves the following objectives:
- To specify deliverables in sufficient terms to allow for development, production and/or acquisition.
- To ensure alignment with all known functional, technical and operational requirements.
- To clearly establish realistic stakeholder expectations.
- To secure stakeholder consent and acceptance.
- To form a measureable basis for deliverables testing and review.
To meet these objectives, deliverables must be described in sufficient detail so that actual results are not left to the imagination. Considering the following example, which description tells a better story?
The Project: Technology Asset Inventory Project
Deliverables Description #1:
IInventory report and recommendation.
Deliverables Description #2:
Inventory report documenting the current location, serial number and configuration of all hardware assets, along with a recommended solution for physical asset tagging and inventory control.
To learn more, check out our series of informative articles covering the project initiation process.
Source: Unless noted otherwise, all content is created by and for ITtoolkit.com
ITtoolkit.com staff writers have experience working for some of the largest corporations, in various positions including marketing, systems engineering, help desk support, web and application development, and IT management.
ITtoolkit.com is part of Right Track Associates, proprietors and publishers of multiple web sites including ITtoolkit.com, Fast Track Manage, HOA Board List and more. We started ITtoolkit.com in 2001 and have continued to grow our web site portfolio, Toolkit products, and related data services. To learn more, visit us at Right Track Associates.