Work Breakdown Structure (WBS) in Project Management
Thanosfotis (Talk | contribs) |
Thanosfotis (Talk | contribs) |
||
| (51 intermediate revisions by one user not shown) | |||
| Line 1: | Line 1: | ||
==History== | ==History== | ||
| − | The Work Break Down Structure (WBS) was developed during 1960s by the U.S. Department of Defense (DoD) and the National Aeronautics and Space Administration (NASA) under the two main pillars of | + | The Work Break Down Structure (WBS) was developed during 1960s by the U.S. Department of Defense (DoD) and the National Aeronautics and Space Administration (NASA) under the two main pillars of “planning’’ and “controlling’’ the large projects they were responsible for, in order to provide the best quality. Specifically, on June 1962, NASA and DoD published a document regarding PERT/COST which was the first approach to the Work Breakdown Structure. It is worth pointing out, that this guide was adopted in all services as a military standard across DoD <ref name="DoD"/>. |
In 1987, this approach of WBS was documented from the Project Management Institute (PMI) in order to provide a generic concept of these techniques for non-defense organizations. Ergo, the Project Management Body of Knowledge (PMBOK) Guide provides an overview of WBS approach for general application through the organizations. | In 1987, this approach of WBS was documented from the Project Management Institute (PMI) in order to provide a generic concept of these techniques for non-defense organizations. Ergo, the Project Management Body of Knowledge (PMBOK) Guide provides an overview of WBS approach for general application through the organizations. | ||
| Line 7: | Line 7: | ||
==Definition of Work Breakdown Structure == | ==Definition of Work Breakdown Structure == | ||
| − | The Work Breakdown Structure (WBS) is a widely applied tool in the field of project management which is defined as the hierarchical decomposition framework for presenting the work that needs to be executed by the team, in order to achieve the project objectives | + | The Work Breakdown Structure (WBS) is a widely applied tool in the field of project management which is defined as the hierarchical decomposition framework for presenting the work that needs to be executed by the team, in order to achieve the project objectives <ref name="ISO"/>. Specifically, it creates the backbone of the project and provides a clear visual overview of the work to be completed. WBS is a tool that gives the ability to the project team to develop the project schedule and the resource requirements, to estimate and control the cost, while at the same time to minimize the number of unexpected situations. Therefore, the main purpose of WBS is to organize the team’s work into manageable sections and define the total scope of the project <ref name="WBS"/>. |
| + | ==WBS Representation== | ||
| − | + | The purpose of the WBS is to communicate the scope of the project to all the relevant project stakeholders. As diverse stakeholders have different needs, different WBS representation methods are required. The most widely used representation views are outline, tabular and tree structure. | |
| − | + | ||
| − | + | [[File:WBS_tree_organisational.png|1300px|thumb|left|Figure 1: Organization Chart Style WBS <ref name="foundation"/>]] | |
| + | [[File:WBS_horizontal.png|1300px|thumb|right|Figure 2: Horizontal WBS <ref name="foundation"/>]] | ||
| + | [[File:Fotis4.png|1300px|thumb|right|Figure 3: Centralised tree structure <ref name="foundation"/>]] | ||
| − | + | The tree structure uses alternative representation types with the organization chart technique being the most common one. As it is presented in figure 1, the root of the tree is on top and the WBS decomposition is performed vertically to the diagram’s bottom. | |
| − | The | + | The tree view representation can be easily modified into other views. The horizontal WBS has the root of tree on the left, whereas the WBS is decomposed horizontally towards the right side of the diagram and it is depicted in figure 2. |
| − | + | The last of the three well known tree views is the centralized tree structure, where the root of the tree is at the center of the WBS diagram and the decomposition elements are moving towards the diagram’s edges. A typical centralized WBS example is illustrated in figure 3. This type of tree representation can be quite powerful during the WBS development phase. | |
| − | + | ||
| − | [[File: | + | Except for the aforementioned graphical representation of WBS, there are also outline and tabular representation ways in order to communicate more accurately and efficiently the WBS elements to the relevant stakeholders. Figures 4 and 5 present typical examples of tabular and outline WBS views. The main content of the following figures is common, but each one serves different purpose according to the stakeholders that receive and reflect on the information. |
| − | + | ||
| + | In conclusion, it can be summarised that the selection of WBS representation technique depends ultimateley on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others support tables and outlines. As the purpose of the representation is to communicate the WBS to the audience, the final choice should be concentrated on stakeholders’ needs and preferences. | ||
| + | |||
| + | [[File:Fotis5.png|1300px|thumb|center|Figure 4: Outline WBS View <ref name="foundation"/>]] | ||
| + | [[File:Fotis7.png|1300px|thumb|center|Figure 5: Tabular View <ref name="foundation"/>]] | ||
==WBS Decomposition== | ==WBS Decomposition== | ||
The decomposition process of the WBS aims to capture the entire project scope by providing the necessary level of details in all the involved stakeholders of the project, in order to achieve the highest level of communication, management and control. The level of details in the WBS is not specific, but varies from project to project and depends on the project’s complexity, the experience of the project team and the need for control. For instance, if the project manager and the project team are experienced and familiar with the tasks to be executed from their involvement in previous projects, the level of detail can remain at a higher level. However, if the project manager or the project team are not experienced, the need for preparation of a very detailed WBS seems essential in order to provide all the necessary information regarding the tasks everyone should accomplish. In that way, the project manager eliminates the risks, ensuring that the project scope is clear in every level. | The decomposition process of the WBS aims to capture the entire project scope by providing the necessary level of details in all the involved stakeholders of the project, in order to achieve the highest level of communication, management and control. The level of details in the WBS is not specific, but varies from project to project and depends on the project’s complexity, the experience of the project team and the need for control. For instance, if the project manager and the project team are experienced and familiar with the tasks to be executed from their involvement in previous projects, the level of detail can remain at a higher level. However, if the project manager or the project team are not experienced, the need for preparation of a very detailed WBS seems essential in order to provide all the necessary information regarding the tasks everyone should accomplish. In that way, the project manager eliminates the risks, ensuring that the project scope is clear in every level. | ||
| − | It is worth pointing out that the full decomposition process does not take place always in the initiation of the project. Especially in large and complex projects, the decomposition of the WBS is partial until further information regarding the processes are known. In some other projects is decided from the project team that only some parts of the WBS can be fully decomposed from the initiation, while other parts can be enriched during the project. This technique is known as the “rolling wave” and demonstrates the flexibility of the WBS’ creation according to the project needs <ref name=" | + | It is worth pointing out that the full decomposition process does not take place always in the initiation of the project. Especially in large and complex projects, the decomposition of the WBS is partial until further information regarding the processes are known. In some other projects is decided from the project team that only some parts of the WBS can be fully decomposed from the initiation, while other parts can be enriched during the project. This technique is known as the “rolling wave” and demonstrates the flexibility of the WBS’ creation according to the project needs <ref name="PMI3"/>. |
Another critical point of the WBS decomposition that also varies from project to project is the logic it is based on. The most typical schemes of WBS decomposition are structured according the following <ref name="PMI"/>: | Another critical point of the WBS decomposition that also varies from project to project is the logic it is based on. The most typical schemes of WBS decomposition are structured according the following <ref name="PMI"/>: | ||
| − | + | ===Function=== | |
In this form of decomposition, the project deliverables are divided into groups according their business function. This style of decomposition aims to enhance the coordination and communication of responsibility to all the involved stakeholders. | In this form of decomposition, the project deliverables are divided into groups according their business function. This style of decomposition aims to enhance the coordination and communication of responsibility to all the involved stakeholders. | ||
| − | + | ===Role=== | |
The purpose of a role-based decomposition is similar to the latter one, while it is structured in that way in order to promote the communication of responsibility for the deliverables. | The purpose of a role-based decomposition is similar to the latter one, while it is structured in that way in order to promote the communication of responsibility for the deliverables. | ||
| − | + | ===Method=== | |
This type of decomposition is structured on predefined methodologies and in contradiction to the aforementioned, the main purpose is to communicate the project’s outcomes at every level of the WBS among the stakeholders. | This type of decomposition is structured on predefined methodologies and in contradiction to the aforementioned, the main purpose is to communicate the project’s outcomes at every level of the WBS among the stakeholders. | ||
| − | + | ===Deliverables=== | |
The project deliverables are subdivided into smaller and more manageable components. This form of breakdown is the most common while it is not depended on the organization structure or project type. | The project deliverables are subdivided into smaller and more manageable components. This form of breakdown is the most common while it is not depended on the organization structure or project type. | ||
In conclusion, the selection of the decomposition logic is critical and should be aligned with the desired outcomes the project manager and project team want to achieve, as well as with the project organisation’s standards. | In conclusion, the selection of the decomposition logic is critical and should be aligned with the desired outcomes the project manager and project team want to achieve, as well as with the project organisation’s standards. | ||
| − | == | + | ==The 100% Rule== |
| − | + | [[File:WBSexample.png|1300px|thumb|right|Figure 6: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]] | |
| − | + | ===Definition=== | |
| − | The | + | The 100% Rule is one of the most vital principles of WBS, which has been established from the Project Management Institute (PMI), in order to achieve a highly effective WBS and evaluate its decomposition. This rule is defined as: “The next decomposition of a WBS element (“child” level) must represent 100 percent of the work applicable to the next higher (“parent”) element <ref name="VA"/>. |
| + | According to the PMBOK, the total of the work is distributed from the lowest to the higher levels, in order to ensure that nothing is left out and prevent any extra work to be performed. It is also worth pointing out that the 100% rule is not only applied in the work packages of the project, but also in the activity level. More specifically the activities which are represented in each work package should sum up to 100% <ref name="link"/>. However, the use of the 100% Rule should be followed with the clear distinction between the elements of the WBS, since it can cause inadequate communication between the project team, double work and confusion from a financial point of view. Hence, it is suggested to use WBS dictionary to avoid this kind of ambiguities in order to eliminate risks regarding the final project outcome <ref name="link"/>. | ||
| + | The 100% Rule provides the project manager with all the necessary information regarding the specific tasks should be performed in each area in order to complete the project and the responsible people for each task. In that way the project manager is aware of the project’s progress and ensures that everything is aligned and related to the WBS elements. The WBS constitutes one of the first steps of the planning process, since it allows all outcomes to be specified before the schedule planning. Another critical aspect of the 100% Rule, is that assists the project manager to ensure that project costs are aligned with the work and every activity is related to the project in order to be completed and finally achieve the desired outcome. | ||
| + | ===The 100% Rule Example=== | ||
| + | |||
| + | The 100% rule is clearly illustrated in the figure 6 which represents the WBS of a project according to the 100% rule’s principles. Specifically, the project consists of a deliverable which is defined in the top level of the WBS regarding the construction of a house. In the second level three deliverables are represented and finally in the third level which consists the lowest level of the WBS, the activities are decomposed into a greater degree as it is required for the completion of the project. The process of decomposition ends when all the necessary information is acquired to achieve the desired outcome. | ||
| + | |||
| + | ==WBS tools== | ||
| + | |||
| + | There are many tools found in the literature that can help for the creation and the appropriate management of a WBS. Technological innovation during the last decades has contributed in the development of new high-tech tools that tend to replace the low-tech traditional ones. From the oldest pen and paper to the newest sticky notes, it should be mentioned that, although they constitute low-tech means of depiction and outline the project elements, there are effective in terms of group communication and development of WBS <ref name="foundation"/>. | ||
| + | |||
| + | Although the traditional tools remain powerful, new project scheduling tools have arisen as a result of the information technology revolution that offer substantial advantages in the WBS creation. There is a variety of tools in the bibliography, but some of the most common are the following and their main characteristics, advantages and drawbacks are summarised below. They can be used to decide the appropriate tool or combination of tools to support the WBS creation depending on the circumstances and the different needs of the project. | ||
| + | |||
| + | ===Project Management Scheduler=== | ||
| + | It constitutes a useful tool in the field of project management offering the capability of integrating the WBS elements with the project schedule. However, there are many risks that are connected to the usage of project management scheduler. One of the most important ones is that is very difficult to provide a clear differentiation between the WBS and Project schedule elements with a tendency to merge them. Another critical aspect is that the project management scheduler suits properly to task-oriented WBS compared to deliverable-oriented WBS. | ||
| + | |||
| + | ===Spreadsheet=== | ||
| + | When it comes to the spreadsheet, it is recognised as the most powerful tool in terms of creating tabular WBS views. In addition to this, it also offers the competences of creating and managing extensive and complex WBS and combining WBS with WBS dictionary. Yet, there is not efficient visual representation that is an important characteristic for understanding and developing the WBS. | ||
| + | |||
| + | ===Word Processor=== | ||
| + | Even though there are some limitations in terms of large-scale and composite WBSs, it provides substantial level of integration of various WBS views and WBS dictionary. | ||
| + | |||
| + | ===Graphics Development=== | ||
| + | It should be mentioned that Graphics Development is not the ideal suggestion on circumstances related to extensive and complex WBSs. However, it offers visual representation that is a competitive advantage as most of the other tools lack in this feature. | ||
| + | |||
| + | ===Enterprise Project Management (EPM)=== | ||
| + | It is undeniably a powerful tool that has the capability of integrating different and various project management elements such as scope, project scheduling and cost. On the other hand, it is difficult to be implemented and requires significant effort in terms of time and cost. Moreover, the application of the EPM to relatively smaller projects is restricted <ref name="VA"/>. | ||
| + | |||
| + | Undoubtedly, it can be concluded, from the analysis of the tools conducted above, that there are limitations regarding their utilization. They can often lead to differentiation issues between the WBS elements (deliverables) and there is also uncertainty in the capability of capturing all the necessary information in the life cycle of the project. Ergo, they should not be considered as panacea and their combination with the WBS should be executed properly. | ||
| + | |||
| + | ==Potential errors in WBS development== | ||
| + | |||
| + | '''1. Using Unsuitable Former WBS''' | ||
| + | |||
| + | A common mistake is that a former WBS is used as the foundation for the development of a WBS in a new project. This fact can lead to undesired results since errors and unrequired characteristics can be sustained from the previous WBS. | ||
| + | |||
| + | '''2. Non-Product Elements''' | ||
| + | |||
| + | WBS should be in general developed as product-oriented as possible. Since many projects are organized according to their functions, a functional WBS development is conducted. For instance, manufacturing, design, engineering are functions and they are not suitable WBS elements as they are not product oriented. Phase A, Phase B etc. are time plans and they are not product oriented as well. NASA Work Breakdown Structure (WBS) Handbook, 2010 Typical examples of inappropriate phase and function-oriented WBS are presented in the figures below. | ||
| + | |||
| + | [[File:Fotis6.png|1300px|thumb|center|Figure 7: Unsuitable Non-Product Oriented WBS, inspired by NASA Work Breakdown Structure (WBS) Handbook, 2010]] | ||
| + | |||
| + | '''3. Incorrect Element Hierarchy''' | ||
| + | |||
| + | Another important error in WBS development is the lack of hierarchy in the work representation due to inefficient personnel involved in the development of WBS. It is necessary that people with the right knowledge and an adequate understanding of the purpose and the scope of the project, the system and the implementation processes are involved in the WBS development. An incorrect hierarchy of WBS elements is depicted in the following figure. | ||
| + | |||
| + | [[File:Fotis8.png|1300px|thumb|center|Figure 8: Illustration of Incorrect Element Hierarchy, inspired by NASA Work Breakdown Structure (WBS) Handbook, 2010]] | ||
| + | |||
| + | ==Limitations== | ||
| + | |||
| + | The WBS is a powerful tool for every project when it is executed properly. However, there are also some limitations that should be seriously considered in order to avoid undesired results. The level of detail for the work packages should remain in the appropriate level providing the necessary information for the project completion. More details than what is actually needed can lead to miscommunication and finally slow down the total progress of the project. Additionally, the WBS should illustrate the breakdown of the project deliverables and not a list of specific tasks and actions, since the latter ones can be modified during the execution of the project compared to the deliverables that cannot me changed without a change request. Furthermore, WBS is often incorrectly confused with the Organizational Hierarchy chart because of their similar characteristics. However, the former one is responsible for the deliverable’s breakdown and the project scope, while the latter one highlights the lines of communication. Finally, the WBS cannot replace the project plan or schedule, but should be used only for the visualization of the decomposed work <ref name="limit"/>. | ||
| + | |||
| + | ==Annotated Bibliography== | ||
| + | |||
| + | '''Eric S. Norman, Shelly A. Brotherton, Robert T. Fried. “Work Breakdown Structures''': The Foundation for Project Management Excellence”- John Wiley & Sons, 2008. : The purpose of this book is to provide information about the development processes of the WBS, presenting several concepts for Work Breakdown Structures. | ||
| + | |||
| + | '''Project Management Institute. “Practice Standard for Work Breakdown Structures”- Second Edition, 2011''': This book provides useful guidance for the actual implementation of the WBS in real-life projects. Additionally, it presents all the aspects that lead to the effective use of the WBS, analyzing the development processes. | ||
| + | |||
| + | '''Project Management Institute. “A Guide to the Project Management Body of Knowledge (PMBOK® Guide)”'''- '''Fifth Edition, 2013''': This guide provides substantial information regarding project management, analyzing different concepts. The project scope definition is clearly illustrated using the different tools and techniques of the WBS. | ||
| + | |||
| + | ==References== | ||
<references> | <references> | ||
<ref name="DoD"> DOD and NASA Guide, PERT/COST System Design, June 1962 </ref> | <ref name="DoD"> DOD and NASA Guide, PERT/COST System Design, June 1962 </ref> | ||
| − | <ref name="VA"> Gregory T. Haugan “Effective Work Breakdown Structures”, 2002, Vienna, VA Management Concept | + | <ref name="VA"> Gregory T. Haugan “Effective Work Breakdown Structures”, 2002, Vienna, VA Management Concept </ref> |
<ref name="link"> https://project-management.com/wbs-types-work-breakdown-structure/#100-percent-rule </ref> | <ref name="link"> https://project-management.com/wbs-types-work-breakdown-structure/#100-percent-rule </ref> | ||
<ref name="PMI"> Project Management Institute. “A Guide to the Project Management Body of Knowledge(PMBOK® Guide)”- Fifth Edition, 2013 </ref> | <ref name="PMI"> Project Management Institute. “A Guide to the Project Management Body of Knowledge(PMBOK® Guide)”- Fifth Edition, 2013 </ref> | ||
| + | <ref name="PMI3"> Project Management Institute. “A Guide to the Project Management Body of Knowledge(PMBOK® Guide)”- Third Edition, 2013 </ref> | ||
<ref name="foundation"> Eric S. Norman, Shelly A. Brotherton, Robert T. Fried. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008 </ref> | <ref name="foundation"> Eric S. Norman, Shelly A. Brotherton, Robert T. Fried. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008 </ref> | ||
| + | <ref name="ISO"> Guidance on Project Management, ISO 21500:2012. </ref> | ||
| + | <ref name="WBS"> Project Management Institute. “Practice Standard for Work Breakdown Structures”- Second Edition, 2011. </ref> | ||
| + | <ref name="limit"> https://www.projectsmart.co.uk/pdf/work-breakdown-structure-purpose-process-pitfalls.pdf. Work Breakdown Structure (WBS). Micah Mathis. Project Smart. </ref> | ||
Latest revision as of 15:21, 19 May 2019
Contents |
[edit] History
The Work Break Down Structure (WBS) was developed during 1960s by the U.S. Department of Defense (DoD) and the National Aeronautics and Space Administration (NASA) under the two main pillars of “planning’’ and “controlling’’ the large projects they were responsible for, in order to provide the best quality. Specifically, on June 1962, NASA and DoD published a document regarding PERT/COST which was the first approach to the Work Breakdown Structure. It is worth pointing out, that this guide was adopted in all services as a military standard across DoD [1].
In 1987, this approach of WBS was documented from the Project Management Institute (PMI) in order to provide a generic concept of these techniques for non-defense organizations. Ergo, the Project Management Body of Knowledge (PMBOK) Guide provides an overview of WBS approach for general application through the organizations.
[edit] Definition of Work Breakdown Structure
The Work Breakdown Structure (WBS) is a widely applied tool in the field of project management which is defined as the hierarchical decomposition framework for presenting the work that needs to be executed by the team, in order to achieve the project objectives [2]. Specifically, it creates the backbone of the project and provides a clear visual overview of the work to be completed. WBS is a tool that gives the ability to the project team to develop the project schedule and the resource requirements, to estimate and control the cost, while at the same time to minimize the number of unexpected situations. Therefore, the main purpose of WBS is to organize the team’s work into manageable sections and define the total scope of the project [3].
[edit] WBS Representation
The purpose of the WBS is to communicate the scope of the project to all the relevant project stakeholders. As diverse stakeholders have different needs, different WBS representation methods are required. The most widely used representation views are outline, tabular and tree structure.
The tree structure uses alternative representation types with the organization chart technique being the most common one. As it is presented in figure 1, the root of the tree is on top and the WBS decomposition is performed vertically to the diagram’s bottom.
The tree view representation can be easily modified into other views. The horizontal WBS has the root of tree on the left, whereas the WBS is decomposed horizontally towards the right side of the diagram and it is depicted in figure 2.
The last of the three well known tree views is the centralized tree structure, where the root of the tree is at the center of the WBS diagram and the decomposition elements are moving towards the diagram’s edges. A typical centralized WBS example is illustrated in figure 3. This type of tree representation can be quite powerful during the WBS development phase.
Except for the aforementioned graphical representation of WBS, there are also outline and tabular representation ways in order to communicate more accurately and efficiently the WBS elements to the relevant stakeholders. Figures 4 and 5 present typical examples of tabular and outline WBS views. The main content of the following figures is common, but each one serves different purpose according to the stakeholders that receive and reflect on the information.
In conclusion, it can be summarised that the selection of WBS representation technique depends ultimateley on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others support tables and outlines. As the purpose of the representation is to communicate the WBS to the audience, the final choice should be concentrated on stakeholders’ needs and preferences.
[edit] WBS Decomposition
The decomposition process of the WBS aims to capture the entire project scope by providing the necessary level of details in all the involved stakeholders of the project, in order to achieve the highest level of communication, management and control. The level of details in the WBS is not specific, but varies from project to project and depends on the project’s complexity, the experience of the project team and the need for control. For instance, if the project manager and the project team are experienced and familiar with the tasks to be executed from their involvement in previous projects, the level of detail can remain at a higher level. However, if the project manager or the project team are not experienced, the need for preparation of a very detailed WBS seems essential in order to provide all the necessary information regarding the tasks everyone should accomplish. In that way, the project manager eliminates the risks, ensuring that the project scope is clear in every level.
It is worth pointing out that the full decomposition process does not take place always in the initiation of the project. Especially in large and complex projects, the decomposition of the WBS is partial until further information regarding the processes are known. In some other projects is decided from the project team that only some parts of the WBS can be fully decomposed from the initiation, while other parts can be enriched during the project. This technique is known as the “rolling wave” and demonstrates the flexibility of the WBS’ creation according to the project needs [5].
Another critical point of the WBS decomposition that also varies from project to project is the logic it is based on. The most typical schemes of WBS decomposition are structured according the following [6]:
[edit] Function
In this form of decomposition, the project deliverables are divided into groups according their business function. This style of decomposition aims to enhance the coordination and communication of responsibility to all the involved stakeholders.
[edit] Role
The purpose of a role-based decomposition is similar to the latter one, while it is structured in that way in order to promote the communication of responsibility for the deliverables.
[edit] Method
This type of decomposition is structured on predefined methodologies and in contradiction to the aforementioned, the main purpose is to communicate the project’s outcomes at every level of the WBS among the stakeholders.
[edit] Deliverables
The project deliverables are subdivided into smaller and more manageable components. This form of breakdown is the most common while it is not depended on the organization structure or project type.
In conclusion, the selection of the decomposition logic is critical and should be aligned with the desired outcomes the project manager and project team want to achieve, as well as with the project organisation’s standards.
[edit] The 100% Rule
[edit] Definition
The 100% Rule is one of the most vital principles of WBS, which has been established from the Project Management Institute (PMI), in order to achieve a highly effective WBS and evaluate its decomposition. This rule is defined as: “The next decomposition of a WBS element (“child” level) must represent 100 percent of the work applicable to the next higher (“parent”) element [7].
According to the PMBOK, the total of the work is distributed from the lowest to the higher levels, in order to ensure that nothing is left out and prevent any extra work to be performed. It is also worth pointing out that the 100% rule is not only applied in the work packages of the project, but also in the activity level. More specifically the activities which are represented in each work package should sum up to 100% [8]. However, the use of the 100% Rule should be followed with the clear distinction between the elements of the WBS, since it can cause inadequate communication between the project team, double work and confusion from a financial point of view. Hence, it is suggested to use WBS dictionary to avoid this kind of ambiguities in order to eliminate risks regarding the final project outcome [8].
The 100% Rule provides the project manager with all the necessary information regarding the specific tasks should be performed in each area in order to complete the project and the responsible people for each task. In that way the project manager is aware of the project’s progress and ensures that everything is aligned and related to the WBS elements. The WBS constitutes one of the first steps of the planning process, since it allows all outcomes to be specified before the schedule planning. Another critical aspect of the 100% Rule, is that assists the project manager to ensure that project costs are aligned with the work and every activity is related to the project in order to be completed and finally achieve the desired outcome.
[edit] The 100% Rule Example
The 100% rule is clearly illustrated in the figure 6 which represents the WBS of a project according to the 100% rule’s principles. Specifically, the project consists of a deliverable which is defined in the top level of the WBS regarding the construction of a house. In the second level three deliverables are represented and finally in the third level which consists the lowest level of the WBS, the activities are decomposed into a greater degree as it is required for the completion of the project. The process of decomposition ends when all the necessary information is acquired to achieve the desired outcome.
[edit] WBS tools
There are many tools found in the literature that can help for the creation and the appropriate management of a WBS. Technological innovation during the last decades has contributed in the development of new high-tech tools that tend to replace the low-tech traditional ones. From the oldest pen and paper to the newest sticky notes, it should be mentioned that, although they constitute low-tech means of depiction and outline the project elements, there are effective in terms of group communication and development of WBS [4].
Although the traditional tools remain powerful, new project scheduling tools have arisen as a result of the information technology revolution that offer substantial advantages in the WBS creation. There is a variety of tools in the bibliography, but some of the most common are the following and their main characteristics, advantages and drawbacks are summarised below. They can be used to decide the appropriate tool or combination of tools to support the WBS creation depending on the circumstances and the different needs of the project.
[edit] Project Management Scheduler
It constitutes a useful tool in the field of project management offering the capability of integrating the WBS elements with the project schedule. However, there are many risks that are connected to the usage of project management scheduler. One of the most important ones is that is very difficult to provide a clear differentiation between the WBS and Project schedule elements with a tendency to merge them. Another critical aspect is that the project management scheduler suits properly to task-oriented WBS compared to deliverable-oriented WBS.
[edit] Spreadsheet
When it comes to the spreadsheet, it is recognised as the most powerful tool in terms of creating tabular WBS views. In addition to this, it also offers the competences of creating and managing extensive and complex WBS and combining WBS with WBS dictionary. Yet, there is not efficient visual representation that is an important characteristic for understanding and developing the WBS.
[edit] Word Processor
Even though there are some limitations in terms of large-scale and composite WBSs, it provides substantial level of integration of various WBS views and WBS dictionary.
[edit] Graphics Development
It should be mentioned that Graphics Development is not the ideal suggestion on circumstances related to extensive and complex WBSs. However, it offers visual representation that is a competitive advantage as most of the other tools lack in this feature.
[edit] Enterprise Project Management (EPM)
It is undeniably a powerful tool that has the capability of integrating different and various project management elements such as scope, project scheduling and cost. On the other hand, it is difficult to be implemented and requires significant effort in terms of time and cost. Moreover, the application of the EPM to relatively smaller projects is restricted [7].
Undoubtedly, it can be concluded, from the analysis of the tools conducted above, that there are limitations regarding their utilization. They can often lead to differentiation issues between the WBS elements (deliverables) and there is also uncertainty in the capability of capturing all the necessary information in the life cycle of the project. Ergo, they should not be considered as panacea and their combination with the WBS should be executed properly.
[edit] Potential errors in WBS development
1. Using Unsuitable Former WBS
A common mistake is that a former WBS is used as the foundation for the development of a WBS in a new project. This fact can lead to undesired results since errors and unrequired characteristics can be sustained from the previous WBS.
2. Non-Product Elements
WBS should be in general developed as product-oriented as possible. Since many projects are organized according to their functions, a functional WBS development is conducted. For instance, manufacturing, design, engineering are functions and they are not suitable WBS elements as they are not product oriented. Phase A, Phase B etc. are time plans and they are not product oriented as well. NASA Work Breakdown Structure (WBS) Handbook, 2010 Typical examples of inappropriate phase and function-oriented WBS are presented in the figures below.
3. Incorrect Element Hierarchy
Another important error in WBS development is the lack of hierarchy in the work representation due to inefficient personnel involved in the development of WBS. It is necessary that people with the right knowledge and an adequate understanding of the purpose and the scope of the project, the system and the implementation processes are involved in the WBS development. An incorrect hierarchy of WBS elements is depicted in the following figure.
[edit] Limitations
The WBS is a powerful tool for every project when it is executed properly. However, there are also some limitations that should be seriously considered in order to avoid undesired results. The level of detail for the work packages should remain in the appropriate level providing the necessary information for the project completion. More details than what is actually needed can lead to miscommunication and finally slow down the total progress of the project. Additionally, the WBS should illustrate the breakdown of the project deliverables and not a list of specific tasks and actions, since the latter ones can be modified during the execution of the project compared to the deliverables that cannot me changed without a change request. Furthermore, WBS is often incorrectly confused with the Organizational Hierarchy chart because of their similar characteristics. However, the former one is responsible for the deliverable’s breakdown and the project scope, while the latter one highlights the lines of communication. Finally, the WBS cannot replace the project plan or schedule, but should be used only for the visualization of the decomposed work [9].
[edit] Annotated Bibliography
Eric S. Norman, Shelly A. Brotherton, Robert T. Fried. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008. : The purpose of this book is to provide information about the development processes of the WBS, presenting several concepts for Work Breakdown Structures.
Project Management Institute. “Practice Standard for Work Breakdown Structures”- Second Edition, 2011: This book provides useful guidance for the actual implementation of the WBS in real-life projects. Additionally, it presents all the aspects that lead to the effective use of the WBS, analyzing the development processes.
Project Management Institute. “A Guide to the Project Management Body of Knowledge (PMBOK® Guide)”- Fifth Edition, 2013: This guide provides substantial information regarding project management, analyzing different concepts. The project scope definition is clearly illustrated using the different tools and techniques of the WBS.
[edit] References
- ↑ DOD and NASA Guide, PERT/COST System Design, June 1962
- ↑ Guidance on Project Management, ISO 21500:2012.
- ↑ Project Management Institute. “Practice Standard for Work Breakdown Structures”- Second Edition, 2011.
- ↑ 4.0 4.1 4.2 4.3 4.4 4.5 Eric S. Norman, Shelly A. Brotherton, Robert T. Fried. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008
- ↑ Project Management Institute. “A Guide to the Project Management Body of Knowledge(PMBOK® Guide)”- Third Edition, 2013
- ↑ Project Management Institute. “A Guide to the Project Management Body of Knowledge(PMBOK® Guide)”- Fifth Edition, 2013
- ↑ 7.0 7.1 Gregory T. Haugan “Effective Work Breakdown Structures”, 2002, Vienna, VA Management Concept
- ↑ 8.0 8.1 https://project-management.com/wbs-types-work-breakdown-structure/#100-percent-rule
- ↑ https://www.projectsmart.co.uk/pdf/work-breakdown-structure-purpose-process-pitfalls.pdf. Work Breakdown Structure (WBS). Micah Mathis. Project Smart.
