Work breakdown structure (WBS)
Contents |
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 [3]: • 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. [3]
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’’. [2]
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 [2]. 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]
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. [3]
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:
