Deliverables & Boundaries
The aim is to create a sufficiently detailed definition of the project scope to achieve a clear-cut completion and set up a framework for the planning work ahead. Two things define your project scope:
Deliverables - what is inside the project
Boundaries - what is outside the project.
Without a precise specification of the scope, the risks are high that the more work progresses, the more work there is to be done. Requests will be made for new deliverables. There will be an outcry that these must be included, and the project will start sprouting in all directions. An updated list of deliverables and boundaries is therefore essential for project success.
However, some deliverables will be removed during the project, new will be included, and boundaries modified. These changes will all affect time, cost, and resources. Therefore, large changes to the scope may be a reason for renegotiating project time, cost, and resources.
A project is a temporary organization formed to produce a defined number of deliverables. The project is completed when all the deliverables have been produced and approved (verified) by their approvers (customers). Deliverables are usually physical objects and are formulated as nouns.
Every deliverable is defined by:
Number – its unique identification
Deliverable – what is to be produced, delivered, and approved
Approver – who is/are the approver/s for the deliverable
Verification – how is the deliverable to be approved (verified)
Responsible – who is responsible for the deliverable. Always a member of the team and preferably from the core team.
Use Standard notes smallest size in the template
Deliverables should be defined within all project dimensions. For dimensions, see the information on “Overall plan.”
A deliverable is finished and completed when it has been approved. Being clear on this point avoids countless discussions during the project and paves the way for a clear-cut ending of the project.
For example, a deliverable can be approved by:
meeting specific requirements or tests
the approver signs a document
the customer settles an invoice
a picture is taken of a prototype
minutes from a meeting
an email from the approver.
A boundary is usually a deliverable that the project will not produce, but it depends on it to reach the goal. These could be things that need to be made by the line organization or outside suppliers not controlled by the project.
It is crucial to list boundaries where the divergence from company praxis is made.