Work Breakdown Structure (WBS)
In my previous article, I showed how to collect requirements and define scope, and this PMP process is the next one in the logical sequence. As soon as the project has been defined and the requirements documented, then creating the work breakdown structure(WBS) is the next step.
PMBOK calls the WBS the ‘hub of information’ for project and should be seen as the cornerstone component of the project plan, as it is used to identify the activities, costs, quality attributes, risks and procurement aspects within the plan.
Equally important is that you should see the WBS as the primary source for first verifying and then controlling the project scope.
Referring to the map of sequence between the process groups and knowledge areas, then this particular process is within the first three that need to be done, and forms part of the scope knowledge area.
There are three main sets of information that are used as an input to the create WBS process:
Project scope statement. This is the prime input as it describes the full scope of the project in detail and can hence the expanded in order to create the WBS
Requirements documentation. This is a key document because it links each requirement back to the specific business need or business benefit.
Organisational process assets. Although these are many and varied, the most useful and applicable to creating the WBS, would be reference to any project methodologies describing how to create a WBS. Also any WBS templates, or examples from previous similar projects. Other assets may be the use of software tools needed to create the graphical WBS diagram. For example, even tools such as Microsoft project have an outline view which can stimulate the work breakdown structure and lead to the next steps of defining the activities.
Now let us look at the four outputs of the create WBS process:
Work breakdown structure.
Despite its name, the work breakdown structure is really a product breakdown structure, because current best practice of shows that first the products or deliverables should be identified, and only then, determine the activity is necessary to create such products.
A useful approach here is to remember that the product or deliverable would be described by a noun or outcome, whereas an activity would typically be a noun and verb. An example here would be ‘installed cabling’ or ‘new help desk’, whereas activity examples would be, ‘create report’ or ‘design software’.
However, using the words WBS, this will consist of a graphical, hierarchical chart that is logically organised from the top downwards. Each ‘node’ on such a diagram, could be considered as a work package, and consists of a unique alphanumeric (or just numeric) code to uniquely locate and identify it.
A useful way to create such a WBS is to book a room with all key stakeholders who can contribute, and use Post-It notes to create the nodes. This is a very creative and efficient way of ensuring that the complete and accurate WBS diagram is created aligned to the project scope.
The discipline and rule, is that if it is not on the WBS, then it isn’t within the scope of the project.
The value of an accurate and complete WBS is that it helps clarify where each piece of work fits into the project, goes on to define activity responsibilities, and is an important communication tool due in particular to its easy to read graphical layout.
The manner in which a WBS is created is via decomposition, which consists of breaking down the product deliverables into progressively smaller and hence lower nodes on the WBS. The approach here is to continue until the deliverables are small enough to be considered as a work package entity.
As a guide, a work package is considered small enough when it can be estimated for work effort, cost, and time. Additionally, a clue is that such a work package need not be composed any further, or that it may be assigned to a single person.
Each sub level accurately and completely rolls up to the level above it.
Here is an example of part of a simple WBS:
In order to create an accurate and complete WBS, it is important to ensure that each node is mutually exclusive with no gaps or overlap in each of the work packages. Put simply, there are no duplication’s, and the WBS covers every part of the project scope.
Notice also, that reading from the top downwards, the WBS diagram indicates products or deliverables, but as these are decomposed downwards, they will depict activities.
The WBS diagram itself has limitations as it is not practical to capture all the node information on the diagram. This is where the WBS dictionary plays a part, as it allows any additional information or attributes for each work package to br csptured as a different document that points, or refers, back to the WBS. Put simply, the WBS dictionary provides detailed information about the nodes within a WBS.
Here is a simple example of a WBS dictionary for an individual node:
The scope baseline.
The term baseline, is derived from the world of configuration management, and as such, a baseline may represent any agreed set of information at a certain point in time. The key understanding here is that whenever a baseline is created, it is placed under change control, meaning that no changes can take place without the right authority and that such changes have been made according to the scope management plan.
There are four baselines contained within the project management plan; the scope baseline, the schedule baseline, the cost baseline and the quality baseline (although the latter is not explicitly stated within the sections of the project management plan).
An important PMBOK definition here, is that ‘a baseline is the original plan plus all the approved changes’.
In the case of the scope baseline, we are referring to the combination of the project scope statement, the WBS, and the WBS dictionary.
Project document updates.
As in many of these processes as a result of carrying them out, the general understanding and detail of the project is refined and improved causing the need to update existing project documentation. An example here is that it is highly likely that new or modified requirements will be identified, needing an update to the requirements documentation that had previously been created.
There is one main tool used in order to create the WBS:
As you might expect, the term of decomposition describes the breaking down of the project deliverables into the smaller activity based elements. As I have already mentioned, the top layers of the WBS normally represent products or deliverables, but as each lower level is identified these will describe the activity nodes rather than product nodes.
One of the major techniques used in estimating for example, is to take larger complex pieces of work and break them down into smaller chunks, then estimating such chunks in terms of work effort so that these can be aggregated to provide an accurate estimate of the larger complex piece of work. The same is true when creating a WBS, that is, lower nodes on the WBS, must sum up to those above them.
Like all things in life, there is a balance required here in creating your WBS, and it can be tempting to decompose down to an over-detailed level. This adds unnecessary complexity, causes this process to take longer than is actually needed, and makes the project unnecessarily complex both to plan and manage.
A rule of thumb here, is the commonsense one, of checking that the level of detail is adequate in order to provide sufficient information at an activity level, and is small enough to be estimated for time and cost.
If you need help to get the PMP Exam results you deserve, then CLICK HERE
David spent 25 years as a senior project manager for US multinationals and now develops a wide range of project-related video training products under the Primer brand. In addition, David runs training seminars across the world, and is a prolific writer on the many topics of project management. He currently lives in Spain with his wife Jude.