Work breakdown structure (WBS)

Revision as of 13:19, 21 February 2021

Abstract

Work Breakdown Structure (WBS) is a method within project management aiming to structure and divide a project into smaller and more manageable components. This will make it easier to organise the work that has to be done in the project, and it will also make it easier to assess the time constrains of the project as well as the total costs. The process of creating WBS is performed once, at the beginning of the project, or at predefined points in the project, and the key benefit of the process is that it provides a framework of what has to be delivered ^[1]. This will support the project manager by creating an overview of the different steps and sub elements of the project, the work that has to be done, as well as providing an overview of the different resources, costs and time constrains involved in the project, ensuring better control with the project as a whole.

WBS is a hierarchical decomposition of the total scope of the work that has to be done in the project carried out by the project team to make the required deliverables in order to accomplish the project objectives ^[1]. This is represented geographically in a hierarchical tree showing the different sub elements of the project work. In the context of the WBS, work refers to work products or deliverables that are the result of activity and not to the activity itself ^[1]. This means that the hierarchical decomposition of the scope of work represents the actual deliverables throughout the project, e.g., a product, service, or data, and not the activities that lays behind in order to reach these deliverables.

The concept of WBS – why and how to use it

WBS is a planning tool with the purpose of assisting project managers in creating a clear overview of the work within a project. This is done by sub-dividing a project into smaller and more manageable parts, in terms of the creating an overview of the different steps of work that has to be done in order to achieve the overall goal of the project. This provides a better control with the project as a whole, as sub-dividing the project into smaller parts also provides an overview of the different resources, costs and time constrains involved in the project. The Practice Standard for Work Breakdown Structures outlines some of the key benefits from performing WBS as ^[2]:

• Better communication to project sponsors, stakeholders, and team members
• More accurate estimation of tasks, risks, timelines, and costs
• Increased confidence that 100% of the work is identified and included
• A foundation for the control processes within the project.

This means that Work Breakdown Structures are a key component in project management within the planning of the project as it organizes the project’s scope by reflecting the work specified within the project. ^[2]

Definition of WBS

As with many other concepts in Project Management, there are more than one definition of Work Breakdown Structure (WBS).

The PMBOK Guide – 6th edition defines WBS as: ‘’The WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. The WBS organizes and defines the total scope of the project fines the total scope of the project and represents the work specified in the current approved project scope statement.’’^[1]

PRINCE2 defines WBS as: ‘’A work breakdown structure is a hierarchical breakdown of the entire work that needs to be completed during a plan; in PRINCE2 a work breakdown structure contains only activities’’. ^[3]

The biggest difference in these two definitions, or approaches to WBS, is that in PRINCE2, a work breakdown structure contains only activities. This is different from the approach in the PMBOK Guide, where ‘’work’’ refers to work products or deliverables that are the result of activity and not to the activity itself ^[1]. Despite this difference of the definition of WBS, both uses of the terminology agree that project managers need to plan by breaking down the products or outputs of the project first and then break down the activities needed to produce the products ^[3]. This article mainly assess the approach to WBS as defined in the PMBOK guide.

Tools and techniques

In this section follows a general overview of how to create WBS followed by a more detailed description of key elements. The process of creating WBS can in general be described as shown in Figure 1: ^{[1] [4]}

FIGURE TEXT

First step of creating WBS is gathering critical project documents including a project management plan including the scope plan. Other examples of project documents that can be needed as inputs are the project scope statement or requirements documentation. In this step it is also important to identify organisational process assets that can influence the WBS, such as policies, procedures and templates for the WBS within the organisation, project files from previous projects as well as lessons learned from previous projects. ^[1] All of these inputs will be the starting point and foundation of creating WBS.

After having gathered all of the needed inputs in order to create WBS, the documents must be analysed in order to identify key elements of the WBS. Here it can be useful to involve expert judgement from individuals or groups with knowledge of or expertise with similar projects ^[1]. From the analyse the level 1 elements can be defined. Level 1 elements are the overall deliverable of the project – the summary deliverable descriptions that must capture 100% of the total project scope ^[4]. This is the starting point of the WBS, and therefore it is important to verify that 100% of the project scope is being captured in the level 1 elements, which is often described as the 100% rule. Now the decomposition of the project scope can be made by breaking down the level 1 element into lower levels of sub-elements. When it is no longer possible to sub-divide any elements in order to make the project more manageable, the WBS is done. ^[4]

