Once you have a complete understanding and appreciation of your project requirements,
including the acceptance criteria, you will have the foundation to produce your work breakdown
structure
Before progressing to the work breakdown structure you need to define the scope of the project
from the project requirements and charter. The scope document provides a detailed description
of exactly what your project objective is, its deliverables, exclusions, and acceptance criteria.
On completion of your project scope statement you can begin to focus on the detailed aspects of
your planning and communications. A key part of any project is planning and anticipating
request for changes, your scope must describe how you will handle such requests.
Your project scope statement also defines the project teams roles and responsibilities, allocating
a specified individual per role, as well as the level, format and circulation of the project
documentation and reports.
Now you are ready to produce your work breakdown structure. This breaks down the project
deliverables into manageable portions of work packages that you allocate a unique id to. This is
commonly shown in a graphical form, such as an organizational style chart or a fishbone
diagram.
This process of breaking work down is referred to as 'decomposition' and enables you to estimate
costs and activity with a greater degree of accuracy. These details are recorded in your WBS
dictionary and form the basis of your scope baseline.
his plan will show how you will plan, prioritize, track and report these requirements. It also
documents the policies, procedures and processes that the project must adhere to. In addition it
explains the interactions between functions, service level agreements and their compliance.
Descriptions of any assumptions and constraints are included along with quality, performance,
support and security needs of your project
Once you have your scope you need to gain formal acceptance of the project deliverables by the
stakeholders and on their agreement your project scope is verified. Any changes or alterations
that arise after this sign off of the scope must adhere to your project's integrated change control
process.
The final aspect of verifying your project scope is the description of how the inevitable changes
to the project scope will be controlled. It is essential that you have strict controls over the change
request process, other wise you could suffer from 'scope creep’. This is where unacceptable or
unqualified risks get introduced into your project often causing project failure in one form or
anther. This can be missing key milestones or over spending against your budget.
Work performance data (as shown below) along with the project plan and the requirements
documentation are the three things that you must have to control over your projects scope.