The project manager should always be in control of the scope by applying rigid management of the requirements, details and processes. All scope changes should be handled in a structured, procedural and controlled manner.
Good scope management focuses on making sure that the scope is well defined and clearly communicated. The overall goal of scope management is to define the need, set stakeholder expectations, deliver against these expectations, manage changes, and to minimize surprises so that the product will be ultimately accepted.
The definition of project scope is the work needed to successfully complete the project and only that work. It is important not to exceed customer expectations and “gold plate” their specifications as this increases risk and potential problems.
The requirements are the primary means of understanding and managing stakeholder expectations, so scope management will have a significant impact on project success.
The main deliverables from this process are:
This process leads to the understanding of what is needed to satisfy the stakeholders and the main outputs here are the requirements documentation, and the requirements traceability matrix.
The former is a document describing what needs to be performed and why each requirement is important on the project. The requirements traceability matrix identifies the source of each requirement which could be a stakeholder, a departmental request, the legal or contractual need, or any other number of sources.
The scope of the project must be understood and documented in detail so that a clear understanding of the requirements is developed. This process is where the project requirements are thoroughly understood and documented, and should be carried out as soon as the collect requirements process has been completed.
The project manager refines the requirements that have been collected by performing additional analysis while factoring in any approved changes, and adding detail. The main output of this process is the project scope statement.
The project scope statement is to document used as a baseline reference point for aura of the project stakeholders. The project scope statement contains details such as:
The work breakdown structure is the source of information for creating the rest of the project plan. All the risks, activities, costs, quality attributes, and procurement decisions tie back to the WBS.
The main product of this process is the work breakdown structure and the main output will be the scope baseline. The scope baseline represents the combination of the project scope statement, the work breakdown structure, and the work breakdown structure dictionary.
The main tool used in the process “create WBS”, is decomposition.
This involves breaking down the project deliverables into progressively smaller components. You could go too far here, breaking the nodes down to a minute detail, but this would waste time and make the project difficult to understand, manage, and change.
So, the key to creating a sensible WBS is to answer the following questions:
Are your work packages small enough to be estimated for time and cost?
PMBOK is clear, the work breakdown structure must always be based on the project deliverables, rather than the tasks needed to create those deliverables and that’s the WBS should be built or designed from the top down:
The work breakdown structure is created by the decomposition of breaking down the deliverables consisting of product features, characteristics, or attributes, into progressively smaller pieces. This process continues until the deliverables are small enough to be considered work packages.
The lowest node on a WBS can be considered a work package when it meets the following criteria:
While the main product of this process is the work breakdown structure, the main output will be the Scope Baseline.
The WBS dictionary is a document that details the contents of the WBS. Because the WBS is graphical it cannot show all the information regarding each node, so the dictionary solves this problem by capturing additional attributes about each work package.
Such additional information might include a unique node number, the name of the node, the written requirements for the node, who is responsible for carrying out the work, along with time, cost, and account information.
Once the scope baseline has been created, it can be used to decompose the work into activity level, resulting in the activity list.
The activity list is created by taking the WBS and decomposing the work packages even further until may represent schedule activities. The difference between a work package and an activity list, is that the activity list is more granular and is decomposed into individual schedule activities:
From this you can see that a work package will often contain bundles of related activities that may involve multiple groups of people.
Each work package at the bottom of the WBS is decomposed into smaller pieces known as schedule activities