Decomposition

The decomposition is one of the key elements of creating WBS, and this step is where the actual breaking down of work structure is happening. The PMBOK Guide defines decomposition as: ‘’ Decomposition is a technique used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts’’^[1]. There is no single answer to how detailed this decomposition of the project scope should be. It depends on the degree of control needed to manage the project successfully and is thereby something that varies with the size and complexity of the project. ^[1] This also means that the sub elements of the WBS are not necessarily decomposed to the same extend. It all depends on the context of the problem where in some projects it may be helpful to decompose every element of the WBS to the same extend, it may not be necessary to do in other projects. This means that decomposition is use-related and defined by the context of the project of which the WBS is made for.^[2]

The PMBOK Guide has defined some general steps of activities involved in the decomposition of the total project work into smaller work-packages as listed below ^[1]:

• Identifying and analyzing the deliverables and related work
• Structuring and organizing the WBS
• Decomposing the upper WBS level into lower-level detailed components
• Developing and assigning the identification codes to the WBS components
• Verifying that the degree of decomposition of the deliverables is appropriate

Identifying and analysing the deliverables and related work is the first step in creating the WBS as this will be the content of work which the WBS must include. After this is done, the structing and organizing of the WBS can be done. There are different approaches on how to organize the WBS. Often it is done by using a top-down approach, using specific guidelines within an organization or by using predefined WBS templates. ^[1] The WBS is organized in different levels as illustrated in the Figure 2 below:

FIGURE TEXT

The Figure shows the overall structure and organization of the WBS. On the figure is shown 3 levels of the WBS – this is only illustrative, as the number of levels as well as elements and sub-elements in a WBS is again dependent on the context, size and complexity of a project.

Level 1 is always defined as the overall deliverable of the project – the project goal. What is defined in the following levels can be represented in various forms. The PMBOK Guide presents two examples of WBS structure, the first being using phases of the project life cycle as the second level of decomposition, with the product and project deliverables inserted at the third level or directly using major deliverables as the second level of decomposition ^[1]. Regardless the use of WBS structure, the key feature of WBS is that it is a hierarchal representation that provides a clear overview of the objectives and deliverables of the work to be performed within the project scope, by sub-dividing the work for each of the elements, that being the deliverables or subcomponents representing products, services or results, into its most fundamental WBS component. ^{[1] [2]}

The Figure also illustrates the point that the different deliverables, in terms of WBS elements, may have different levels of decomposition. Sub-dividing an element into multiple sub-elements and increasing the level of detail may result in greater ability to plan, manage, and control the project. On the other hand, too much level of detail can result in non-productive management effort, inefficient use of resources, decreased efficiency in performing the work, and difficulty aggregating data over different levels of the WBS.^[1] Another aspect of organizing and structuring the WBS is by using ‘’rolling wave planning’’. This approach is used when deliverables or sub-components of the WBS may be completed far into the future, and therefor it is not possible at the given time of the WBS planning to have enough details regarding the deliverable. In this case, the project management team will usually wait until the deliverable is agreed on, so that the details of the WBS can be developed correctly. ^[1] Developing and assigning the identification codes to the WBS components amplifies the overall structure of the WBS making it easier to group and identify the coherence of the different elements of the WBS, making it easier to structure and manage the project planning process.

The 100% rule

Another key feature of WBS is the 100% rule. The 100% rule asserts that the WBS includes 100% of the work defined by the project scope in terms of representing all product and project work including project management work. The rule states that the total of the work at the lowest levels should add up to the higher levels of work ensuring that nothing is left behind or, on the other hand, that nothing is included in the project that should not be included. The 100% rule is illustrated in the Figure 3 below:

FIGURE TEXT

As seen in the figure, the rule applies at all levels of the WBS, meaning that the sum of the work at the ‘’child-level’’ must be equal to the work represented at the ‘’parent-level’’. ^[2]

Application

