Work Breakdown Structure – Scope management
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.
Plan Scope Management
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:
- Scope management plan forming one of the 16 components of the project plan. It describes how the scope documents will be prepared and how the remaining scope process is will be carried out
- Requirements management plan defining what activities the team will perform to gather and manage the project requirements
Collect requirements Process
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.
Define scope process
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 product deliverables
- The project goals
- The product description
- The requirements for the project
- Constraints and assumptions
- Scope related risks
- The objective criteria for accepting the product
Create WBS Process
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?
- Is the team satisfied that the current level of detail provides sufficient information to proceed with the subsequent project activities?
- Is each work package small enough to be able to be assigned to a single person or a group that can be accountable for the results?
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:
- The work package cannot easily be decomposed any further
- The work package is small enough to be estimated for time and work effort
- The work package is small enough to be estimated for cost
- The work package may be assigned to a single person (although this may be a cohesive group)
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.
Define Activities Process
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