Table of Contents |
Project deliverables are the outcomes that are the focus of the project, and all work is targeted at creating deliverables. A project might have one deliverable, or it might have many interrelated deliverables.
IN CONTEXT
You are a project manager within an organization that creates a watch with tablet computer-like functionality. It is your responsibility to list all deliverables that must be created by the time the project ends.
The watch itself is, of course, a deliverable. However, a prototype watch might also be a deliverable. The software that runs on the watch is likely a deliverable too. Documentation on the operation of the watch will almost certainly be a deliverable. Users need to know how to operate the product.
As the project manager, it's also your responsibility to note which deliverables won't be created by the project. In this case, perhaps sales and marketing are not a deliverable.
Project requirements are essential elements that define the specific features and capabilities necessary for the successful completion of a project. These requirements emerge from the project’s goals, objectives, and stakeholder expectations. While some objectives may lead to a single requirement, most projects involve multiple requirements.
A project requirement is very specific about what must be accomplished. It is the criteria to determine if this work is a success. The requirements set the quality standard for evaluating the project's success.
EXAMPLE
Consider this project requirement:Remember, project requirements play a crucial role in shaping the project’s outcome and ensuring its alignment with stakeholder expectations.
Project managers must also document project assumptions made about a project or it's deliverables. These also emerge from reviewing expectations and consulting stakeholders.
Assumptions are different than expectations in that assumptions are assumed to be a true prediction of the future. Expectations will only occur if the project delivers on its work.
EXAMPLE
An assumption on the tablet watch project might be that the project may assume that the existing tablet development team will contribute three software engineers to the tablet watch team.Assumptions can be made about nearly anything assumed to be true and applicable to a project, such as the resources available for work, the accessible technology, or the support organizations or individuals might provide a project.
Project managers will need to use discretion to determine what assumptions are listed so as not to be too detailed. If there is a chance that a false assumption is a risk to the project, then that assumption should be included.
Deliverables and requirements are then used by the project manager to determine what work is in scope and out of scope for a project. In scope means the project is responsible for the work. Out of scope means that it is not. In other words, what the project will do, and what it won't do.
It's simple to understand why we document what a project will do. But why document what it won't do? Successful project managers do this because projects and deliverables are complex; it's difficult to gather 100% of the stakeholder expectations.
EXAMPLE
Regarding the tablet watch, in scope may be the capability to make and receive phone calls. Out of scope work might be the ability to take photos.Discussing what won't be a deliverable opens up the opportunity to gather information about expectations. By stating what is in and out of scope, allows stakeholders to review and discuss, should there be any disagreement about what is in and out of scope. This is how outcomes are determined.
Source: This work is adapted from Sophia author Jeff Carroll.
