Work Breakdown Structure in Project Management
(→Summary) |
|||
| (46 intermediate revisions by one user not shown) | |||
| Line 1: | Line 1: | ||
== Abstract == | == Abstract == | ||
| − | Project Management is often a complex process involving various teams, stakeholders and different development approaches. Therefore, structured planning of the whole project work is important in order to reach the delivery of the result within time and dedicated budget. Since each project is different complexity wise, uncertainty in early stages of some projects can be expected. In order to reduce the project uncertainty it is important to break down the complex tasks into manageable sub-tasks of the whole project (PMBOK; Seventh Edition, 2021, p. 81)<ref name="one">Project Management Institute. “A Guide to the Project Management Body of Knowledge (PMBOK)”- Seventh Edition, 2021, p. 81</ref>. This Wiki article will focus on the Work Breakdown Structure (WBS) method used to reduce the complexity of a project by delimiting the whole project plan into manageable sub-tasks on different levels. Furthermore, the wiki article will cover context and history of WBS along with application and limitations of this method. Lastly, | + | Project Management is often a complex process involving various teams, stakeholders and different development approaches. Therefore, structured planning of the whole project work is important in order to reach the delivery of the expected result within time and dedicated budget. Since each project is different complexity wise, uncertainty in early stages of some projects can be expected. In order to reduce the project uncertainty it is important to break down the complex tasks into manageable sub-tasks of the whole project (PMBOK; Seventh Edition, 2021, p. 81)<ref name="one">Project Management Institute. “A Guide to the Project Management Body of Knowledge (PMBOK)”- Seventh Edition, 2021, p. 81</ref>. This Wiki article will focus on the Work Breakdown Structure (WBS) method used to reduce the complexity of a project by delimiting the whole project plan into manageable sub-tasks on different levels. By following principles of WBS, each level of WBS and each deliverable is assigned a certain part of the project. Furthermore, the wiki article will cover context and history of WBS along with application and limitations of this method. Lastly, since WBS is very flexible and easily applicable tool, the article will focus on most popular ways of application specifically used in project management. |
== Context and Historical Applications == | == Context and Historical Applications == | ||
| − | Historically, the Work Breakdown Structure method was inspired by Program Evaluation and Review Technique (PERT) | + | Historically, the Work Breakdown Structure method was inspired by Program Evaluation and Review Technique (PERT) along with Earned Value concepts which were used by United States Department of Defense (DoD)<ref> Fleming, Quentin W., Joel M. Koppelman "Earned Value Project Management" CROSSTALK: The Journal of Defense Software Engineering July 1998, p 19-21</ref>. In 1968, along with aerospace industry and National Aeronautics and Space Agency(NASA) DoD has published a "Work Breakdown Structures for Defense Materiel Items" <ref> [ http://everyspec.com/MIL-STD/MIL-STD-0800-0899/MIL-STD-881E_56929] "WORK BREAKDOWN STRUCTURES FOR DEFENSE MATERIEL ITEMS " 2020] </ref>. Similarly, NASA has adopted WBS to its purposes and has developed publicly available handbook of its own <ref>[https://ntrs.nasa.gov/citations/20180000844] "Work Breakdown Structure (WBS) Handbook" 2018 </ref>. In both organizations WBS was introduced to be used for Program, Product and Project management. In 1987, WBS method was documented by the Project Management Institute (PMI) with a focus to provide more industry applicable concept of this technique. |
| − | + | ||
== WBS Terminology and Principles == | == WBS Terminology and Principles == | ||
| − | Before | + | Before presenting the framework of Work Breakdown Structure and its applications it is important to understand the main terms and principles used in WBS development. Therefore, this section will cover main terms and its explanations along with its principles and their impact to the use of method. |
===Terminology=== | ===Terminology=== | ||
| − | + | The terms and their explanations are taken from NASA WBS handbook: <ref>[https://ntrs.nasa.gov/citations/20180000844] "Work Breakdown Structure (WBS) Handbook" 2016 p.46 </ref> | |
| − | + | '''WBS Levels''' - A visual and coded arrangement or configuration of a WBS which enables the hierarchy of a projects to deliverables and deliverables to work packages and tasks. The levels can be seen on the left side of '''Figure 1'''. | |
| − | + | '''Deliverable''' - Usually expressed in nouns/adjectives, the deliverables are the work products of the project. They are aimed to describe "what" of a project with an intention to express results and not only actions. They are usually visualized as a separate box in WSB template and have a specific code assigned to it. The deliverable of "1.1 Frame set" can be seen as a first box in level 2 in '''Figure 1'''. | |
| + | '''Work Package''' - The lowest level of a deliverable which contains a clear identification of tasks, activities and milestones that have to be delivered in order to fulfil the deliverable. Work package is identified as "1.6.4.1 Customer Testing" in '''Figure 1'''. The more detailed description of work package deliverable is always found in WBS Dictionary. | ||
===Principles=== | ===Principles=== | ||
| − | Decomposition - As indicated by the naming, this method relies on Breakdown principle often called Decomposition. | + | '''Decomposition''' - As indicated by the naming, this method relies on Breakdown principle often called Decomposition. |
| − | The main idea of this is that the project has to be decomposed into a deliverables with a level of detail which would precisely capture the whole scope of the project and at the same time maintain that level of detail for effective communications, task divisions and control. | + | The main idea of this is that the project has to be decomposed into a deliverables with a level of detail which would precisely capture the whole scope of the project and at the same time maintain that level of detail for effective communications, task divisions and control. <ref>Eric S. Norman, Robert T. Fried, Shelly A. Brotherton. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008, p. 28</ref> |
| − | 100% rule - Following the principle of Decomposition it is important to keep the scope of each deliverable in line with the whole project and its limitations. Therefore the 100% rule is essential when developing WBS and it states that each level | + | '''100% rule''' - Following the principle of Decomposition it is important to keep the scope of each deliverable in line with the whole project and its limitations. Therefore the 100% rule is essential when developing WBS and it states that each level |
| − | of WBS decomposition has to make 100% of the work of its parent element. | + | of WBS decomposition has to make 100% of the work of its parent element. <ref>Eric S. Norman, Robert T. Fried, Shelly A. Brotherton. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008, p. 23</ref> |
| − | Project Scope - Each deliverable and element of WBS has to be within project's scope and any tasks that do not belong to the project, should be left out. | + | '''Project Scope''' - Each deliverable and element of WBS has to be within project's scope and any tasks that do not belong to the project, should be left out. <ref>Eric S. Norman, Robert T. Fried, Shelly A. Brotherton. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008, p. 53</ref>. Therefore, in each project beginning it is important to have a well defined scope of a project to further proceed with WBS development. |
==Framework== | ==Framework== | ||
| Line 37: | Line 37: | ||
#WBS Dictionary | #WBS Dictionary | ||
#Project Schedule | #Project Schedule | ||
| − | |||
=== Visual Representation === | === Visual Representation === | ||
| Line 47: | Line 46: | ||
| − | As mentioned before, the most common way of representing WBS is by the use of Tree structure otherwise known as Organisational Chart. The main reason for its popularity between WBS users is that this kind of visualisation allows to present "child" and "parent" dependencies between deliverables. In this case, the child elements are visualised as a smaller boxes which are | + | As mentioned before, the most common way of representing WBS is by the use of Tree structure otherwise known as Organisational Chart. The main reason for its popularity between WBS users is that this kind of visualisation allows to present "child" and "parent" dependencies between deliverables. In this case, the child elements are visualised as a smaller boxes which are connected by lines with the parent elements higher in the structure <ref> Project Management Institute (PMI) “Practice Standard for Work Breakdown Structures”- Second Edition, 2011, p. 54</ref>. With this kind of representation, the whole project can be decomposed into smaller elements and code structure can be still maintained by identifying the code in each box. Lastly, levels could be indicated for easier decomposition visualisation. The example of Tree view of WBS can be seen in '''Figure 1'''. |
| − | <li style="display: inline-block;"> [[File:WBS_Structures.jpg|thumb|none|780px|Figure 1: | + | <li style="display: inline-block;"> [[File:WBS_Structures.jpg|thumb|none|780px|Figure 1: WBS: Tree view visualisation, inspired by the “Practice Standard for Work Breakdown Structures”-Second Edition (2011)]] |
| − | + | ||
==== Tabular view ==== | ==== Tabular view ==== | ||
| − | Another type of WBS visualisation is Tabular view. In this case, the levels of WBS along with hierarchy and coding of elements is | + | Another type of WBS visualisation is Tabular view. In this case, the levels of WBS along with hierarchy and coding of elements is indicated by table columns. This type of visualisation can be made using simple tools such as Excel and therefore is a popular choice between people with limited design tools.<ref> Project Management Institute (PMI) “Practice Standard for Work Breakdown Structures”- Second Edition, 2011, p. 53</ref> A potential disadvantage of this representation can be increased complexity when dealing with big WBS structures since modelling in tabular forms is demanding process. |
| − | + | ||
| − | + | ||
| + | <li style="display: inline-block;"> [[File:Tabular_view.png|thumb|none|780px|Figure 2: WBS: Tabular view visualisation, inspired by the “Practice Standard for Work Breakdown Structures”-Second Edition (2011)]] | ||
==== Outline view ==== | ==== Outline view ==== | ||
| − | The last visualisation used for WBS is Outline view. This kind of visualisation has numbered levels for each element along with its coding. The main tools used for outline view are regular office tools such as word processor and excel. Outline view can be seen in '''Figure 3 '''. | + | The last visualisation used for WBS is Outline view. This kind of visualisation has numbered levels for each element along with its coding. The main tools used for outline view are regular office tools such as word processor and excel. The downside of this type of visualisation is lack of apparent hierarchical structure which in this case is only indicated by the coding of deliverables. Outline view can be seen in '''Figure 3 ''' <ref> Project Management Institute (PMI) “Practice Standard for Work Breakdown Structures”- Second Edition, 2011, p. 51</ref>. |
| − | <li style="display: inline-block;"> [[File:Outline_view.png|thumb|none|780px|Figure | + | <li style="display: inline-block;"> [[File:Outline_view.png|thumb|none|780px|Figure 3: WBS: Outline view visualisation, inspired by the “Practice Standard for Work Breakdown Structures”-Second Edition (2011)]] |
=== WBS Dictionary === | === WBS Dictionary === | ||
| − | When the WBS of the project is finalised, the WBS Dictionary should be developed to support the project and WBS. The main goal of the WBS Dictionary is to reduce uncertainty by providing an extra clarity for all team members, | + | When the WBS of the project is finalised, the WBS Dictionary should be developed to support the project and WBS. The main goal of the WBS Dictionary is to reduce uncertainty by providing an extra clarity for all team members, stakeholders and sponsors<ref>[https://www.projectmanager.com/blog/wbs-dictionary#:~:text=What%20Is%20a%20WBS%20Dictionary,%2C%20resources%2C%20cost%20and%20quantity.] WBS Dictionary: A Quick Guide with Examples</ref>.The Dictionary is intended to contain necessary explanations, context and detail in text to further aid communication and facilitate understanding. Therefore WBS Dictionary indicates level, WBS Code, Name, definition and responsible organization of each Element or deliverable. The example of WBS dictionary of Bicycle WBS is depicted in '''Figure 4''' where the third element "Frame" has a WBS level 3, WBS code 1.1.1 and corresponding definition. |
| − | + | <li style="display: inline-block;"> [[File:WBS_Dictionary_PM.png|thumb|none|780px|Figure 4: WBS Dictionary, inspired by the “Practice Standard for Work Breakdown Structures”-Second Edition (2011)]] | |
| − | WBS | + | |
=== Project Schedule === | === Project Schedule === | ||
| − | Once the WBS has been | + | Once the WBS has been depicted in a visual format and WBS dictionary has been developed, these two elements of WBS can be taken the for project planning. Here Project Schedule template can be used to transform the tasks from WBS lowest level to the Schedule. The whole transition from WBS to Project Schedule consists of three main steps: Activity definition, Activity sequencing and Project schedule development. During the Activity Definition phase, the WBS deliverables are defined as activities and if needed are further decomposed into tasks. Here the WBS dictionary is used for deliverable definition and further information. Once all activities are specified, the sequencing stage begins. In this stage, network diagrams and flowcharts are used to map the activities according to their dependencies. Lastly, by using the outputs of activity definition and sequencing, the master project schedule is generated. <ref>Eric S. Norman, Robert T. Fried, Shelly A. Brotherton. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008, p. 130</ref> |
== WBS Application in Project Management == | == WBS Application in Project Management == | ||
| − | Given main principles and the different approaches to visualizing WBS there is still room for different methods of its application in project management, these methods will be covered below. | + | Given main principles and the different approaches to visualizing WBS there is still room for different methods of its application in project management, these methods will be covered below with the main focus on two most commonly used methods: Top-down and Bottom-up. <ref>Eric S. Norman, Robert T. Fried, Shelly A. Brotherton. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008, p. 58-60 </ref> |
==== Top-down ==== | ==== Top-down ==== | ||
| − | One of the most common | + | One of the most common approaches of WBS application is Top-down. As the naming suggests, the WBS application starts from the main project in level 0 and later is decomposed into major deliverables in lower levels. The suggested approach contains four main steps: |
| − | Step 1: | + | Step 1: Identification of the final product, service or result that would be a goal of a successful project. Following this step, the project team should define a project scope and review existing documentation to ensure that the final goal is within the scope and that there is no mismatch between project requirements and WBS. |
| − | Step 2: Definition of project major deliverables of level 1. These deliverables should be seen as | + | Step 2: Definition of project major deliverables of level 1. These deliverables should be seen as an interim goals which are needed for project success but does not satisfy the need as a single entity. This process can be carried in an iterative manner where the level 1 deliverables are defined and validated considering the 100% rule. |
| − | Step 3: Decomposition of project main deliverables to lower levels which would contain a level of detail needed for the project management and task definition. In this step | + | Step 3: Decomposition of project main deliverables to lower levels which would contain a level of detail needed for the project management and task definition. In this step previously explained work packages should be defined to work as a stand-alone deliverable. This step can also be carried out in an iterative manner considering the 100% rule. |
| − | Step 4: Revision of WBS to match stakeholder needs. The main goal of this step is to develop a WBS which would reflect the whole project in terms of planning, execution and control to convince and | + | Step 4: Revision of WBS to match stakeholder needs. The main goal of this step is to develop a WBS which would reflect the whole project in terms of planning, execution and control to convince and inform stakeholders. |
| − | ==== | + | ==== Bottom-Up ==== |
| − | In | + | In contrast, the project group can choose to start the construction of WBS by the work package definition and work their way up to the definition of the final project. It is important to not get carried away when following this method. There are 6 main steps needed when developing WBS trough Bottom-Up approach: |
Step 1: Starting from the lowest level - work packages, identify all deliverables involved in the whole project. It is important to keep only one deliverable per work package. | Step 1: Starting from the lowest level - work packages, identify all deliverables involved in the whole project. It is important to keep only one deliverable per work package. | ||
| Line 102: | Line 98: | ||
Step 3: Aggregation of the deliverables towards upper level to form a parent-child structure. After this step the team should make sure that current structure follows the 100% rule. | Step 3: Aggregation of the deliverables towards upper level to form a parent-child structure. After this step the team should make sure that current structure follows the 100% rule. | ||
| − | Step 4: Revision | + | Step 4: Revision of the structure. After the step 3, the team should make sure that current structure follows the 100% rule and that all of the work has been included in the WBS structure. |
Step 5: Aggregation towards Level 0. Here the steps are repeated until the deliverables make up the whole project and level 0 is reached. | Step 5: Aggregation towards Level 0. Here the steps are repeated until the deliverables make up the whole project and level 0 is reached. | ||
| − | Step 6: Revision of WBS to match stakeholder needs. The main goal of this step is to develop a WBS which would reflect the whole project in terms of planning, execution and control to convince and | + | Step 6: Revision of WBS to match stakeholder needs. The main goal of this step is to develop a WBS which would reflect the whole project in terms of planning, execution and control to convince and inform stakeholders. |
==== WBS Standards and Templates ==== | ==== WBS Standards and Templates ==== | ||
| − | Organizations with high project management maturity might have developed a organizational WBS standard which would work as a internal set of principles used when construing a WBS. The standards can include aspects such as format, numbering scheme, | + | Organizations with high project management maturity might have developed a organizational WBS standard which would work as a internal set of principles used when construing a WBS. The standards can include aspects such as format, numbering scheme, convention or some required elements. The aim of these standards is to ease the WBS application and to ensure consistency and completeness along the whole organization. |
| − | Followed by the Standards, WBS Templates can be created as a sample with a hierarchical structure that could be customized in each project. It | + | Followed by the Standards, WBS Templates can be created as a sample with a hierarchical structure that could be customized in each project. It should be noted that organization can have multiple standards and templates for different projects. Lastly, compared to previous approaches, WBS standards and Templates are for reusing of existing WBS materials while Top-Down and Bottom-Up approaches are for new WBS development. |
| − | + | ||
=== WBS Tools === | === WBS Tools === | ||
| Line 121: | Line 116: | ||
==== Sticky Notes ==== | ==== Sticky Notes ==== | ||
| − | As one of the most used and cheapest tools of project management, sticky notes can also be used when developing a WBS. In this case the group members would engage into a brainstorm like workshop to think of many deliverables for the project as possible. Once the group is out of ideas, the project manager can facilitate the | + | As one of the most used and cheapest tools of project management, sticky notes can also be used when developing a WBS. In this case the group members would engage into a brainstorm like workshop to think of many deliverables for the project as possible. Once the group is out of ideas, the project manager can facilitate the structuration of the WBS by combining similar sticky notes on top of each other and then grouping them under more general deliverable. In this case the final result will be well defined Level 0 and Level 1 deliverables along with lower level deliverables used to define work packages. |
==== Spreadsheets and Word processing tools ==== | ==== Spreadsheets and Word processing tools ==== | ||
| − | As computers and different applications are inseparable part of project management, spreadsheets and Word processing tools can be | + | As computers and different applications are inseparable part of project management, spreadsheets and Word processing tools can be easily incorporated for the WBS development. In this case, spreadsheets can be used to develop a detailed version of WBS while word processing tools can be used to define WBS Dictionary. Lastly, the application of the two could be combined to generate a template or visualization of the WBS. |
| − | ==== | + | ==== Enterprise Project Management ==== |
| − | If the projects taken in the | + | If the projects taken in the organization tend to be complex and require precise resource estimation, EPM could be integrated to allocate employees, costs and investments. |
| − | + | ||
| − | + | ||
== Advantages == | == Advantages == | ||
| − | The WBS in Project management is very versatile tool which allows expanding on its main principles. Therefore, WBS can be used not only for project deliverable planning but also resource allocation and cost estimation. Furthermore, since every member of the project is collaborating during WBS | + | The WBS in Project management is very versatile tool which allows expanding on its main principles. Therefore, WBS can be used not only for project deliverable planning but also resource allocation and cost estimation. Furthermore, since every member of the project is collaborating during WBS development, people tend to take care that their work is represented in WBS. Lastly, WBS and WBS Dictionary integration with Project Schedule not only allows to develop a timeline for the project but can also work as a tool for Risk management when allocating the resources of the project. |
== Limitations == | == Limitations == | ||
| + | |||
| + | Correctly applied WBS method can provide every project manager with a structured approach towards project management, its execution and reduction in uncertainty. Therefore, it is important to be aware of limitations that this method can have. Firstly, in the literature about WBS, the aspect of detail has been touched upon few times. Authors indicate that too much information as well as too little information can cause this method to provide more uncertainty that clear structure, therefore it is up to every project manager to monitor WBS documentation and to make sure that the amount of information provided by WBS structure and WBS Dictionary is enough to have a fluid information flow. Secondly, WBS structure in itself cannot provide a thorough project schedule therefore to avoid any misalignment of the tasks, WBS visualisation has to be used only for project planning inspiration and not as the schedule itself. | ||
| + | |||
| + | == Summary == | ||
| + | |||
| + | The WBS structure is a very widely applicable tool in project management that could be used by project managers to reduce the uncertainty of the project early stages by incorporating the whole project group into project delimitation. By the use of this tool, project deliverables, their hierarchical dependencies and definitions can be documented and visualised in different ways. This article has provided the reader with the background of WBS along with its most commonly used approaches in project management, namely Tree view for visualisation and top-down/bottom-up WBS development approaches. Furthermore, tools used in WBS development and different applications of WBS itself were discussed. Lastly, advantages and limitations of WBS were discussed with regards on how the WBS method provides project managers with a process step approach to structuring the project which later can be used for project scheduling, resource estimation, risk management and communication with project stakeholders. | ||
== Annotated Bibliography == | == Annotated Bibliography == | ||
| + | |||
| + | '''Eric S. Norman, Robert T. Fried, Shelly A. Brotherton. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008.''' : This book provides information about the development processes of the WBS along with wider scope on how WBS can be used for other Project Management processes. The book contains examples and WBS Structure visualisations. | ||
| + | |||
| + | '''Project Management Institute. “A Guide to the Project Management Body of Knowledge (PMBOK® Guide)”- Seventh Edition, 2013''': The Project Management guide provides information regarding project management, WBS and other concepts. | ||
| + | |||
| + | '''Project Management Institute. “Practice Standard for Work Breakdown Structures”- Second Edition, 2011''': This book is specifically focused on WBS and therefore it works as a useful guide for the actual application of WBS in real-life scenarios. Furthermore, it provides examples and visualisations from real life cases. | ||
| + | |||
| + | '''NASA Work Breakdown Structure (WBS) Handbook''' : This WBS handbook developed by NASA provides both: a handy guide on WBS used in governmental organizations along with well-defined WBS dictionary which could be used to further familiarize with WBS method. | ||
== References == | == References == | ||
Latest revision as of 14:01, 18 March 2022
Contents |
[edit] Abstract
Project Management is often a complex process involving various teams, stakeholders and different development approaches. Therefore, structured planning of the whole project work is important in order to reach the delivery of the expected result within time and dedicated budget. Since each project is different complexity wise, uncertainty in early stages of some projects can be expected. In order to reduce the project uncertainty it is important to break down the complex tasks into manageable sub-tasks of the whole project (PMBOK; Seventh Edition, 2021, p. 81)[1]. This Wiki article will focus on the Work Breakdown Structure (WBS) method used to reduce the complexity of a project by delimiting the whole project plan into manageable sub-tasks on different levels. By following principles of WBS, each level of WBS and each deliverable is assigned a certain part of the project. Furthermore, the wiki article will cover context and history of WBS along with application and limitations of this method. Lastly, since WBS is very flexible and easily applicable tool, the article will focus on most popular ways of application specifically used in project management.
[edit] Context and Historical Applications
Historically, the Work Breakdown Structure method was inspired by Program Evaluation and Review Technique (PERT) along with Earned Value concepts which were used by United States Department of Defense (DoD)[2]. In 1968, along with aerospace industry and National Aeronautics and Space Agency(NASA) DoD has published a "Work Breakdown Structures for Defense Materiel Items" [3]. Similarly, NASA has adopted WBS to its purposes and has developed publicly available handbook of its own [4]. In both organizations WBS was introduced to be used for Program, Product and Project management. In 1987, WBS method was documented by the Project Management Institute (PMI) with a focus to provide more industry applicable concept of this technique.
[edit] WBS Terminology and Principles
Before presenting the framework of Work Breakdown Structure and its applications it is important to understand the main terms and principles used in WBS development. Therefore, this section will cover main terms and its explanations along with its principles and their impact to the use of method.
[edit] Terminology
The terms and their explanations are taken from NASA WBS handbook: [5]
WBS Levels - A visual and coded arrangement or configuration of a WBS which enables the hierarchy of a projects to deliverables and deliverables to work packages and tasks. The levels can be seen on the left side of Figure 1.
Deliverable - Usually expressed in nouns/adjectives, the deliverables are the work products of the project. They are aimed to describe "what" of a project with an intention to express results and not only actions. They are usually visualized as a separate box in WSB template and have a specific code assigned to it. The deliverable of "1.1 Frame set" can be seen as a first box in level 2 in Figure 1.
Work Package - The lowest level of a deliverable which contains a clear identification of tasks, activities and milestones that have to be delivered in order to fulfil the deliverable. Work package is identified as "1.6.4.1 Customer Testing" in Figure 1. The more detailed description of work package deliverable is always found in WBS Dictionary.
[edit] Principles
Decomposition - As indicated by the naming, this method relies on Breakdown principle often called Decomposition. The main idea of this is that the project has to be decomposed into a deliverables with a level of detail which would precisely capture the whole scope of the project and at the same time maintain that level of detail for effective communications, task divisions and control. [6]
100% rule - Following the principle of Decomposition it is important to keep the scope of each deliverable in line with the whole project and its limitations. Therefore the 100% rule is essential when developing WBS and it states that each level of WBS decomposition has to make 100% of the work of its parent element. [7]
Project Scope - Each deliverable and element of WBS has to be within project's scope and any tasks that do not belong to the project, should be left out. [8]. Therefore, in each project beginning it is important to have a well defined scope of a project to further proceed with WBS development.
[edit] Framework
The framework of WBS consists of three main parts being:
- Visual representation
- WBS Dictionary
- Project Schedule
[edit] Visual Representation
Visual representation can be made in various ways but the most common format used in project management is Tree view. The tree view clearly depicts levels of the WBS and indicates the coding assigned for each deliverable
[edit] Tree view
As mentioned before, the most common way of representing WBS is by the use of Tree structure otherwise known as Organisational Chart. The main reason for its popularity between WBS users is that this kind of visualisation allows to present "child" and "parent" dependencies between deliverables. In this case, the child elements are visualised as a smaller boxes which are connected by lines with the parent elements higher in the structure [9]. With this kind of representation, the whole project can be decomposed into smaller elements and code structure can be still maintained by identifying the code in each box. Lastly, levels could be indicated for easier decomposition visualisation. The example of Tree view of WBS can be seen in Figure 1.
[edit] Tabular view
Another type of WBS visualisation is Tabular view. In this case, the levels of WBS along with hierarchy and coding of elements is indicated by table columns. This type of visualisation can be made using simple tools such as Excel and therefore is a popular choice between people with limited design tools.[10] A potential disadvantage of this representation can be increased complexity when dealing with big WBS structures since modelling in tabular forms is demanding process.
[edit] Outline view
The last visualisation used for WBS is Outline view. This kind of visualisation has numbered levels for each element along with its coding. The main tools used for outline view are regular office tools such as word processor and excel. The downside of this type of visualisation is lack of apparent hierarchical structure which in this case is only indicated by the coding of deliverables. Outline view can be seen in Figure 3 [11].
[edit] WBS Dictionary
When the WBS of the project is finalised, the WBS Dictionary should be developed to support the project and WBS. The main goal of the WBS Dictionary is to reduce uncertainty by providing an extra clarity for all team members, stakeholders and sponsors[12].The Dictionary is intended to contain necessary explanations, context and detail in text to further aid communication and facilitate understanding. Therefore WBS Dictionary indicates level, WBS Code, Name, definition and responsible organization of each Element or deliverable. The example of WBS dictionary of Bicycle WBS is depicted in Figure 4 where the third element "Frame" has a WBS level 3, WBS code 1.1.1 and corresponding definition.
[edit] Project Schedule
Once the WBS has been depicted in a visual format and WBS dictionary has been developed, these two elements of WBS can be taken the for project planning. Here Project Schedule template can be used to transform the tasks from WBS lowest level to the Schedule. The whole transition from WBS to Project Schedule consists of three main steps: Activity definition, Activity sequencing and Project schedule development. During the Activity Definition phase, the WBS deliverables are defined as activities and if needed are further decomposed into tasks. Here the WBS dictionary is used for deliverable definition and further information. Once all activities are specified, the sequencing stage begins. In this stage, network diagrams and flowcharts are used to map the activities according to their dependencies. Lastly, by using the outputs of activity definition and sequencing, the master project schedule is generated. [13]
[edit] WBS Application in Project Management
Given main principles and the different approaches to visualizing WBS there is still room for different methods of its application in project management, these methods will be covered below with the main focus on two most commonly used methods: Top-down and Bottom-up. [14]
[edit] Top-down
One of the most common approaches of WBS application is Top-down. As the naming suggests, the WBS application starts from the main project in level 0 and later is decomposed into major deliverables in lower levels. The suggested approach contains four main steps:
Step 1: Identification of the final product, service or result that would be a goal of a successful project. Following this step, the project team should define a project scope and review existing documentation to ensure that the final goal is within the scope and that there is no mismatch between project requirements and WBS.
Step 2: Definition of project major deliverables of level 1. These deliverables should be seen as an interim goals which are needed for project success but does not satisfy the need as a single entity. This process can be carried in an iterative manner where the level 1 deliverables are defined and validated considering the 100% rule.
Step 3: Decomposition of project main deliverables to lower levels which would contain a level of detail needed for the project management and task definition. In this step previously explained work packages should be defined to work as a stand-alone deliverable. This step can also be carried out in an iterative manner considering the 100% rule.
Step 4: Revision of WBS to match stakeholder needs. The main goal of this step is to develop a WBS which would reflect the whole project in terms of planning, execution and control to convince and inform stakeholders.
[edit] Bottom-Up
In contrast, the project group can choose to start the construction of WBS by the work package definition and work their way up to the definition of the final project. It is important to not get carried away when following this method. There are 6 main steps needed when developing WBS trough Bottom-Up approach:
Step 1: Starting from the lowest level - work packages, identify all deliverables involved in the whole project. It is important to keep only one deliverable per work package.
Step 2: Group related work packages together based on their focus, area and relation towards the project.
Step 3: Aggregation of the deliverables towards upper level to form a parent-child structure. After this step the team should make sure that current structure follows the 100% rule.
Step 4: Revision of the structure. After the step 3, the team should make sure that current structure follows the 100% rule and that all of the work has been included in the WBS structure.
Step 5: Aggregation towards Level 0. Here the steps are repeated until the deliverables make up the whole project and level 0 is reached.
Step 6: Revision of WBS to match stakeholder needs. The main goal of this step is to develop a WBS which would reflect the whole project in terms of planning, execution and control to convince and inform stakeholders.
[edit] WBS Standards and Templates
Organizations with high project management maturity might have developed a organizational WBS standard which would work as a internal set of principles used when construing a WBS. The standards can include aspects such as format, numbering scheme, convention or some required elements. The aim of these standards is to ease the WBS application and to ensure consistency and completeness along the whole organization. Followed by the Standards, WBS Templates can be created as a sample with a hierarchical structure that could be customized in each project. It should be noted that organization can have multiple standards and templates for different projects. Lastly, compared to previous approaches, WBS standards and Templates are for reusing of existing WBS materials while Top-Down and Bottom-Up approaches are for new WBS development.
[edit] WBS Tools
Another important aspect of WBS in project management is the tools that can be used when developing a WBS for a project. This section will cover different types of tools that can be used when creating WBS in a project team.
[edit] Sticky Notes
As one of the most used and cheapest tools of project management, sticky notes can also be used when developing a WBS. In this case the group members would engage into a brainstorm like workshop to think of many deliverables for the project as possible. Once the group is out of ideas, the project manager can facilitate the structuration of the WBS by combining similar sticky notes on top of each other and then grouping them under more general deliverable. In this case the final result will be well defined Level 0 and Level 1 deliverables along with lower level deliverables used to define work packages.
[edit] Spreadsheets and Word processing tools
As computers and different applications are inseparable part of project management, spreadsheets and Word processing tools can be easily incorporated for the WBS development. In this case, spreadsheets can be used to develop a detailed version of WBS while word processing tools can be used to define WBS Dictionary. Lastly, the application of the two could be combined to generate a template or visualization of the WBS.
[edit] Enterprise Project Management
If the projects taken in the organization tend to be complex and require precise resource estimation, EPM could be integrated to allocate employees, costs and investments.
[edit] Advantages
The WBS in Project management is very versatile tool which allows expanding on its main principles. Therefore, WBS can be used not only for project deliverable planning but also resource allocation and cost estimation. Furthermore, since every member of the project is collaborating during WBS development, people tend to take care that their work is represented in WBS. Lastly, WBS and WBS Dictionary integration with Project Schedule not only allows to develop a timeline for the project but can also work as a tool for Risk management when allocating the resources of the project.
[edit] Limitations
Correctly applied WBS method can provide every project manager with a structured approach towards project management, its execution and reduction in uncertainty. Therefore, it is important to be aware of limitations that this method can have. Firstly, in the literature about WBS, the aspect of detail has been touched upon few times. Authors indicate that too much information as well as too little information can cause this method to provide more uncertainty that clear structure, therefore it is up to every project manager to monitor WBS documentation and to make sure that the amount of information provided by WBS structure and WBS Dictionary is enough to have a fluid information flow. Secondly, WBS structure in itself cannot provide a thorough project schedule therefore to avoid any misalignment of the tasks, WBS visualisation has to be used only for project planning inspiration and not as the schedule itself.
[edit] Summary
The WBS structure is a very widely applicable tool in project management that could be used by project managers to reduce the uncertainty of the project early stages by incorporating the whole project group into project delimitation. By the use of this tool, project deliverables, their hierarchical dependencies and definitions can be documented and visualised in different ways. This article has provided the reader with the background of WBS along with its most commonly used approaches in project management, namely Tree view for visualisation and top-down/bottom-up WBS development approaches. Furthermore, tools used in WBS development and different applications of WBS itself were discussed. Lastly, advantages and limitations of WBS were discussed with regards on how the WBS method provides project managers with a process step approach to structuring the project which later can be used for project scheduling, resource estimation, risk management and communication with project stakeholders.
[edit] Annotated Bibliography
Eric S. Norman, Robert T. Fried, Shelly A. Brotherton. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008. : This book provides information about the development processes of the WBS along with wider scope on how WBS can be used for other Project Management processes. The book contains examples and WBS Structure visualisations.
Project Management Institute. “A Guide to the Project Management Body of Knowledge (PMBOK® Guide)”- Seventh Edition, 2013: The Project Management guide provides information regarding project management, WBS and other concepts.
Project Management Institute. “Practice Standard for Work Breakdown Structures”- Second Edition, 2011: This book is specifically focused on WBS and therefore it works as a useful guide for the actual application of WBS in real-life scenarios. Furthermore, it provides examples and visualisations from real life cases.
NASA Work Breakdown Structure (WBS) Handbook : This WBS handbook developed by NASA provides both: a handy guide on WBS used in governmental organizations along with well-defined WBS dictionary which could be used to further familiarize with WBS method.
[edit] References
- ↑ Project Management Institute. “A Guide to the Project Management Body of Knowledge (PMBOK)”- Seventh Edition, 2021, p. 81
- ↑ Fleming, Quentin W., Joel M. Koppelman "Earned Value Project Management" CROSSTALK: The Journal of Defense Software Engineering July 1998, p 19-21
- ↑ [ http://everyspec.com/MIL-STD/MIL-STD-0800-0899/MIL-STD-881E_56929] "WORK BREAKDOWN STRUCTURES FOR DEFENSE MATERIEL ITEMS " 2020]
- ↑ [1] "Work Breakdown Structure (WBS) Handbook" 2018
- ↑ [2] "Work Breakdown Structure (WBS) Handbook" 2016 p.46
- ↑ Eric S. Norman, Robert T. Fried, Shelly A. Brotherton. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008, p. 28
- ↑ Eric S. Norman, Robert T. Fried, Shelly A. Brotherton. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008, p. 23
- ↑ Eric S. Norman, Robert T. Fried, Shelly A. Brotherton. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008, p. 53
- ↑ Project Management Institute (PMI) “Practice Standard for Work Breakdown Structures”- Second Edition, 2011, p. 54
- ↑ Project Management Institute (PMI) “Practice Standard for Work Breakdown Structures”- Second Edition, 2011, p. 53
- ↑ Project Management Institute (PMI) “Practice Standard for Work Breakdown Structures”- Second Edition, 2011, p. 51
- ↑ [3] WBS Dictionary: A Quick Guide with Examples
- ↑ Eric S. Norman, Robert T. Fried, Shelly A. Brotherton. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008, p. 130
- ↑ Eric S. Norman, Robert T. Fried, Shelly A. Brotherton. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008, p. 58-60