In the following section, an example of WBS is made for the construction of a house. The WBS is only illustrative, as the purpose is to explain how to make a WBS in a clear and simple way. This means that the content of WBS may not be 100% accurate according to how to actually construct a house, and it may not content all of the required elements of the construction process, but it gives a clear vision of the process of making a WBS which is the purpose of this article.

Example of application of WBS

As mentioned earlier, there are no ‘’correct’’ way of making a WBS – it all depends on the context and complexity of the project as well as organisational factors on how WBS is usually made within the organisation. Despite this, there are still some key elements that can be applied in every WBS regardless of the project, as well as an overall hierarchal structure of elements and sub-elements within the project that characterises a WBS.

The Figure below shows an illustrative example of a WBS for the construction of a house. The figure is inspired by similar figures from the handbook Project Management Institute. “Practice Standard for Work Breakdown Structures”- Second Edition, 2011 and examples from www.workbreakdownstructure.com. The WBS example of the construction of a house could be further developed by decomposing the different elements into even more detail, but as the need for this is dependent on the specific project, it will not contribute further to the understanding of the principles behind creating a WBS.

FIGURE TEXT

The WBS represents the scope of work required in the construction of a house. In the WBS, the different levels of the hierarchical structure of the WBS is represented with the four different levels. At level 1, the overall scope of the project is represented – the final product and goal of the project – the finished house. At level 2, the detail level of the WBS is still quite general, though it is differentiated within the four different common aspects of the construction of a house. This also illustrates that behind creating the WBS lays an analyse of how to actually build the house, which elements are included and needed, and also expert knowledge of how processes are grouped and interlinked within the construction process. The WBS also shows that the detail level of the WBS increases with the levels of the WBS. It also illustrates that not all elements of the WBS are decomposed to the same level of detail – it depends on the different control needs within the project.

The WBS also illustrates the ‘’child-parent’’ relation between the different elements and sub-elements, and that child elements includes 100% of parent element. In the figure, the hierarchical code scheme of identification codes for the different WBS elements are also represented. The purpose of these are to easily identify which group of work the element belongs to, and it also clarifies the ‘’child-parent’’ relation between the different elements of the WBS. To increase the foundation for control in the project in terms of proving an overview of the total cost, budget estimations can be added to the WBS. By doing this, the WBS both provides an overview of the work that needs to be done in the project in terms of the deliverables within the project, how these are interlinked and dependent on each other, the amount of work within each deliverable as well as the distribution of the costs throughout the project. This all adds to the benefits of why to create the WBS which general purpose is to support the project manager by creating an overview of the different steps and elements of a project as well as costs and constrains involved in the project, ensuring better control with the project as a whole.

Limitations

Even though the benefits of creating a WBS are various, there are still some limitations within creating a WBS which the project manager should be aware of. First of all, it is not possible to create a WBS which is 100% accurate. The WBS is providing a general overview of the project, and no matter how many levels of detail that is incorporated in the WBS, it will always only be a representation of the expected reality of the work within the project, as it is impossible to include every single aspect of especially big projects. Having too many levels of detail within the WBS can also be a limitation, as this can lead to confusion and lack of clarity within the project. Furthermore, the components of the WBS should only be the deliverables of the project and not the activities that lays behind these deliverables ^[1], as these can change a lot during the project – this also being one of the reasons that the WBS cannot replace the project plan or schedule. Creating a WBS that is not deliverable-oriented is also one of the most common mistakes when developing a WBS. Projects are often function-based, and therefor is can seem natural to incorporate activities or functions within the WBS, which should be avoided. ^[5]

Annotated bibliography

MANGLER

References

1. ↑ ^{1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 1.13 1.14 1.15 1.16} Project Management Institute,(2017). A guide to the Project Management Body of Knowledge (PMBOK guide). 6th Edition.
2. ↑ ^{2.0 2.1 2.2 2.3 2.4} Project Management Institute,(2011). Practice Standard for Work Breakdown Structures. 2nd Edition.
3. ↑ ^{3.0 3.1} Project Management Institute,(2017). Managing Successful Projects with PRINCE2. 6th Edition.
4. ↑ ^{4.0 4.1 4.2} https://www.workbreakdownstructure.com/
5. ↑ NASA,(2010). Work Breakdown Structure (WBS) Handbook.