DTU ProjectLab - User contributions [en-gb]

Work Breakdown Structure (WBS) in Project Management

2019-05-19T14:21:49Z

Thanosfotis:

==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 <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.

==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 <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 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.

[[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==

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="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"/>:

===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.

===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.

===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.

===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.

==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 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>

<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>
<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="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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T14:02:14Z

Thanosfotis:

Work Breakdown Structure (WBS) in Project Management

2019-05-19T14:01:42Z

Thanosfotis:

Work Breakdown Structure (WBS) in Project Management

2019-05-19T14:00:54Z

Thanosfotis:

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:59:45Z

Thanosfotis:

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:49:44Z

Thanosfotis:

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:48:59Z

Thanosfotis:

==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 <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.

==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 <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 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.

[[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==

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="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"/>:

===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.

===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.

===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.

===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.

==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 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>

<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>
<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="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="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>

Stakeholder analysis

2019-05-19T13:48:04Z

Thanosfotis:

=Abstract=
A stakeholder can be shortly described either as an individual, group or organisation who is likely to affect or to be affected by the output of a project, program or portfolio. Companies have already initiated the stakeholder identification in the early 1930's, whereas the first official definition is detected in 1963 at Stanford Research Institute (SRI). However, the original stakeholder definition and stakeholder model owe their origin to Freeman (1984). Stakeholder analysis is a critical step for the success of the project and it aims to identify all the relevant stakeholders, to categorise and prioritise them according to different criteria like their interest, influence and power with the usage of alternative mapping techniques, to profile stakeholders and plan their engagement and, in conclusion, to decide on the stakeholder management processes. A stakeholder analysis should be conducted in the initiation of the project but since it is a dynamic process, it should be updated regularly. Although performing a stakeholder analysis may be a painful and time consuming procedure, it is considered valuable and it should not be neglected.

'''Key words:''' Stakeholder, stakeholder analysis, stakeholder identification, stakeholder prioritisation, stakeholder engagement, stakeholder management, mapping stakeholders, Project Management, Portfolio Management, Program Management

=Stakeholders and stakeholder analysis=
According to the classic definition of stakeholders from Project Management Institute (PMI) that is relevant for any project case “Stakeholders of a project are individuals, groups, or organisations that are affected or recognised to be affected either in a positive or negative way by a decision, action, or output of a project” <ref name="PMI"/>.
Stakeholder analysis is referred as the systematic gathering and analysis of quantitative and qualitative data to decide whose interests should be taken into consideration throughout the project. The objective of performing a stakeholder analysis is to provide the project manager and project team an overview of the people who have interest or influence in the project. It should be one of the first steps of each project and it aims to identify everyone with a concern who needs to be involved.

=History=
The term stakeholder in reference to definition, use and purpose constitutes a quite unclear concept in the literature and it tend to vary over the years. The first time the term ‘stakeholder’ appeared in the bibliography was in 1963 at the Stanford Research Institute (SRI) and originally included owners, employees, customers, supplier, lenders and society. However, it is truth that the business world was thinking and utilising the stakeholder idea many years before 1960s. According to Dodd (1932), GEC was identifying shareholders, employees, customers, and the general public as the main groups that they had to handle. Sapieca (1990) stated that Johnson & Johnson determined in 1947 customers, employees, managers, and the general public as the most important individuals and groups to deal with. Igor Ansoff and Robert Steward developed further the term based on the SRI’s approach <ref name="Theory"/>.
Freeman (1984) presented the definition of stakeholders as “any group or individual who can affect or is affected by the achievement of the organisation objectives” in his book “Strategic Management: A Stakeholder Approach” <ref name="Freeman"/> . This is one of the most popular definitions as 20 out of 75 in total found in the literature share this approach. In the figure below, the original stakeholder model developed from Freeman is presented.

[[File:Freemanmodel.png|1300px|thumb|center|Figure 1: The original stakeholder model Freeman (1984) <ref name="Freeman"/>]]

=Stakeholder analysis process=

There are several approaches regarding the stakeholder analysis process in the bibliography, but most of them have a common philosophy and can be summarised in four principal steps: Identifying, Prioritising, Profiling and Managing Stakeholders. In the initial stage, there is a need of recognising all the people who are affected or influenced by the project and have an interest in a successful or unsuccessful result. Stakeholders can be internal such as managers and employees or external like customers or suppliers. Stakeholders can be also characterised primary with a direct interest and stake to the project (employees, customer, suppliers) or secondary who do not engage in direct exchange but they are affected by or they can affect the project (business partners, competitors, regulatory authorities). The next step is to assess and prioritise stakeholders according to their importance related to the project. Subsequently, stakeholder profiling and engagement and stakeholder management are following in order for the stakeholder analysis to be completed.

===Identify Stakeholders===

The first key step in stakeholder analysis process is to identify all the people (individuals or groups) and organisations that are impacted by the project, and report all relevant information concerning their interests, engagement, influence and effect on project success.
Possible project stakeholders may be people who are <ref name="PMI"/>:
*employed on the project
*sponsoring it or supporting it
*competitors
*contributing to the requirements or are determined to use the final product, process, service, or outcome of the project like regulatory agencies and potential customers
*involved in the marketing and advertising of the product or the service
*responsible for the financial sustainability of the project
*offering goods and services that are consumed by the project (suppliers)
*using the result of the project (customers)

[[File:ISO.png|1300px|thumb|left|Figure 2: Project Stakeholders (ISO 21500:2012) <ref name="ISO"/>]]

There might be also other stakeholders indirectly involved like those contributing in recruitment activities, suppliers who contribute by offering resources to the project, shareholders, those performing administrative and logistic tasks, the project management office that might perform various activities like governance, standardisation, project management trainings and so on. It is of crucial importance that the project team starts with identification of right (and legal) stakeholders, identifying their needs, demands, wishes, preferences dreams and priorities. It is important to take into consideration that stakeholder identification is not a stable activity that is done only in the initial days of the project, but it is a dynamic process that needs to be continuously updated as the project is in progress. Once the stakeholders are identified, they are listed in a stakeholder table or represented in a diagram.

Stakeholders can be categorised in two different main groups: internal and external <ref name="PMI"/>.

'''Internal Stakeholders''' are individuals or groups inside the organisation with a direct interest or influence to the project, for instance employees, owners, and managers. They have substantial interest in the success of the organisation and they are in most cases highly affected by the ongoing activities, decisions, and outcomes of a project.

'''External stakeholders''' are individuals, groups, and organisations that are outside the business area, and they are likely to affect or be affected in a positive or negative way by the outcome of the project. External stakeholder might, for instance, be suppliers, shareholders, regulatory authorities and competitors and undoubtedly the customers.

In order to better understand the different categories of stakeholders, a diagram from '''ISO 21500:2012, Guidance on Project Management''', an international standard developed by the International Organisation for Standardisation, is used. It includes any person inside and outside the project as is represented in figure 2. It categorises the stakeholders in three main groups:

#'''Project organisation''' that includes the project team, the project management team and the project manager.
#'''Project Governance''' that may include the project steering Committee or board and the project Sponsors.
#'''Additional stakeholders''' like employees, customers, suppliers, shareholders, business partners, finance providers, regulatory authorities, Project Management Office (PMO) and stakeholders with special interest.

===Prioritise Stakeholders===

Once the stakeholders are identified, they are listed in a stakeholder table or represented in a diagram. The next step in the stakeholder analysis process is to prioritise the stakeholders and is commonly performed with the use of mapping techniques <ref name="Stakeholders"/>.
Some of the most commonly used mapping techniques constitute the power-interest grid, the power-influence grid, the influence-impact grid, the stakeholder tube and the salience model and they are further analysed below <ref name="Management"/>:

[[File:Interest-influence-stakeholder-matrix.png|thumb|right|1300px|Figure 3: Power/Interest Grid <ref name="TSO"/>]]

'''Power/ Interest Grid''': In the power-interest grid, also known as Power/Interest matrix, the stakeholders are placed on a two-dimensional graph. The horizontal axis represents the interest level whereas the vertical axis symbolises the power and the authority related to the project. For example, on the one hand, in the case that a stakeholder has both a high influence and interest in the project, it is considered as key stakeholder with a high importance in the project. On the other hand, if a stakeholder lacks influence in the project, then he is not likely to affect the project in a high level, even in the case that he has high interest. A typical Power/ Interest grid is presented in figure 3. The Power/ Interest Grid is the one of the most commonly methods for mapping and prioritising stakeholders.

'''Power/ Influence Grid''': The Power/ Interest grid model presents similar structure with the aforementioned model and plots the stakeholders in a two-dimensional graph. The axis Y represents the authority level whereas the axis X the capability to influence the decisions and the output of the project.

'''Influence/ Impact Grid''': The Influence/ Impact Grid plots the stakeholders in a two-dimensional graph, representing their capability to affect the project compared with their ability to cause changes in the project management and execution, and cons in the final outcome.

'''Stakeholder Cube''': The Stakeholder Cube model maps out the stakeholders in a three-dimensional graphical representation and prioritises stakeholders based on their interest, power and attitude.
*Interest (active or passive)
*Power (influential or unsubstantial) and
*Attitude (backer or blocker).

A stakeholder cube is represented in figure 4 to provide a clear overview and better understanding of the model <ref name="Bourne"/>.

[[File:Stakeholder_cube.png‎|thumb|left|1300px|Figure 4: Stakeholder Cube <ref name="Bourne"/>]]
[[File:1.png|900px|thumb|Figure 5: Salience Model <ref name="Bourne"/>]]

'''Salience Model''': The Salience Model assesses and prioritises the various stakeholders according to three different factors: power, legitimacy and urgency in the organisation.

*Power: the capability of stakeholders to force their desire
*Urgency: the necessity for immediate actions
*Legitimacy: the assessment of their involvement to the project's decisions

A graphical representation is used to depict the different stakeholder prioritisation categories that spring from the salience model utilisation.

===Profile Stakeholders===
Next step in stakeholder analysis process is to profile the stakeholders and plan the stakeholder engagement. The main object of this step is to develop approaches to include project stakeholders in regards with their needs, anticipations, interests, and potential influence on the project. The substantial advantage that stakeholder engagement provides is that constitutes an actionable plan to interact efficiently with stakeholders. This process is executed regularly throughout the project according to the project management needs and the most common method is constructing a stakeholder engagement table. <ref name="PMI"/>. There are many aspects that can be included in the stakeholder table and there are different stakeholder engagement tables in the literature. However, most characteristics are common and they usually involved in one of the following categories <ref name="Engagement"/>:
*the stakeholder role in the organisation
*the interest of the stakeholder in the success of a project
* the influence of the stakeholder to the decisions of the project
*the benefits and the disadvantages that the stakeholder has regarding to the project
*the relationship to other stakeholders
*unique facts related to the stakeholder
*expectations and
*an effective way to handle expectations.

===Stakeholder Management Processes===
Identification, prioritisation and engagement of the stakeholders are the main principles that the stakeholder management strategy is based on. According to PMI, one of the most well-known project management techniques for stakeholder management is the communication plan.

The communication plan is an initial and critical step in the stakeholder management process. The objective of this plan is to communicate the project to all the relevant stakeholders and to prioritise issues when forming the communication strategy. There are different channels and strategies for a communication plan.
'''Communicating channels''' can be in general categorised into written and oral means. Written channels can be emails, hard copies, tweets and blogs, whereas the most typical oral means are face to face communication, telephone and video conferencing. Both oral and written channels have advantages and the selection depends on the circumstances and the need for communication [O’Reilly and Pondy 1979] <ref name="Communication"/> .
For instance, oral communication seems to be more effective when there is a need for feedback, different opinions and justifications. On the other hand, oral means tend to be effective when different vocabularies are used between people as they offer the opportunity to study and better understand the message. Except for the benefits of different channels, there are also external limitations in a business unit that lead in the final selection in terms of cost and time. Face to face communication may be more effective in terms of sharing opinions and collaboration. However, it needs time, cost and energy, whereas an email is an efficient, instant and “cheap” channel, but less effective than personal contact.

[[File:Communication_strategies.png‎|thumb|1300px|Figure 6: Amount of information vs Communication Effectiveness <ref name="Communication"/>]]
Except for different channels for a communication plan, there are also various '''communication strategies''' that can be used depending on the willingness of the top management members to share information and details with the employees regarding their content and directionality. Five different communication strategies can be found in the bibliography [Clampitt et al. 2000] <ref name="Communication"/>:

*Spray and Pray
*Tell and sell
*Underscore and explore
*Identify and reply
*Withhold and uphold

The communication strategies' graph depicts the effectiveness in the communication regarding the different communication strategies. As is evident the most effective method is the underscore and explore that balances the optimum ratio of transmitted information and effectiveness.

Auditing the effectiveness of the communication strategy is vital for the success of a project and this can be achieved by using the “regular auditing of communication”, as Hargie and Tourish (2000) recommended. A clear overview of the communication objectives is required answering in questions like: “Who is communicating with whom?”, “What issues are they talking about?”, “Do people understand and use the information they receive?” etc. This discussion aims to clarify ‘what, when, who and how’ [Hayes 2018]. Moreover, it is also worth pointing out that the communication plan should not be based only in the aforementioned questions, especially if it is considered that there are not ready answers to these questions. Ergo, project managers should also focus on how they understand, interpret and finally use the information provided by other people according to the specific circumstances.

=Challenges and uncertainty=
Stakeholder identification and analysis may be an long and painful process. The number of stakeholders constitutes an uncertain factor depended on the circumstances and can vary significantly between different projects. Complex and extensive projects may include more than 50 different stakeholders. Therefore, the analysis require a substantial amount of work in terms of time and cost.

Another important uncertainty regarding this process is the fact that the power, interest, influence and other aspects that are used for the prioritisation process are not measurable parameters and a qualitative data analysis is required to obtain the data. In addition, this process requires a number of assumptions and thus, the robustness of the analysis is questionable.

=Conclusion=

Stakeholder analysis is a powerful tool in the field of project, program and portfolio management. It gives the opportunity to identify the people and groups inside and outside the organisation that can affect or be affected by the outcome of the project, program and portfolio. Understanding the key stakeholders, their interests, power and needs, prioritising them according to different criteria and prepare the stakeholder engagement and management processes creates additional value for the company and contributes significantly to the success of the project. Although it may be a time consuming process, it should never be disregarded and the extent to which should be conducted depends on the circumstances and the requirements of the project, program or portfolio.

=Annotated Bibliography=
'''Freeman, R.E. (1984), Strategic Management: A Stakeholder Approach.'''
The Strategic Management: A Stakeholder Approach published for first time in 1984 provides significant input regarding the stakeholder definition development and history. It also analyses in depth the identification and prioritisation steps, presenting techniques and giving relevant examples.

'''Project Management Institute (2013), A Guide to the Project Management Body of Knowledge (PMBOK® Guide). '''
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is a collection of best practices and tools for project managers providing the foundation of Project, Program and Portfolio Management. It gives the stakeholder definition and substantial information regarding the stakeholder analysis process.

'''Guidance on Project Management, ISO 21500:2012. '''
The International Organisation fo Standardisation developed the Guidance on Project Management, ISO 21500:2012 that provides guidance on concepts and processes of project management that are important for the success of projects. Regarding the stakeholder analysis, it provides significant and detailed input and an useful graphical representation of the different stakeholder categories.

=References=

<references>

<ref name="Freeman">Freeman, R.E. (1984) ''Strategic Management: A Stakeholder Approach. </ref>
<ref name="PMI">Project Management Institute. (2010) ''A Guide to the Project Management Body of Knowledge (PMBOK Guide)'', Project Management Institute. ISBN: 9781930699458, 193069945X </ref>
<ref name="ISO"> Guidance on Project Management, ISO 21500:2012. </ref>
<ref name="Theory">Fontaine C, Haarman A., Schmid S. (2006), The Stakeholder Theory. </ref>
<ref name="Management">Sanguera P. (2018), Managing the Stakeholders. </ref>
<ref name="Stakeholders">Polonsky M. (1996), Stakeholder management and the stakeholder matrix: Potential strategic marketing tools. </ref>
<ref name="Communication">Hayes, J. (2018), “The Theory and Practice of Change Management </ref>
<ref name="Bourne">Bourne L. (2005), Stakeholder Relationship Management </ref>
<ref name="TSO">The Stationery Office(TSO) (2011), Managing Successful Programmes</ref>
<ref name="Engagement"> Schmeer K. (2000), Stakeholder Analysis Guidelines</ref>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:43:57Z

Thanosfotis:

==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 <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.

==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 <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 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.

[[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==

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="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"/>:

===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.

===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.

===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.

===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.

==The 100% Rule==
[[File:WBSexample.png|1300px|thumb|right|Figure 6: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

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>

<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>
<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="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="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>

Stakeholder analysis

2019-05-19T13:42:27Z

Thanosfotis:

=Abstract=
A stakeholder can be shortly described either as an individual, group or organisation who is likely to affect or to be affected by the output of a project, program or portfolio. Companies have already initiated the stakeholder identification in the early 1930's, whereas the first official definition is detected in 1963 at Stanford Research Institute (SRI). However, the original stakeholder definition and stakeholder model owe their origin to Freeman (1984). Stakeholder analysis is a critical step for the success of the project and it aims to identify all the relevant stakeholders, to categorise and prioritise them according to different criteria like their interest, influence and power with the usage of alternative mapping techniques, to profile stakeholders and plan their engagement and, in conclusion, to decide on the stakeholder management processes. A stakeholder analysis should be conducted in the initiation of the project but since it is a dynamic process, it should be updated regularly. Although performing a stakeholder analysis may be a painful and time consuming procedure, it is considered valuable and it should not be neglected.

'''Key words:''' Stakeholder, stakeholder analysis, stakeholder identification, stakeholder prioritisation, stakeholder engagement, stakeholder management, mapping stakeholders, Project Management, Portfolio Management, Program Management

=Stakeholders and stakeholder analysis=
According to the classic definition of stakeholders from Project Management Institute (PMI) that is relevant for any project case “Stakeholders of a project are individuals, groups, or organisations that are affected or recognised to be affected either in a positive or negative way by a decision, action, or output of a project” <ref name="PMI"/>.
Stakeholder analysis is referred as the systematic gathering and analysis of quantitative and qualitative data to decide whose interests should be taken into consideration throughout the project. The objective of performing a stakeholder analysis is to provide the project manager and project team an overview of the people who have interest or influence in the project. It should be one of the first steps of each project and it aims to identify everyone with a concern who needs to be involved.

=History=
The term stakeholder in reference to definition, use and purpose constitutes a quite unclear concept in the literature and it tend to vary over the years. The first time the term ‘stakeholder’ appeared in the bibliography was in 1963 at the Stanford Research Institute (SRI) and originally included owners, employees, customers, supplier, lenders and society. However, it is truth that the business world was thinking and utilising the stakeholder idea many years before 1960s. According to Dodd (1932), GEC was identifying shareholders, employees, customers, and the general public as the main groups that they had to handle. Sapieca (1990) stated that Johnson & Johnson determined in 1947 customers, employees, managers, and the general public as the most important individuals and groups to deal with. Igor Ansoff and Robert Steward developed further the term based on the SRI’s approach <ref name="Theory"/>.
Freeman (1984) presented the definition of stakeholders as “any group or individual who can affect or is affected by the achievement of the organisation objectives” in his book “Strategic Management: A Stakeholder Approach” <ref name="Freeman"/> . This is one of the most popular definitions as 20 out of 75 in total found in the literature share this approach. In the figure below, the original stakeholder model developed from Freeman is presented.

[[File:Freemanmodel.png|1300px|thumb|center|Figure 1: The original stakeholder model Freeman (1984) <ref name="Freeman"/>]]

=Stakeholder analysis process=

There are several approaches regarding the stakeholder analysis process in the bibliography, but most of them have a common philosophy and can be summarised in four principal steps: Identifying, Prioritising, Profiling and Managing Stakeholders. In the initial stage, there is a need of recognising all the people who are affected or influenced by the project and have an interest in a successful or unsuccessful result. Stakeholders can be internal such as managers and employees or external like customers or suppliers. Stakeholders can be also characterised primary with a direct interest and stake to the project (employees, customer, suppliers) or secondary who do not engage in direct exchange but they are affected by or they can affect the project (business partners, competitors, regulatory authorities). The next step is to assess and prioritise stakeholders according to their importance related to the project. Subsequently, stakeholder profiling and engagement and stakeholder management are following in order for the stakeholder analysis to be completed.

===Identify Stakeholders===

The first key step in stakeholder analysis process is to identify all the people (individuals or groups) and organisations that are impacted by the project, and report all relevant information concerning their interests, engagement, influence and effect on project success.
Possible project stakeholders may be people who are <ref name="PMI"/>:
*employed on the project
*sponsoring it or supporting it
*competitors
*contributing to the requirements or are determined to use the final product, process, service, or outcome of the project like regulatory agencies and potential customers
*involved in the marketing and advertising of the product or the service
*responsible for the financial sustainability of the project
*offering goods and services that are consumed by the project (suppliers)
*using the result of the project (customers)

[[File:ISO.png|1300px|thumb|left|Figure 2: Project Stakeholders (ISO 21500:2012) <ref name="ISO"/>]]

There might be also other stakeholders indirectly involved like those contributing in recruitment activities, suppliers who contribute by offering resources to the project, shareholders, those performing administrative and logistic tasks, the project management office that might perform various activities like governance, standardisation, project management trainings and so on. It is of crucial importance that the project team starts with identification of right (and legal) stakeholders, identifying their needs, demands, wishes, preferences dreams and priorities. It is important to take into consideration that stakeholder identification is not a stable activity that is done only in the initial days of the project, but it is a dynamic process that needs to be continuously updated as the project is in progress. Once the stakeholders are identified, they are listed in a stakeholder table or represented in a diagram.

Stakeholders can be categorised in two different main groups: internal and external <ref name="PMI"/>.

'''Internal Stakeholders''' are individuals or groups inside the organisation with a direct interest or influence to the project, for instance employees, owners, and managers. They have substantial interest in the success of the organisation and they are in most cases highly affected by the ongoing activities, decisions, and outcomes of a project.

'''External stakeholders''' are individuals, groups, and organisations that are outside the business area, and they are likely to affect or be affected in a positive or negative way by the outcome of the project. External stakeholder might, for instance, be suppliers, shareholders, regulatory authorities and competitors and undoubtedly the customers.

In order to better understand the different categories of stakeholders, a diagram from '''ISO 21500:2012, Guidance on Project Management''', an international standard developed by the International Organisation for Standardisation, is used. It includes any person inside and outside the project as is represented in the figure below. It categorises the stakeholders in three main groups:

#'''Project organisation''' that includes the project team, the project management team and the project manager.
#'''Project Governance''' that may include the project steering Committee or board and the project Sponsors.
#'''Additional stakeholders''' like employees, customers, suppliers, shareholders, business partners, finance providers, regulatory authorities, Project Management Office (PMO) and stakeholders with special interest.

===Prioritise Stakeholders===

Once the stakeholders are identified, they are listed in a stakeholder table or represented in a diagram. The next step in the stakeholder analysis process is to prioritise the stakeholders and is commonly performed with the use of mapping techniques <ref name="Stakeholders"/>.
Some of the most commonly used mapping techniques constitute the power-interest grid, the power-influence grid, the influence-impact grid, the stakeholder tube and the salience model and they are further analysed below <ref name="Management"/>:

[[File:Interest-influence-stakeholder-matrix.png|thumb|right|1300px|Figure 3: Power/Interest Grid <ref name="TSO"/>]]

'''Power/ Interest Grid''': In the power-interest grid, also known as Power/Interest matrix, the stakeholders are placed on a two-dimensional graph. The horizontal axis represents the interest level whereas the vertical axis symbolises the power and the authority related to the project. For example, on the one hand, in the case that a stakeholder has both a high influence and interest in the project, it is considered as key stakeholder with a high importance in the project. On the other hand, if a stakeholder lacks influence in the project, then he is not likely to affect the project in a high level, even in the case that he has high interest. A typical Power/ Interest grid is presented in figure 3. The Power/ Interest Grid is the one of the most commonly methods for mapping and prioritising stakeholders.

'''Power/ Influence Grid''': The Power/ Interest grid model presents similar structure with the aforementioned model and plots the stakeholders in a two-dimensional graph. The axis Y represents the authority level whereas the axis X the capability to influence the decisions and the output of the project.

'''Influence/ Impact Grid''': The Influence/ Impact Grid plots the stakeholders in a two-dimensional graph, representing their capability to affect the project compared with their ability to cause changes in the project management and execution, and cons in the final outcome.

'''Stakeholder Cube''': The Stakeholder Cube model maps out the stakeholders in a three-dimensional graphical representation and prioritises stakeholders based on their interest, power and attitude.
*Interest (active or passive)
*Power (influential or unsubstantial) and
*Attitude (backer or blocker).

A stakeholder cube is represented in figure 4 to provide a clear overview and better understanding of the model <ref name="Bourne"/>.

[[File:Stakeholder_cube.png‎|thumb|left|1300px|Figure 4: Stakeholder Cube <ref name="Bourne"/>]]
[[File:1.png|900px|thumb|Figure 5: Salience Model <ref name="Bourne"/>]]

'''Salience Model''': The Salience Model assesses and prioritises the various stakeholders according to three different factors: power, legitimacy and urgency in the organisation.

*Power: the capability of stakeholders to force their desire
*Urgency: the necessity for immediate actions
*Legitimacy: the assessment of their involvement to the project's decisions

A graphical representation is used to depict the different stakeholder prioritisation categories that spring from the salience model utilisation.

===Profile Stakeholders===
Next step in stakeholder analysis process is to profile the stakeholders and plan the stakeholder engagement. The main object of this step is to develop approaches to include project stakeholders in regards with their needs, anticipations, interests, and potential influence on the project. The substantial advantage that stakeholder engagement provides is that constitutes an actionable plan to interact efficiently with stakeholders. This process is executed regularly throughout the project according to the project management needs and the most common method is constructing a stakeholder engagement table. <ref name="PMI"/>. There are many aspects that can be included in the stakeholder table and there are different stakeholder engagement tables in the literature. However, most characteristics are common and they usually involved in one of the following categories <ref name="Engagement"/>:
*the stakeholder role in the organisation
*the interest of the stakeholder in the success of a project
* the influence of the stakeholder to the decisions of the project
*the benefits and the disadvantages that the stakeholder has regarding to the project
*the relationship to other stakeholders
*unique facts related to the stakeholder
*expectations and
*an effective way to handle expectations.

===Stakeholder Management Processes===
Identification, prioritisation and engagement of the stakeholders are the main principles that the stakeholder management strategy is based on. According to PMI, one of the most well-known project management techniques for stakeholder management is the communication plan.

The communication plan is an initial and critical step in the stakeholder management process. The objective of this plan is to communicate the project to all the relevant stakeholders and to prioritise issues when forming the communication strategy. There are different channels and strategies for a communication plan.
'''Communicating channels''' can be in general categorised into written and oral means. Written channels can be emails, hard copies, tweets and blogs, whereas the most typical oral means are face to face communication, telephone and video conferencing. Both oral and written channels have advantages and the selection depends on the circumstances and the need for communication [O’Reilly and Pondy 1979] <ref name="Communication"/> .
For instance, oral communication seems to be more effective when there is a need for feedback, different opinions and justifications. On the other hand, oral means tend to be effective when different vocabularies are used between people as they offer the opportunity to study and better understand the message. Except for the benefits of different channels, there are also external limitations in a business unit that lead in the final selection in terms of cost and time. Face to face communication may be more effective in terms of sharing opinions and collaboration. However, it needs time, cost and energy, whereas an email is an efficient, instant and “cheap” channel, but less effective than personal contact.

[[File:Communication_strategies.png‎|thumb|1300px|Figure 6: Amount of information vs Communication Effectiveness <ref name="Communication"/>]]
Except for different channels for a communication plan, there are also various '''communication strategies''' that can be used depending on the willingness of the top management members to share information and details with the employees regarding their content and directionality. Five different communication strategies can be found in the bibliography [Clampitt et al. 2000] <ref name="Communication"/>:

*Spray and Pray
*Tell and sell
*Underscore and explore
*Identify and reply
*Withhold and uphold

The communication strategies' graph depicts the effectiveness in the communication regarding the different communication strategies. As is evident the most effective method is the underscore and explore that balances the optimum ratio of transmitted information and effectiveness.

Auditing the effectiveness of the communication strategy is vital for the success of a project and this can be achieved by using the “regular auditing of communication”, as Hargie and Tourish (2000) recommended. A clear overview of the communication objectives is required answering in questions like: “Who is communicating with whom?”, “What issues are they talking about?”, “Do people understand and use the information they receive?” etc. This discussion aims to clarify ‘what, when, who and how’ [Hayes 2018]. Moreover, it is also worth pointing out that the communication plan should not be based only in the aforementioned questions, especially if it is considered that there are not ready answers to these questions. Ergo, project managers should also focus on how they understand, interpret and finally use the information provided by other people according to the specific circumstances.

=Challenges and uncertainty=
Stakeholder identification and analysis may be an long and painful process. The number of stakeholders constitutes an uncertain factor depended on the circumstances and can vary significantly between different projects. Complex and extensive projects may include more than 50 different stakeholders. Therefore, the analysis require a substantial amount of work in terms of time and cost.

Another important uncertainty regarding this process is the fact that the power, interest, influence and other aspects that are used for the prioritisation process are not measurable parameters and a qualitative data analysis is required to obtain the data. In addition, this process requires a number of assumptions and thus, the robustness of the analysis is questionable.

=Conclusion=

Stakeholder analysis is a powerful tool in the field of project, program and portfolio management. It gives the opportunity to identify the people and groups inside and outside the organisation that can affect or be affected by the outcome of the project, program and portfolio. Understanding the key stakeholders, their interests, power and needs, prioritising them according to different criteria and prepare the stakeholder engagement and management processes creates additional value for the company and contributes significantly to the success of the project. Although it may be a time consuming process, it should never be disregarded and the extent to which should be conducted depends on the circumstances and the requirements of the project, program or portfolio.

=Annotated Bibliography=
'''Freeman, R.E. (1984), Strategic Management: A Stakeholder Approach.'''
The Strategic Management: A Stakeholder Approach published for first time in 1984 provides significant input regarding the stakeholder definition development and history. It also analyses in depth the identification and prioritisation steps, presenting techniques and giving relevant examples.

'''Project Management Institute (2013), A Guide to the Project Management Body of Knowledge (PMBOK® Guide). '''
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is a collection of best practices and tools for project managers providing the foundation of Project, Program and Portfolio Management. It gives the stakeholder definition and substantial information regarding the stakeholder analysis process.

'''Guidance on Project Management, ISO 21500:2012. '''
The International Organisation fo Standardisation developed the Guidance on Project Management, ISO 21500:2012 that provides guidance on concepts and processes of project management that are important for the success of projects. Regarding the stakeholder analysis, it provides significant and detailed input and an useful graphical representation of the different stakeholder categories.

=References=

<references>

<ref name="Freeman">Freeman, R.E. (1984) ''Strategic Management: A Stakeholder Approach. </ref>
<ref name="PMI">Project Management Institute. (2010) ''A Guide to the Project Management Body of Knowledge (PMBOK Guide)'', Project Management Institute. ISBN: 9781930699458, 193069945X </ref>
<ref name="ISO"> Guidance on Project Management, ISO 21500:2012. </ref>
<ref name="Theory">Fontaine C, Haarman A., Schmid S. (2006), The Stakeholder Theory. </ref>
<ref name="Management">Sanguera P. (2018), Managing the Stakeholders. </ref>
<ref name="Stakeholders">Polonsky M. (1996), Stakeholder management and the stakeholder matrix: Potential strategic marketing tools. </ref>
<ref name="Communication">Hayes, J. (2018), “The Theory and Practice of Change Management </ref>
<ref name="Bourne">Bourne L. (2005), Stakeholder Relationship Management </ref>
<ref name="TSO">The Stationery Office(TSO) (2011), Managing Successful Programmes</ref>
<ref name="Engagement"> Schmeer K. (2000), Stakeholder Analysis Guidelines</ref>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:41:43Z

Thanosfotis:

==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 <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.

==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 <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 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.

[[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==

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="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"/>:

===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.

===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.

===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.

===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.

==The 100% Rule==
[[File:WBSexample.png|1300px|thumb|right|Figure 6: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

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 work should be executed. <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>

<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>
<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="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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:40:52Z

Thanosfotis:

==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 <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.

==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 <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 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.

[[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==

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="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"/>:

===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.

===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.

===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.

===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.

==The 100% Rule==
[[File:WBSexample.png|1300px|thumb|right|Figure 6: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

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 undoubtedly 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 work should be executed. <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>

<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>
<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="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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:40:13Z

Thanosfotis:

==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 <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.

==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 <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 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.

[[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==

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="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"/>:

===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.

===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.

===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.

===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.

==The 100% Rule==
[[File:WBSexample.png|1300px|thumb|right|Figure 6: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

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 undoubtedly 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 it 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 work should be executed. <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>

<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>
<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="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="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>

Stakeholder analysis

2019-05-19T13:39:55Z

Thanosfotis:

=Abstract=
A stakeholder can be shortly described either as an individual, group or organisation who is likely to affect or to be affected by the output of a project, program or portfolio. Companies have already initiated the stakeholder identification in the early 1930's, whereas the first official definition is detected in 1963 at Stanford Research Institute (SRI). However, the original stakeholder definition and stakeholder model owe their origin to Freeman (1984). Stakeholder analysis is a critical step for the success of the project and it aims to identify all the relevant stakeholders, to categorise and prioritise them according to different criteria like their interest, influence and power with the usage of alternative mapping techniques, to profile stakeholders and plan their engagement and, in conclusion, to decide on the stakeholder management processes. A stakeholder analysis should be conducted in the initiation of the project but since it is a dynamic process, it should be updated regularly. Although performing a stakeholder analysis may be a painful and time consuming process, it is considered valuable and it should not be neglected.

'''Key words:''' Stakeholder, stakeholder analysis, stakeholder identification, stakeholder prioritisation, stakeholder engagement, stakeholder management, mapping stakeholders, Project Management, Portfolio Management, Program Management

=Stakeholders and stakeholder analysis=
According to the classic definition of stakeholders from Project Management Institute (PMI) that is relevant for any project case “Stakeholders of a project are individuals, groups, or organisations that are affected or recognised to be affected either in a positive or negative way by a decision, action, or output of a project” <ref name="PMI"/>.
Stakeholder analysis is referred as the systematic gathering and analysis of quantitative and qualitative data to decide whose interests should be taken into consideration throughout the project. The objective of performing a stakeholder analysis is to provide the project manager and project team an overview of the people who have interest or influence in the project. It should be one of the first steps of each project and it aims to identify everyone with a concern who needs to be involved.

=History=
The term stakeholder in reference to definition, use and purpose constitutes a quite unclear concept in the literature and it tend to vary over the years. The first time the term ‘stakeholder’ appeared in the bibliography was in 1963 at the Stanford Research Institute (SRI) and originally included owners, employees, customers, supplier, lenders and society. However, it is truth that the business world was thinking and utilising the stakeholder idea many years before 1960s. According to Dodd (1932), GEC was identifying shareholders, employees, customers, and the general public as the main groups that they had to handle. Sapieca (1990) stated that Johnson & Johnson determined in 1947 customers, employees, managers, and the general public as the most important individuals and groups to deal with. Igor Ansoff and Robert Steward developed further the term based on the SRI’s approach <ref name="Theory"/>.
Freeman (1984) presented the definition of stakeholders as “any group or individual who can affect or is affected by the achievement of the organisation objectives” in his book “Strategic Management: A Stakeholder Approach” <ref name="Freeman"/> . This is one of the most popular definitions as 20 out of 75 in total found in the literature share this approach. In the figure below, the original stakeholder model developed from Freeman is presented.

[[File:Freemanmodel.png|1300px|thumb|center|Figure 1: The original stakeholder model Freeman (1984) <ref name="Freeman"/>]]

=Stakeholder analysis process=

There are several approaches regarding the stakeholder analysis process in the bibliography, but most of them have a common philosophy and can be summarised in four principal steps: Identifying, Prioritising, Profiling and Managing Stakeholders. In the initial stage, there is a need of recognising all the people who are affected or influenced by the project and have an interest in a successful or unsuccessful result. Stakeholders can be internal such as managers and employees or external like customers or suppliers. Stakeholders can be also characterised primary with a direct interest and stake to the project (employees, customer, suppliers) or secondary who do not engage in direct exchange but they are affected by or they can affect the project (business partners, competitors, regulatory authorities). The next step is to assess and prioritise stakeholders according to their importance related to the project. Subsequently, stakeholder profiling and engagement and stakeholder management are following in order for the stakeholder analysis to be completed.

===Identify Stakeholders===

The first key step in stakeholder analysis process is to identify all the people (individuals or groups) and organisations that are impacted by the project, and report all relevant information concerning their interests, engagement, influence and effect on project success.
Possible project stakeholders may be people who are <ref name="PMI"/>:
*employed on the project
*sponsoring it or supporting it
*competitors
*contributing to the requirements or are determined to use the final product, process, service, or outcome of the project like regulatory agencies and potential customers
*involved in the marketing and advertising of the product or the service
*responsible for the financial sustainability of the project
*offering goods and services that are consumed by the project (suppliers)
*using the result of the project (customers)

[[File:ISO.png|1300px|thumb|left|Figure 2: Project Stakeholders (ISO 21500:2012) <ref name="ISO"/>]]

There might be also other stakeholders indirectly involved like those contributing in recruitment activities, suppliers who contribute by offering resources to the project, shareholders, those performing administrative and logistic tasks, the project management office that might perform various activities like governance, standardisation, project management trainings and so on. It is of crucial importance that the project team starts with identification of right (and legal) stakeholders, identifying their needs, demands, wishes, preferences dreams and priorities. It is important to take into consideration that stakeholder identification is not a stable activity that is done only in the initial days of the project, but it is a dynamic process that needs to be continuously updated as the project is in progress. Once the stakeholders are identified, they are listed in a stakeholder table or represented in a diagram.

Stakeholders can be categorised in two different main groups: internal and external <ref name="PMI"/>.

'''Internal Stakeholders''' are individuals or groups inside the organisation with a direct interest or influence to the project, for instance employees, owners, and managers. They have substantial interest in the success of the organisation and they are in most cases highly affected by the ongoing activities, decisions, and outcomes of a project.

'''External stakeholders''' are individuals, groups, and organisations that are outside the business area, and they are likely to affect or be affected in a positive or negative way by the outcome of the project. External stakeholder might, for instance, be suppliers, shareholders, regulatory authorities and competitors and undoubtedly the customers.

In order to better understand the different categories of stakeholders, a diagram from '''ISO 21500:2012, Guidance on Project Management''', an international standard developed by the International Organisation for Standardisation, is used. It includes any person inside and outside the project as is represented in the figure below. It categorises the stakeholders in three main groups:

#'''Project organisation''' that includes the project team, the project management team and the project manager.
#'''Project Governance''' that may include the project steering Committee or board and the project Sponsors.
#'''Additional stakeholders''' like employees, customers, suppliers, shareholders, business partners, finance providers, regulatory authorities, Project Management Office (PMO) and stakeholders with special interest.

===Prioritise Stakeholders===

Once the stakeholders are identified, they are listed in a stakeholder table or represented in a diagram. The next step in the stakeholder analysis process is to prioritise the stakeholders and is commonly performed with the use of mapping techniques <ref name="Stakeholders"/>.
Some of the most commonly used mapping techniques constitute the power-interest grid, the power-influence grid, the influence-impact grid, the stakeholder tube and the salience model and they are further analysed below <ref name="Management"/>:

[[File:Interest-influence-stakeholder-matrix.png|thumb|right|1300px|Figure 3: Power/Interest Grid <ref name="TSO"/>]]

'''Power/ Interest Grid''': In the power-interest grid, also known as Power/Interest matrix, the stakeholders are placed on a two-dimensional graph. The horizontal axis represents the interest level whereas the vertical axis symbolises the power and the authority related to the project. For example, on the one hand, in the case that a stakeholder has both a high influence and interest in the project, it is considered as key stakeholder with a high importance in the project. On the other hand, if a stakeholder lacks influence in the project, then he is not likely to affect the project in a high level, even in the case that he has high interest. A typical Power/ Interest grid is presented in figure 3. The Power/ Interest Grid is the one of the most commonly methods for mapping and prioritising stakeholders.

'''Power/ Influence Grid''': The Power/ Interest grid model presents similar structure with the aforementioned model and plots the stakeholders in a two-dimensional graph. The axis Y represents the authority level whereas the axis X the capability to influence the decisions and the output of the project.

'''Influence/ Impact Grid''': The Influence/ Impact Grid plots the stakeholders in a two-dimensional graph, representing their capability to affect the project compared with their ability to cause changes in the project management and execution, and cons in the final outcome.

'''Stakeholder Cube''': The Stakeholder Cube model maps out the stakeholders in a three-dimensional graphical representation and prioritises stakeholders based on their interest, power and attitude.
*Interest (active or passive)
*Power (influential or unsubstantial) and
*Attitude (backer or blocker).

A stakeholder cube is represented in figure 4 to provide a clear overview and better understanding of the model <ref name="Bourne"/>.

[[File:Stakeholder_cube.png‎|thumb|left|1300px|Figure 4: Stakeholder Cube <ref name="Bourne"/>]]
[[File:1.png|900px|thumb|Figure 5: Salience Model <ref name="Bourne"/>]]

'''Salience Model''': The Salience Model assesses and prioritises the various stakeholders according to three different factors: power, legitimacy and urgency in the organisation.

*Power: the capability of stakeholders to force their desire
*Urgency: the necessity for immediate actions
*Legitimacy: the assessment of their involvement to the project's decisions

A graphical representation is used to depict the different stakeholder prioritisation categories that spring from the salience model utilisation.

===Profile Stakeholders===
Next step in stakeholder analysis process is to profile the stakeholders and plan the stakeholder engagement. The main object of this step is to develop approaches to include project stakeholders in regards with their needs, anticipations, interests, and potential influence on the project. The substantial advantage that stakeholder engagement provides is that constitutes an actionable plan to interact efficiently with stakeholders. This process is executed regularly throughout the project according to the project management needs and the most common method is constructing a stakeholder engagement table. <ref name="PMI"/>. There are many aspects that can be included in the stakeholder table and there are different stakeholder engagement tables in the literature. However, most characteristics are common and they usually involved in one of the following categories <ref name="Engagement"/>:
*the stakeholder role in the organisation
*the interest of the stakeholder in the success of a project
* the influence of the stakeholder to the decisions of the project
*the benefits and the disadvantages that the stakeholder has regarding to the project
*the relationship to other stakeholders
*unique facts related to the stakeholder
*expectations and
*an effective way to handle expectations.

===Stakeholder Management Processes===
Identification, prioritisation and engagement of the stakeholders are the main principles that the stakeholder management strategy is based on. According to PMI, one of the most well-known project management techniques for stakeholder management is the communication plan.

The communication plan is an initial and critical step in the stakeholder management process. The objective of this plan is to communicate the project to all the relevant stakeholders and to prioritise issues when forming the communication strategy. There are different channels and strategies for a communication plan.
'''Communicating channels''' can be in general categorised into written and oral means. Written channels can be emails, hard copies, tweets and blogs, whereas the most typical oral means are face to face communication, telephone and video conferencing. Both oral and written channels have advantages and the selection depends on the circumstances and the need for communication [O’Reilly and Pondy 1979] <ref name="Communication"/> .
For instance, oral communication seems to be more effective when there is a need for feedback, different opinions and justifications. On the other hand, oral means tend to be effective when different vocabularies are used between people as they offer the opportunity to study and better understand the message. Except for the benefits of different channels, there are also external limitations in a business unit that lead in the final selection in terms of cost and time. Face to face communication may be more effective in terms of sharing opinions and collaboration. However, it needs time, cost and energy, whereas an email is an efficient, instant and “cheap” channel, but less effective than personal contact.

[[File:Communication_strategies.png‎|thumb|1300px|Figure 6: Amount of information vs Communication Effectiveness <ref name="Communication"/>]]
Except for different channels for a communication plan, there are also various '''communication strategies''' that can be used depending on the willingness of the top management members to share information and details with the employees regarding their content and directionality. Five different communication strategies can be found in the bibliography [Clampitt et al. 2000] <ref name="Communication"/>:

*Spray and Pray
*Tell and sell
*Underscore and explore
*Identify and reply
*Withhold and uphold

The communication strategies' graph depicts the effectiveness in the communication regarding the different communication strategies. As is evident the most effective method is the underscore and explore that balances the optimum ratio of transmitted information and effectiveness.

Auditing the effectiveness of the communication strategy is vital for the success of a project and this can be achieved by using the “regular auditing of communication”, as Hargie and Tourish (2000) recommended. A clear overview of the communication objectives is required answering in questions like: “Who is communicating with whom?”, “What issues are they talking about?”, “Do people understand and use the information they receive?” etc. This discussion aims to clarify ‘what, when, who and how’ [Hayes 2018]. Moreover, it is also worth pointing out that the communication plan should not be based only in the aforementioned questions, especially if it is considered that there are not ready answers to these questions. Ergo, project managers should also focus on how they understand, interpret and finally use the information provided by other people according to the specific circumstances.

=Challenges and uncertainty=
Stakeholder identification and analysis may be an long and painful process. The number of stakeholders constitutes an uncertain factor depended on the circumstances and can vary significantly between different projects. Complex and extensive projects may include more than 50 different stakeholders. Therefore, the analysis require a substantial amount of work in terms of time and cost.

Another important uncertainty regarding this process is the fact that the power, interest, influence and other aspects that are used for the prioritisation process are not measurable parameters and a qualitative data analysis is required to obtain the data. In addition, this process requires a number of assumptions and thus, the robustness of the analysis is questionable.

=Conclusion=

Stakeholder analysis is a powerful tool in the field of project, program and portfolio management. It gives the opportunity to identify the people and groups inside and outside the organisation that can affect or be affected by the outcome of the project, program and portfolio. Understanding the key stakeholders, their interests, power and needs, prioritising them according to different criteria and prepare the stakeholder engagement and management processes creates additional value for the company and contributes significantly to the success of the project. Although it may be a time consuming process, it should never be disregarded and the extent to which should be conducted depends on the circumstances and the requirements of the project, program or portfolio.

=Annotated Bibliography=
'''Freeman, R.E. (1984), Strategic Management: A Stakeholder Approach.'''
The Strategic Management: A Stakeholder Approach published for first time in 1984 provides significant input regarding the stakeholder definition development and history. It also analyses in depth the identification and prioritisation steps, presenting techniques and giving relevant examples.

'''Project Management Institute (2013), A Guide to the Project Management Body of Knowledge (PMBOK® Guide). '''
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is a collection of best practices and tools for project managers providing the foundation of Project, Program and Portfolio Management. It gives the stakeholder definition and substantial information regarding the stakeholder analysis process.

'''Guidance on Project Management, ISO 21500:2012. '''
The International Organisation fo Standardisation developed the Guidance on Project Management, ISO 21500:2012 that provides guidance on concepts and processes of project management that are important for the success of projects. Regarding the stakeholder analysis, it provides significant and detailed input and an useful graphical representation of the different stakeholder categories.

=References=

<references>

<ref name="Freeman">Freeman, R.E. (1984) ''Strategic Management: A Stakeholder Approach. </ref>
<ref name="PMI">Project Management Institute. (2010) ''A Guide to the Project Management Body of Knowledge (PMBOK Guide)'', Project Management Institute. ISBN: 9781930699458, 193069945X </ref>
<ref name="ISO"> Guidance on Project Management, ISO 21500:2012. </ref>
<ref name="Theory">Fontaine C, Haarman A., Schmid S. (2006), The Stakeholder Theory. </ref>
<ref name="Management">Sanguera P. (2018), Managing the Stakeholders. </ref>
<ref name="Stakeholders">Polonsky M. (1996), Stakeholder management and the stakeholder matrix: Potential strategic marketing tools. </ref>
<ref name="Communication">Hayes, J. (2018), “The Theory and Practice of Change Management </ref>
<ref name="Bourne">Bourne L. (2005), Stakeholder Relationship Management </ref>
<ref name="TSO">The Stationery Office(TSO) (2011), Managing Successful Programmes</ref>
<ref name="Engagement"> Schmeer K. (2000), Stakeholder Analysis Guidelines</ref>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:37:55Z

Thanosfotis:

==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 <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.

==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 <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 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.

[[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==

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="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"/>:

===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.

===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.

===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.

===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.

==The 100% Rule==
[[File:WBSexample.png|1300px|thumb|right|Figure 6: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

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 undoubtedly a powerful tool at 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 it 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 work should be executed. <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>

<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>
<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="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="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>

Stakeholder analysis

2019-05-19T13:36:40Z

Thanosfotis:

=Abstract=
A stakeholder can be shortly described either as an individual, group or organisation who is likely to affect or to be affected by the output of a project, program or portfolio. Companies have already initiated the stakeholder identification in the early 1930's, whereas the first official definition is detected in 1963 at Stanford Research Institute (SRI). However, the original stakeholder definition and stakeholder model owe their origin to Freeman (1984). Stakeholder analysis is a critical step for the success of the project and it aims to identify all the relevant stakeholders, to categorise and prioritise them according to different criteria like their interest, influence and power with the usage of alternative mapping techniques, to profile stakeholders and plan their engagement and, in conclusion, to decide on the stakeholder management processes. A stakeholder analysis should be conducted in the initiation of the project but since it is a dynamic process should be updated regularly. Although performing a stakeholder analysis may be a painful and time consuming process, it is considered valuable and it should not be neglected.

'''Key words:''' Stakeholder, stakeholder analysis, stakeholder identification, stakeholder prioritisation, stakeholder engagement, stakeholder management, mapping stakeholders, Project Management, Portfolio Management, Program Management

=Stakeholders and stakeholder analysis=
According to the classic definition of stakeholders from Project Management Institute (PMI) that is relevant for any project case “Stakeholders of a project are individuals, groups, or organisations that are affected or recognised to be affected either in a positive or negative way by a decision, action, or output of a project” <ref name="PMI"/>.
Stakeholder analysis is referred as the systematic gathering and analysis of quantitative and qualitative data to decide whose interests should be taken into consideration throughout the project. The objective of performing a stakeholder analysis is to provide the project manager and project team an overview of the people who have interest or influence in the project. It should be one of the first steps of each project and it aims to identify everyone with a concern who needs to be involved.

=History=
The term stakeholder in reference to definition, use and purpose constitutes a quite unclear concept in the literature and it tend to vary over the years. The first time the term ‘stakeholder’ appeared in the bibliography was in 1963 at the Stanford Research Institute (SRI) and originally included owners, employees, customers, supplier, lenders and society. However, it is truth that the business world was thinking and utilising the stakeholder idea many years before 1960s. According to Dodd (1932), GEC was identifying shareholders, employees, customers, and the general public as the main groups that they had to handle. Sapieca (1990) stated that Johnson & Johnson determined in 1947 customers, employees, managers, and the general public as the most important individuals and groups to deal with. Igor Ansoff and Robert Steward developed further the term based on the SRI’s approach <ref name="Theory"/>.
Freeman (1984) presented the definition of stakeholders as “any group or individual who can affect or is affected by the achievement of the organisation objectives” in his book “Strategic Management: A Stakeholder Approach” <ref name="Freeman"/> . This is one of the most popular definitions as 20 out of 75 in total found in the literature share this approach. In the figure below, the original stakeholder model developed from Freeman is presented.

[[File:Freemanmodel.png|1300px|thumb|center|Figure 1: The original stakeholder model Freeman (1984) <ref name="Freeman"/>]]

=Stakeholder analysis process=

There are several approaches regarding the stakeholder analysis process in the bibliography, but most of them have a common philosophy and can be summarised in four principal steps: Identifying, Prioritising, Profiling and Managing Stakeholders. In the initial stage, there is a need of recognising all the people who are affected or influenced by the project and have an interest in a successful or unsuccessful result. Stakeholders can be internal such as managers and employees or external like customers or suppliers. Stakeholders can be also characterised primary with a direct interest and stake to the project (employees, customer, suppliers) or secondary who do not engage in direct exchange but they are affected by or they can affect the project (business partners, competitors, regulatory authorities). The next step is to assess and prioritise stakeholders according to their importance related to the project. Subsequently, stakeholder profiling and engagement and stakeholder management are following in order for the stakeholder analysis to be completed.

===Identify Stakeholders===

The first key step in stakeholder analysis process is to identify all the people (individuals or groups) and organisations that are impacted by the project, and report all relevant information concerning their interests, engagement, influence and effect on project success.
Possible project stakeholders may be people who are <ref name="PMI"/>:
*employed on the project
*sponsoring it or supporting it
*competitors
*contributing to the requirements or are determined to use the final product, process, service, or outcome of the project like regulatory agencies and potential customers
*involved in the marketing and advertising of the product or the service
*responsible for the financial sustainability of the project
*offering goods and services that are consumed by the project (suppliers)
*using the result of the project (customers)

[[File:ISO.png|1300px|thumb|left|Figure 2: Project Stakeholders (ISO 21500:2012) <ref name="ISO"/>]]

There might be also other stakeholders indirectly involved like those contributing in recruitment activities, suppliers who contribute by offering resources to the project, shareholders, those performing administrative and logistic tasks, the project management office that might perform various activities like governance, standardisation, project management trainings and so on. It is of crucial importance that the project team starts with identification of right (and legal) stakeholders, identifying their needs, demands, wishes, preferences dreams and priorities. It is important to take into consideration that stakeholder identification is not a stable activity that is done only in the initial days of the project, but it is a dynamic process that needs to be continuously updated as the project is in progress. Once the stakeholders are identified, they are listed in a stakeholder table or represented in a diagram.

Stakeholders can be categorised in two different main groups: internal and external <ref name="PMI"/>.

'''Internal Stakeholders''' are individuals or groups inside the organisation with a direct interest or influence to the project, for instance employees, owners, and managers. They have substantial interest in the success of the organisation and they are in most cases highly affected by the ongoing activities, decisions, and outcomes of a project.

'''External stakeholders''' are individuals, groups, and organisations that are outside the business area, and they are likely to affect or be affected in a positive or negative way by the outcome of the project. External stakeholder might, for instance, be suppliers, shareholders, regulatory authorities and competitors and undoubtedly the customers.

In order to better understand the different categories of stakeholders, a diagram from '''ISO 21500:2012, Guidance on Project Management''', an international standard developed by the International Organisation for Standardisation, is used. It includes any person inside and outside the project as is represented in the figure below. It categorises the stakeholders in three main groups:

#'''Project organisation''' that includes the project team, the project management team and the project manager.
#'''Project Governance''' that may include the project steering Committee or board and the project Sponsors.
#'''Additional stakeholders''' like employees, customers, suppliers, shareholders, business partners, finance providers, regulatory authorities, Project Management Office (PMO) and stakeholders with special interest.

===Prioritise Stakeholders===

Once the stakeholders are identified, they are listed in a stakeholder table or represented in a diagram. The next step in the stakeholder analysis process is to prioritise the stakeholders and is commonly performed with the use of mapping techniques <ref name="Stakeholders"/>.
Some of the most commonly used mapping techniques constitute the power-interest grid, the power-influence grid, the influence-impact grid, the stakeholder tube and the salience model and they are further analysed below <ref name="Management"/>:

[[File:Interest-influence-stakeholder-matrix.png|thumb|right|1300px|Figure 3: Power/Interest Grid <ref name="TSO"/>]]

'''Power/ Interest Grid''': In the power-interest grid, also known as Power/Interest matrix, the stakeholders are placed on a two-dimensional graph. The horizontal axis represents the interest level whereas the vertical axis symbolises the power and the authority related to the project. For example, on the one hand, in the case that a stakeholder has both a high influence and interest in the project, it is considered as key stakeholder with a high importance in the project. On the other hand, if a stakeholder lacks influence in the project, then he is not likely to affect the project in a high level, even in the case that he has high interest. A typical Power/ Interest grid is presented in figure 3. The Power/ Interest Grid is the one of the most commonly methods for mapping and prioritising stakeholders.

'''Power/ Influence Grid''': The Power/ Interest grid model presents similar structure with the aforementioned model and plots the stakeholders in a two-dimensional graph. The axis Y represents the authority level whereas the axis X the capability to influence the decisions and the output of the project.

'''Influence/ Impact Grid''': The Influence/ Impact Grid plots the stakeholders in a two-dimensional graph, representing their capability to affect the project compared with their ability to cause changes in the project management and execution, and cons in the final outcome.

'''Stakeholder Cube''': The Stakeholder Cube model maps out the stakeholders in a three-dimensional graphical representation and prioritises stakeholders based on their interest, power and attitude.
*Interest (active or passive)
*Power (influential or unsubstantial) and
*Attitude (backer or blocker).

A stakeholder cube is represented in figure 4 to provide a clear overview and better understanding of the model <ref name="Bourne"/>.

[[File:Stakeholder_cube.png‎|thumb|left|1300px|Figure 4: Stakeholder Cube <ref name="Bourne"/>]]
[[File:1.png|900px|thumb|Figure 5: Salience Model <ref name="Bourne"/>]]

'''Salience Model''': The Salience Model assesses and prioritises the various stakeholders according to three different factors: power, legitimacy and urgency in the organisation.

*Power: the capability of stakeholders to force their desire
*Urgency: the necessity for immediate actions
*Legitimacy: the assessment of their involvement to the project's decisions

A graphical representation is used to depict the different stakeholder prioritisation categories that spring from the salience model utilisation.

===Profile Stakeholders===
Next step in stakeholder analysis process is to profile the stakeholders and plan the stakeholder engagement. The main object of this step is to develop approaches to include project stakeholders in regards with their needs, anticipations, interests, and potential influence on the project. The substantial advantage that stakeholder engagement provides is that constitutes an actionable plan to interact efficiently with stakeholders. This process is executed regularly throughout the project according to the project management needs and the most common method is constructing a stakeholder engagement table. <ref name="PMI"/>. There are many aspects that can be included in the stakeholder table and there are different stakeholder engagement tables in the literature. However, most characteristics are common and they usually involved in one of the following categories <ref name="Engagement"/>:
*the stakeholder role in the organisation
*the interest of the stakeholder in the success of a project
* the influence of the stakeholder to the decisions of the project
*the benefits and the disadvantages that the stakeholder has regarding to the project
*the relationship to other stakeholders
*unique facts related to the stakeholder
*expectations and
*an effective way to handle expectations.

===Stakeholder Management Processes===
Identification, prioritisation and engagement of the stakeholders are the main principles that the stakeholder management strategy is based on. According to PMI, one of the most well-known project management techniques for stakeholder management is the communication plan.

The communication plan is an initial and critical step in the stakeholder management process. The objective of this plan is to communicate the project to all the relevant stakeholders and to prioritise issues when forming the communication strategy. There are different channels and strategies for a communication plan.
'''Communicating channels''' can be in general categorised into written and oral means. Written channels can be emails, hard copies, tweets and blogs, whereas the most typical oral means are face to face communication, telephone and video conferencing. Both oral and written channels have advantages and the selection depends on the circumstances and the need for communication [O’Reilly and Pondy 1979] <ref name="Communication"/> .
For instance, oral communication seems to be more effective when there is a need for feedback, different opinions and justifications. On the other hand, oral means tend to be effective when different vocabularies are used between people as they offer the opportunity to study and better understand the message. Except for the benefits of different channels, there are also external limitations in a business unit that lead in the final selection in terms of cost and time. Face to face communication may be more effective in terms of sharing opinions and collaboration. However, it needs time, cost and energy, whereas an email is an efficient, instant and “cheap” channel, but less effective than personal contact.

[[File:Communication_strategies.png‎|thumb|1300px|Figure 6: Amount of information vs Communication Effectiveness <ref name="Communication"/>]]
Except for different channels for a communication plan, there are also various '''communication strategies''' that can be used depending on the willingness of the top management members to share information and details with the employees regarding their content and directionality. Five different communication strategies can be found in the bibliography [Clampitt et al. 2000] <ref name="Communication"/>:

*Spray and Pray
*Tell and sell
*Underscore and explore
*Identify and reply
*Withhold and uphold

The communication strategies' graph depicts the effectiveness in the communication regarding the different communication strategies. As is evident the most effective method is the underscore and explore that balances the optimum ratio of transmitted information and effectiveness.

Auditing the effectiveness of the communication strategy is vital for the success of a project and this can be achieved by using the “regular auditing of communication”, as Hargie and Tourish (2000) recommended. A clear overview of the communication objectives is required answering in questions like: “Who is communicating with whom?”, “What issues are they talking about?”, “Do people understand and use the information they receive?” etc. This discussion aims to clarify ‘what, when, who and how’ [Hayes 2018]. Moreover, it is also worth pointing out that the communication plan should not be based only in the aforementioned questions, especially if it is considered that there are not ready answers to these questions. Ergo, project managers should also focus on how they understand, interpret and finally use the information provided by other people according to the specific circumstances.

=Challenges and uncertainty=
Stakeholder identification and analysis may be an long and painful process. The number of stakeholders constitutes an uncertain factor depended on the circumstances and can vary significantly between different projects. Complex and extensive projects may include more than 50 different stakeholders. Therefore, the analysis require a substantial amount of work in terms of time and cost.

Another important uncertainty regarding this process is the fact that the power, interest, influence and other aspects that are used for the prioritisation process are not measurable parameters and a qualitative data analysis is required to obtain the data. In addition, this process requires a number of assumptions and thus, the robustness of the analysis is questionable.

=Conclusion=

Stakeholder analysis is a powerful tool in the field of project, program and portfolio management. It gives the opportunity to identify the people and groups inside and outside the organisation that can affect or be affected by the outcome of the project, program and portfolio. Understanding the key stakeholders, their interests, power and needs, prioritising them according to different criteria and prepare the stakeholder engagement and management processes creates additional value for the company and contributes significantly to the success of the project. Although it may be a time consuming process, it should never be disregarded and the extent to which should be conducted depends on the circumstances and the requirements of the project, program or portfolio.

=Annotated Bibliography=
'''Freeman, R.E. (1984), Strategic Management: A Stakeholder Approach.'''
The Strategic Management: A Stakeholder Approach published for first time in 1984 provides significant input regarding the stakeholder definition development and history. It also analyses in depth the identification and prioritisation steps, presenting techniques and giving relevant examples.

'''Project Management Institute (2013), A Guide to the Project Management Body of Knowledge (PMBOK® Guide). '''
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is a collection of best practices and tools for project managers providing the foundation of Project, Program and Portfolio Management. It gives the stakeholder definition and substantial information regarding the stakeholder analysis process.

'''Guidance on Project Management, ISO 21500:2012. '''
The International Organisation fo Standardisation developed the Guidance on Project Management, ISO 21500:2012 that provides guidance on concepts and processes of project management that are important for the success of projects. Regarding the stakeholder analysis, it provides significant and detailed input and an useful graphical representation of the different stakeholder categories.

=References=

<references>

<ref name="Freeman">Freeman, R.E. (1984) ''Strategic Management: A Stakeholder Approach. </ref>
<ref name="PMI">Project Management Institute. (2010) ''A Guide to the Project Management Body of Knowledge (PMBOK Guide)'', Project Management Institute. ISBN: 9781930699458, 193069945X </ref>
<ref name="ISO"> Guidance on Project Management, ISO 21500:2012. </ref>
<ref name="Theory">Fontaine C, Haarman A., Schmid S. (2006), The Stakeholder Theory. </ref>
<ref name="Management">Sanguera P. (2018), Managing the Stakeholders. </ref>
<ref name="Stakeholders">Polonsky M. (1996), Stakeholder management and the stakeholder matrix: Potential strategic marketing tools. </ref>
<ref name="Communication">Hayes, J. (2018), “The Theory and Practice of Change Management </ref>
<ref name="Bourne">Bourne L. (2005), Stakeholder Relationship Management </ref>
<ref name="TSO">The Stationery Office(TSO) (2011), Managing Successful Programmes</ref>
<ref name="Engagement"> Schmeer K. (2000), Stakeholder Analysis Guidelines</ref>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:36:19Z

Thanosfotis:

==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 <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.

==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 <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 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 are supporters of 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==

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="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"/>:

===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.

===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.

===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.

===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.

==The 100% Rule==
[[File:WBSexample.png|1300px|thumb|right|Figure 6: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

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 undoubtedly a powerful tool at 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 it 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 work should be executed. <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>

<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>
<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="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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:35:07Z

Thanosfotis:

==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 <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.

==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 <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 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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==

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="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"/>:

===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.

===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.

===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.

===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.

==The 100% Rule==
[[File:WBSexample.png|1300px|thumb|right|Figure 6: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

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 undoubtedly a powerful tool at 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 it 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 work should be executed. <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>

<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>
<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="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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:33:32Z

Thanosfotis:

==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 <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.

==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 <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 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 that they are likely 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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==

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="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"/>:

===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.

===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.

===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.

===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.

==The 100% Rule==
[[File:WBSexample.png|1300px|thumb|right|Figure 6: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

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 undoubtedly a powerful tool at 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 it 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 work should be executed. <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>

<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>
<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="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="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>

File:WBSexample.png

2019-05-19T13:32:21Z

Thanosfotis: Thanosfotis uploaded a new version of "File:WBSexample.png"

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:30:56Z

Thanosfotis:

==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 <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.

==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 <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 the figure 1, in this view 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 the 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 the 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 that they are likely 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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==

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="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"/>:

===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.

===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.

===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.

===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.

==The 100% Rule==
[[File:WBSexample.png|1300px|thumb|right|Figure 6: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

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 undoubtedly a powerful tool at 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 it 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 work should be executed. <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>

<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>
<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="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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:29:44Z

Thanosfotis:

==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 <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.

==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 <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 the figure 1, in this view 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 the 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 the 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 that they are likely 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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==

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="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"/>:

===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.

===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.

===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.

===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.

==The 100% Rule==
[[File:WBSexample.png|1300px|thumb|right|Figure 6: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

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 undoubtedly a powerful tool at 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 it 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 work should be executed. <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>

<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>
<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="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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:27:40Z

Thanosfotis:

==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 <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.

==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 <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 the figure 1, in this view 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 the 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 the 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 that they are likely 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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==

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="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"/>:

===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.

===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.

===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.

===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.

==The 100% Rule==
[[File:WBSexample.png|1300px|thumb|right|Figure 6: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

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 undoubtedly a powerful tool at 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 it 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 work should be executed. <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>

<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>
<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="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="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>

Stakeholder analysis

2019-05-19T13:22:43Z

Thanosfotis:

=Abstract=
A stakeholder can be shortly described either as an individual, group or organisation who is likely to affect or to be affected by the output of a project, program or portfolio. Companies have already initiated the stakeholder identification in the early 1930's, whereas the first official definition is detected in 1963 at Stanford Research Institute (SRI). However, the original stakeholder definition and stakeholder model owe their origin to Freeman (1984). Stakeholder analysis is a critical step for the success of the project and it aims to identify all the relevant stakeholders, to categorise and prioritise them according to different criteria like their interest, influence and power with the usage of alternative mapping techniques, to profile stakeholders and plan their engagement and, in conclusion, to decide on the stakeholder management processes. A stakeholder analysis should be conducted in the initiation of the project but since it is a dynamic process should be updated regularly. Although performing a stakeholder analysis may be a painful and time consuming process, it is considered valuable and it should not be neglected.

'''Key words:''' Stakeholder, stakeholder analysis, stakeholder identification, stakeholder prioritisation, stakeholder engagement, stakeholder management, mapping stakeholders, Project Management, Portfolio Management, Program Management

=Stakeholders and stakeholder analysis=
According to the classic definition of stakeholders from Project Management Institute (PMI) that is relevant for any project case “Stakeholders of a project are individuals, groups, or organisations that are affected or recognised to be affected either in a positive or negative way by a decision, action, or output of a project” <ref name="PMI"/>.
Stakeholder analysis is referred as the systematic gathering and analysis of quantitative and qualitative data to decide whose interests should be taken into consideration throughout the project. The objective of performing a stakeholder analysis is to provide the project manager and project team an overview of the people who have interest or influence in the project. It should be one of the first steps of each project and it aims to identify everyone with a concern who needs to be involved.

=History=
The term stakeholder in reference to definition, use and purpose constitutes a quite unclear concept in the literature and it tend to vary over the years. The first time the term ‘stakeholder’ appeared in the bibliography was in 1963 at the Stanford Research Institute (SRI) and originally included owners, employees, customers, supplier, lenders and society. However, it is truth that the business world was thinking and utilising the stakeholder idea many years before 1960s. According to Dodd (1932), GEC was identifying shareholders, employees, customers, and the general public as the main groups that they had to handle. Sapieca (1990) stated that Johnson & Johnson determined in 1947 customers, employees, managers, and the general public as the most important individuals and groups to deal with. Igor Ansoff and Robert Steward developed further the term based on the SRI’s approach <ref name="Theory"/>.
Freeman (1984) presented the definition of stakeholders as “any group or individual who can affect or is affected by the achievement of the organisation objectives” in his book “Strategic Management: A Stakeholder Approach” <ref name="Freeman"/> . This is one of the most popular definitions as 20 out of 75 in total found in the literature share this approach. In the figure below, the original stakeholder model developed from Freeman is presented.

[[File:Freemanmodel.png|1300px|thumb|center|Figure 1: The original stakeholder model Freeman (1984) <ref name="Freeman"/>]]

=Stakeholder analysis process=

There are several approaches regarding the stakeholder analysis process in the bibliography, but most of them have a common philosophy and can be summarised in four principal steps: Identifying, Prioritising, Profiling and Managing Stakeholders. In the initial stage, there is a need of recognising all the people who are affected or influenced by the project and have an interest in a successful or unsuccessful result. Stakeholders can be internal such as managers and employees or external like customers or suppliers. Stakeholders can be also characterised primary with a direct interest and stake to the project (employees, customer, suppliers) or secondary who do not engage in direct exchange but they are affected by or they can affect the project (business partners, competitors, regulatory authorities). The next step is to assess and prioritise stakeholders according to their importance related to the project. Subsequently, stakeholder profiling and engagement and stakeholder management are following in order for the stakeholder analysis to be completed.

===Identify Stakeholders===

The first key step in stakeholder analysis process is to identify all the people (individuals or groups) and organisations that are impacted by the project, and report all relevant information concerning their interests, engagement, influence and effect on project success.
Possible project stakeholders may be people who are <ref name="PMI"/>:
*employed on the project
*sponsoring it or supporting it
*competitors
*contributing to the requirements or are determined to use the final product, process, service, or outcome of the project like regulatory agencies and potential customers
*involved in the marketing and advertising of the product or the service
*responsible for the financial sustainability of the project
*offering goods and services that are consumed by the project (suppliers)
*using the result of the project (customers)

[[File:ISO.png|1300px|thumb|left|Figure 2: Project Stakeholders (ISO 21500:2012) <ref name="ISO"/>]]

There might be also other stakeholders indirectly involved like those contributing in recruitment activities, suppliers who contribute by offering resources to the project, shareholders, those performing administrative and logistic tasks, the project management office that might perform various activities like governance, standardisation, project management trainings and so on. It is of crucial importance that the project team starts with identification of right (and legal) stakeholders, identifying their needs, demands, wishes, preferences dreams and priorities. It is important to take into consideration that stakeholder identification is not a stable activity that is done only in the initial days of the project, but it is a dynamic process that needs to be continuously updated as the project is in progress. Once the stakeholders are identified, they are listed in a stakeholder table or represented in a diagram.

Stakeholders can be categorised in two different main groups: internal and external <ref name="PMI"/>.

'''Internal Stakeholders''' are individuals or groups inside the organisation with a direct interest or influence to the project, for instance employees, owners, and managers. They have substantial interest in the success of the organisation and they are in most cases highly affected by the ongoing activities, decisions, and outcomes of a project.

'''External stakeholders''' are individuals, groups, and organisations that are outside the business area, and they are likely to affect or be affected in a positive or negative way by the outcome of the project. External stakeholder might, for instance, be suppliers, shareholders, regulatory authorities and competitors and undoubtedly the customers.

In order to better understand the different categories of stakeholders, a diagram from '''ISO 21500:2012, Guidance on Project Management''', an international standard developed by the International Organisation for Standardisation, is used. It includes any person inside and outside the project as is represented in the figure below. It categorises the stakeholders in three main groups:

#'''Project organisation''' that includes the project team, the project management team and the project manager.
#'''Project Governance''' that may include the project steering Committee or board and the project Sponsors.
#'''Additional stakeholders''' like employees, customers, suppliers, shareholders, business partners, finance providers, regulatory authorities, Project Management Office (PMO) and stakeholders with special interest.

===Prioritise Stakeholders===

Once the stakeholders are identified, they are listed in a stakeholder table or represented in a diagram. The next step in the stakeholder analysis process is to prioritise the stakeholders and is commonly performed with the use of mapping techniques <ref name="Stakeholders"/>.
Some of the most commonly used mapping techniques constitute the power-interest grid, the power-influence grid, the influence-impact grid, the stakeholder tube and the salience model and they are further analysed below <ref name="Management"/>:

[[File:Interest-influence-stakeholder-matrix.png|thumb|right|1300px|Figure 3: Power/Interest Grid <ref name="TSO"/>]]

'''Power/ Interest Grid''': In the power-interest grid, also known as Power/Interest matrix, the stakeholders are placed on a two-dimensional graph. The horizontal axis represents the interest level whereas the vertical axis symbolises the power and the authority related to the project. For example, on the one hand, in the case that a stakeholder has both a high influence and interest in the project, it is considered as key stakeholder with a high importance in the project. On the other hand, if a stakeholder lacks influence in the project, then he is not likely to affect the project in a high level, even in the case that he has high interest. A typical Power/ Interest grid is presented in figure 3. The Power/ Interest Grid is the one of the most commonly methods for mapping and prioritising stakeholders.

'''Power/ Influence Grid''': The Power/ Interest grid model presents similar structure with the aforementioned model and plots the stakeholders in a two-dimensional graph. The axis Y represents the authority level whereas the axis X the capability to influence the decisions and the output of the project.

'''Influence/ Impact Grid''': The Influence/ Impact Grid plots the stakeholders in a two-dimensional graph, representing their capability to affect the project compared with their ability to cause changes in the project management and execution, and cons in the final outcome.

'''Stakeholder Cube''': The Stakeholder Cube model maps out the stakeholders in a three-dimensional graphical representation and prioritises stakeholders based on their interest, power and attitude.
*Interest (active or passive)
*Power (influential or unsubstantial) and
*Attitude (backer or blocker).

A stakeholder cube is represented in the figure 4 to provide a clear overview and better understanding of the model <ref name="Bourne"/>.

[[File:Stakeholder_cube.png‎|thumb|left|1300px|Figure 4: Stakeholder Cube <ref name="Bourne"/>]]
[[File:1.png|900px|thumb|Figure 5: Salience Model <ref name="Bourne"/>]]

'''Salience Model''': The Salience Model assesses and prioritises the various stakeholders according to three different factors: power, legitimacy and urgency in the organisation.

*Power: the capability of stakeholders to force their desire
*Urgency: the necessity for immediate actions
*Legitimacy: the assessment of their involvement to the project's decisions

A graphical representation is used to depict the different stakeholder prioritisation categories that spring from the salience model utilisation.

===Profile Stakeholders===
Next step in stakeholder analysis process is to profile the stakeholders and plan the stakeholder engagement. The main object of this step is to develop approaches to include project stakeholders in regards with their needs, anticipations, interests, and potential influence on the project. The substantial advantage that stakeholder engagement provides is that constitutes an actionable plan to interact efficiently with stakeholders. This process is executed regularly throughout the project according to the project management needs and the most common method is constructing a stakeholder engagement table. <ref name="PMI"/>. There are many aspects that can be included in the stakeholder table and there are different stakeholder engagement tables in the literature. However, most characteristics are common and they usually involved in one of the following categories <ref name="Engagement"/>:
*the stakeholder role in the organisation
*the interest of the stakeholder in the success of a project
* the influence of the stakeholder to the decisions of the project
*the benefits and the disadvantages that the stakeholder has regarding to the project
*the relationship to other stakeholders
*unique facts related to the stakeholder
*expectations and
*an effective way to handle expectations.

===Stakeholder Management Processes===
Identification, prioritisation and engagement of the stakeholders are the main principles that the stakeholder management strategy is based on. According to PMI, one of the most well-known project management techniques for stakeholder management is the communication plan.

The communication plan is an initial and critical step in the stakeholder management process. The objective of this plan is to communicate the project to all the relevant stakeholders and to prioritise issues when forming the communication strategy. There are different channels and strategies for a communication plan.
'''Communicating channels''' can be in general categorised into written and oral means. Written channels can be emails, hard copies, tweets and blogs, whereas the most typical oral means are face to face communication, telephone and video conferencing. Both oral and written channels have advantages and the selection depends on the circumstances and the need for communication [O’Reilly and Pondy 1979] <ref name="Communication"/> .
For instance, oral communication seems to be more effective when there is a need for feedback, different opinions and justifications. On the other hand, oral means tend to be effective when different vocabularies are used between people as they offer the opportunity to study and better understand the message. Except for the benefits of different channels, there are also external limitations in a business unit that lead in the final selection in terms of cost and time. Face to face communication may be more effective in terms of sharing opinions and collaboration. However, it needs time, cost and energy, whereas an email is an efficient, instant and “cheap” channel, but less effective than personal contact.

[[File:Communication_strategies.png‎|thumb|1300px|Figure 6: Amount of information vs Communication Effectiveness <ref name="Communication"/>]]
Except for different channels for a communication plan, there are also various '''communication strategies''' that can be used depending on the willingness of the top management members to share information and details with the employees regarding their content and directionality. Five different communication strategies can be found in the bibliography [Clampitt et al. 2000] <ref name="Communication"/>:

*Spray and Pray
*Tell and sell
*Underscore and explore
*Identify and reply
*Withhold and uphold

The communication strategies' graph depicts the effectiveness in the communication regarding the different communication strategies. As is evident the most effective method is the underscore and explore that balances the optimum ratio of transmitted information and effectiveness.

Auditing the effectiveness of the communication strategy is vital for the success of a project and this can be achieved by using the “regular auditing of communication”, as Hargie and Tourish (2000) recommended. A clear overview of the communication objectives is required answering in questions like: “Who is communicating with whom?”, “What issues are they talking about?”, “Do people understand and use the information they receive?” etc. This discussion aims to clarify ‘what, when, who and how’ [Hayes 2018]. Moreover, it is also worth pointing out that the communication plan should not be based only in the aforementioned questions, especially if it is considered that there are not ready answers to these questions. Ergo, project managers should also focus on how they understand, interpret and finally use the information provided by other people according to the specific circumstances.

=Challenges and uncertainty=
Stakeholder identification and analysis may be an long and painful process. The number of stakeholders constitutes an uncertain factor depended on the circumstances and can vary significantly between different projects. Complex and extensive projects may include more than 50 different stakeholders. Therefore, the analysis require a substantial amount of work in terms of time and cost.

Another important uncertainty regarding this process is the fact that the power, interest, influence and other aspects that are used for the prioritisation process are not measurable parameters and a qualitative data analysis is required to obtain the data. In addition, this process requires a number of assumptions and thus, the robustness of the analysis is questionable.

=Conclusion=

Stakeholder analysis is a powerful tool in the field of project, program and portfolio management. It gives the opportunity to identify the people and groups inside and outside the organisation that can affect or be affected by the outcome of the project, program and portfolio. Understanding the key stakeholders, their interests, power and needs, prioritising them according to different criteria and prepare the stakeholder engagement and management processes creates additional value for the company and contributes significantly to the success of the project. Although it may be a time consuming process, it should never be disregarded and the extent to which should be conducted depends on the circumstances and the requirements of the project, program or portfolio.

=Annotated Bibliography=
'''Freeman, R.E. (1984), Strategic Management: A Stakeholder Approach.'''
The Strategic Management: A Stakeholder Approach published for first time in 1984 provides significant input regarding the stakeholder definition development and history. It also analyses in depth the identification and prioritisation steps, presenting techniques and giving relevant examples.

'''Project Management Institute (2013), A Guide to the Project Management Body of Knowledge (PMBOK® Guide). '''
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is a collection of best practices and tools for project managers providing the foundation of Project, Program and Portfolio Management. It gives the stakeholder definition and substantial information regarding the stakeholder analysis process.

'''Guidance on Project Management, ISO 21500:2012. '''
The International Organisation fo Standardisation developed the Guidance on Project Management, ISO 21500:2012 that provides guidance on concepts and processes of project management that are important for the success of projects. Regarding the stakeholder analysis, it provides significant and detailed input and an useful graphical representation of the different stakeholder categories.

=References=

<references>

<ref name="Freeman">Freeman, R.E. (1984) ''Strategic Management: A Stakeholder Approach. </ref>
<ref name="PMI">Project Management Institute. (2010) ''A Guide to the Project Management Body of Knowledge (PMBOK Guide)'', Project Management Institute. ISBN: 9781930699458, 193069945X </ref>
<ref name="ISO"> Guidance on Project Management, ISO 21500:2012. </ref>
<ref name="Theory">Fontaine C, Haarman A., Schmid S. (2006), The Stakeholder Theory. </ref>
<ref name="Management">Sanguera P. (2018), Managing the Stakeholders. </ref>
<ref name="Stakeholders">Polonsky M. (1996), Stakeholder management and the stakeholder matrix: Potential strategic marketing tools. </ref>
<ref name="Communication">Hayes, J. (2018), “The Theory and Practice of Change Management </ref>
<ref name="Bourne">Bourne L. (2005), Stakeholder Relationship Management </ref>
<ref name="TSO">The Stationery Office(TSO) (2011), Managing Successful Programmes</ref>
<ref name="Engagement"> Schmeer K. (2000), Stakeholder Analysis Guidelines</ref>

Stakeholder analysis

2019-05-19T13:22:14Z

Thanosfotis:

=Abstract=
A stakeholder can be shortly described either as an individual, group or organisation who is likely to affect or to be affected by the output of a project, program or portfolio. Companies have already initiated the stakeholder identification in the early 1930's, whereas the first official definition is detected in 1963 at Stanford Research Institute (SRI). However, the original stakeholder definition and stakeholder model owe their origin to Freeman (1984). Stakeholder analysis is a critical step for the success of the project and it aims to identify all the relevant stakeholders, to categorise and prioritise them according to different criteria like their interest, influence and power with the usage of alternative mapping techniques, to profile stakeholders and plan their engagement and, in conclusion, to decide on the stakeholder management processes. A stakeholder analysis should be conducted in the initiation of the project but since it is a dynamic process should be updated regularly. Although performing a stakeholder analysis may be a painful and time consuming process, it is considered valuable and it should not be neglected.

'''Key words:''' Stakeholder, stakeholder analysis, stakeholder identification, stakeholder prioritisation, stakeholder engagement, stakeholder management, mapping stakeholders, Project Management, Portfolio Management, Program Management

=Stakeholders and stakeholder analysis=
According to the classic definition of stakeholders from Project Management Institute (PMI) that is relevant for any project case “Stakeholders of a project are individuals, groups, or organisations that are affected or recognised to be affected either in a positive or negative way by a decision, action, or output of a project” <ref name="PMI"/>.
Stakeholder analysis is referred as the systematic gathering and analysis of quantitative and qualitative data to decide whose interests should be taken into consideration throughout the project. The objective of performing a stakeholder analysis is to provide the project manager and project team an overview of the people who have interest or influence in the project. It should be one of the first steps of each project and it aims to identify everyone with a concern who needs to be involved.

=History=
The term stakeholder in reference to definition, use and purpose constitutes a quite unclear concept in the literature and it tend to vary over the years. The first time the term ‘stakeholder’ appeared in the bibliography was in 1963 at the Stanford Research Institute (SRI) and originally included owners, employees, customers, supplier, lenders and society. However, it is truth that the business world was thinking and utilising the stakeholder idea many years before 1960s. According to Dodd (1932), GEC was identifying shareholders, employees, customers, and the general public as the main groups that they had to handle. Sapieca (1990) stated that Johnson & Johnson determined in 1947 customers, employees, managers, and the general public as the most important individuals and groups to deal with. Igor Ansoff and Robert Steward developed further the term based on the SRI’s approach <ref name="Theory"/>.
Freeman (1984) presented the definition of stakeholders as “any group or individual who can affect or is affected by the achievement of the organisation objectives” in his book “Strategic Management: A Stakeholder Approach” <ref name="Freeman"/> . This is one of the most popular definitions as 20 out of 75 in total found in the literature share this approach. In the figure below, the original stakeholder model developed from Freeman is presented.

[[File:Freemanmodel.png|1300px|thumb|center|Figure 1: The original stakeholder model Freeman (1984).<ref name="Freeman"/>]]

=Stakeholder analysis process=

There are several approaches regarding the stakeholder analysis process in the bibliography, but most of them have a common philosophy and can be summarised in four principal steps: Identifying, Prioritising, Profiling and Managing Stakeholders. In the initial stage, there is a need of recognising all the people who are affected or influenced by the project and have an interest in a successful or unsuccessful result. Stakeholders can be internal such as managers and employees or external like customers or suppliers. Stakeholders can be also characterised primary with a direct interest and stake to the project (employees, customer, suppliers) or secondary who do not engage in direct exchange but they are affected by or they can affect the project (business partners, competitors, regulatory authorities). The next step is to assess and prioritise stakeholders according to their importance related to the project. Subsequently, stakeholder profiling and engagement and stakeholder management are following in order for the stakeholder analysis to be completed.

===Identify Stakeholders===

The first key step in stakeholder analysis process is to identify all the people (individuals or groups) and organisations that are impacted by the project, and report all relevant information concerning their interests, engagement, influence and effect on project success.
Possible project stakeholders may be people who are <ref name="PMI"/>:
*employed on the project
*sponsoring it or supporting it
*competitors
*contributing to the requirements or are determined to use the final product, process, service, or outcome of the project like regulatory agencies and potential customers
*involved in the marketing and advertising of the product or the service
*responsible for the financial sustainability of the project
*offering goods and services that are consumed by the project (suppliers)
*using the result of the project (customers)

[[File:ISO.png|1300px|thumb|left|Figure 2: Project Stakeholders (ISO 21500:2012).<ref name="ISO"/>]]

There might be also other stakeholders indirectly involved like those contributing in recruitment activities, suppliers who contribute by offering resources to the project, shareholders, those performing administrative and logistic tasks, the project management office that might perform various activities like governance, standardisation, project management trainings and so on. It is of crucial importance that the project team starts with identification of right (and legal) stakeholders, identifying their needs, demands, wishes, preferences dreams and priorities. It is important to take into consideration that stakeholder identification is not a stable activity that is done only in the initial days of the project, but it is a dynamic process that needs to be continuously updated as the project is in progress. Once the stakeholders are identified, they are listed in a stakeholder table or represented in a diagram.

Stakeholders can be categorised in two different main groups: internal and external <ref name="PMI"/>.

'''Internal Stakeholders''' are individuals or groups inside the organisation with a direct interest or influence to the project, for instance employees, owners, and managers. They have substantial interest in the success of the organisation and they are in most cases highly affected by the ongoing activities, decisions, and outcomes of a project.

'''External stakeholders''' are individuals, groups, and organisations that are outside the business area, and they are likely to affect or be affected in a positive or negative way by the outcome of the project. External stakeholder might, for instance, be suppliers, shareholders, regulatory authorities and competitors and undoubtedly the customers.

In order to better understand the different categories of stakeholders, a diagram from '''ISO 21500:2012, Guidance on Project Management''', an international standard developed by the International Organisation for Standardisation, is used. It includes any person inside and outside the project as is represented in the figure below. It categorises the stakeholders in three main groups:

#'''Project organisation''' that includes the project team, the project management team and the project manager.
#'''Project Governance''' that may include the project steering Committee or board and the project Sponsors.
#'''Additional stakeholders''' like employees, customers, suppliers, shareholders, business partners, finance providers, regulatory authorities, Project Management Office (PMO) and stakeholders with special interest.

===Prioritise Stakeholders===

Once the stakeholders are identified, they are listed in a stakeholder table or represented in a diagram. The next step in the stakeholder analysis process is to prioritise the stakeholders and is commonly performed with the use of mapping techniques <ref name="Stakeholders"/>.
Some of the most commonly used mapping techniques constitute the power-interest grid, the power-influence grid, the influence-impact grid, the stakeholder tube and the salience model and they are further analysed below <ref name="Management"/>:

[[File:Interest-influence-stakeholder-matrix.png|thumb|right|1300px|Figure 3: Power/Interest Grid <ref name="TSO"/>]]

'''Power/ Interest Grid''': In the power-interest grid, also known as Power/Interest matrix, the stakeholders are placed on a two-dimensional graph. The horizontal axis represents the interest level whereas the vertical axis symbolises the power and the authority related to the project. For example, on the one hand, in the case that a stakeholder has both a high influence and interest in the project, it is considered as key stakeholder with a high importance in the project. On the other hand, if a stakeholder lacks influence in the project, then he is not likely to affect the project in a high level, even in the case that he has high interest. A typical Power/ Interest grid is presented in figure 3. The Power/ Interest Grid is the one of the most commonly methods for mapping and prioritising stakeholders.

'''Power/ Influence Grid''': The Power/ Interest grid model presents similar structure with the aforementioned model and plots the stakeholders in a two-dimensional graph. The axis Y represents the authority level whereas the axis X the capability to influence the decisions and the output of the project.

'''Influence/ Impact Grid''': The Influence/ Impact Grid plots the stakeholders in a two-dimensional graph, representing their capability to affect the project compared with their ability to cause changes in the project management and execution, and cons in the final outcome.

'''Stakeholder Cube''': The Stakeholder Cube model maps out the stakeholders in a three-dimensional graphical representation and prioritises stakeholders based on their interest, power and attitude.
*Interest (active or passive)
*Power (influential or unsubstantial) and
*Attitude (backer or blocker).

A stakeholder cube is represented in the figure 4 to provide a clear overview and better understanding of the model <ref name="Bourne"/>.

[[File:Stakeholder_cube.png‎|thumb|left|1300px|Figure 4: Stakeholder Cube <ref name="Bourne"/>]]
[[File:1.png|900px|thumb|Figure 5: Salience Model <ref name="Bourne"/>]]

'''Salience Model''': The Salience Model assesses and prioritises the various stakeholders according to three different factors: power, legitimacy and urgency in the organisation.

*Power: the capability of stakeholders to force their desire
*Urgency: the necessity for immediate actions
*Legitimacy: the assessment of their involvement to the project's decisions

A graphical representation is used to depict the different stakeholder prioritisation categories that spring from the salience model utilisation.

===Profile Stakeholders===
Next step in stakeholder analysis process is to profile the stakeholders and plan the stakeholder engagement. The main object of this step is to develop approaches to include project stakeholders in regards with their needs, anticipations, interests, and potential influence on the project. The substantial advantage that stakeholder engagement provides is that constitutes an actionable plan to interact efficiently with stakeholders. This process is executed regularly throughout the project according to the project management needs and the most common method is constructing a stakeholder engagement table. <ref name="PMI"/>. There are many aspects that can be included in the stakeholder table and there are different stakeholder engagement tables in the literature. However, most characteristics are common and they usually involved in one of the following categories <ref name="Engagement"/>:
*the stakeholder role in the organisation
*the interest of the stakeholder in the success of a project
* the influence of the stakeholder to the decisions of the project
*the benefits and the disadvantages that the stakeholder has regarding to the project
*the relationship to other stakeholders
*unique facts related to the stakeholder
*expectations and
*an effective way to handle expectations.

===Stakeholder Management Processes===
Identification, prioritisation and engagement of the stakeholders are the main principles that the stakeholder management strategy is based on. According to PMI, one of the most well-known project management techniques for stakeholder management is the communication plan.

The communication plan is an initial and critical step in the stakeholder management process. The objective of this plan is to communicate the project to all the relevant stakeholders and to prioritise issues when forming the communication strategy. There are different channels and strategies for a communication plan.
'''Communicating channels''' can be in general categorised into written and oral means. Written channels can be emails, hard copies, tweets and blogs, whereas the most typical oral means are face to face communication, telephone and video conferencing. Both oral and written channels have advantages and the selection depends on the circumstances and the need for communication [O’Reilly and Pondy 1979] <ref name="Communication"/> .
For instance, oral communication seems to be more effective when there is a need for feedback, different opinions and justifications. On the other hand, oral means tend to be effective when different vocabularies are used between people as they offer the opportunity to study and better understand the message. Except for the benefits of different channels, there are also external limitations in a business unit that lead in the final selection in terms of cost and time. Face to face communication may be more effective in terms of sharing opinions and collaboration. However, it needs time, cost and energy, whereas an email is an efficient, instant and “cheap” channel, but less effective than personal contact.

[[File:Communication_strategies.png‎|thumb|1300px|Figure 6: Amount of information vs Communication Effectiveness <ref name="Communication"/>]]
Except for different channels for a communication plan, there are also various '''communication strategies''' that can be used depending on the willingness of the top management members to share information and details with the employees regarding their content and directionality. Five different communication strategies can be found in the bibliography [Clampitt et al. 2000] <ref name="Communication"/>:

*Spray and Pray
*Tell and sell
*Underscore and explore
*Identify and reply
*Withhold and uphold

The communication strategies' graph depicts the effectiveness in the communication regarding the different communication strategies. As is evident the most effective method is the underscore and explore that balances the optimum ratio of transmitted information and effectiveness.

Auditing the effectiveness of the communication strategy is vital for the success of a project and this can be achieved by using the “regular auditing of communication”, as Hargie and Tourish (2000) recommended. A clear overview of the communication objectives is required answering in questions like: “Who is communicating with whom?”, “What issues are they talking about?”, “Do people understand and use the information they receive?” etc. This discussion aims to clarify ‘what, when, who and how’ [Hayes 2018]. Moreover, it is also worth pointing out that the communication plan should not be based only in the aforementioned questions, especially if it is considered that there are not ready answers to these questions. Ergo, project managers should also focus on how they understand, interpret and finally use the information provided by other people according to the specific circumstances.

=Challenges and uncertainty=
Stakeholder identification and analysis may be an long and painful process. The number of stakeholders constitutes an uncertain factor depended on the circumstances and can vary significantly between different projects. Complex and extensive projects may include more than 50 different stakeholders. Therefore, the analysis require a substantial amount of work in terms of time and cost.

Another important uncertainty regarding this process is the fact that the power, interest, influence and other aspects that are used for the prioritisation process are not measurable parameters and a qualitative data analysis is required to obtain the data. In addition, this process requires a number of assumptions and thus, the robustness of the analysis is questionable.

=Conclusion=

Stakeholder analysis is a powerful tool in the field of project, program and portfolio management. It gives the opportunity to identify the people and groups inside and outside the organisation that can affect or be affected by the outcome of the project, program and portfolio. Understanding the key stakeholders, their interests, power and needs, prioritising them according to different criteria and prepare the stakeholder engagement and management processes creates additional value for the company and contributes significantly to the success of the project. Although it may be a time consuming process, it should never be disregarded and the extent to which should be conducted depends on the circumstances and the requirements of the project, program or portfolio.

=Annotated Bibliography=
'''Freeman, R.E. (1984), Strategic Management: A Stakeholder Approach.'''
The Strategic Management: A Stakeholder Approach published for first time in 1984 provides significant input regarding the stakeholder definition development and history. It also analyses in depth the identification and prioritisation steps, presenting techniques and giving relevant examples.

'''Project Management Institute (2013), A Guide to the Project Management Body of Knowledge (PMBOK® Guide). '''
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is a collection of best practices and tools for project managers providing the foundation of Project, Program and Portfolio Management. It gives the stakeholder definition and substantial information regarding the stakeholder analysis process.

'''Guidance on Project Management, ISO 21500:2012. '''
The International Organisation fo Standardisation developed the Guidance on Project Management, ISO 21500:2012 that provides guidance on concepts and processes of project management that are important for the success of projects. Regarding the stakeholder analysis, it provides significant and detailed input and an useful graphical representation of the different stakeholder categories.

=References=

<references>

<ref name="Freeman">Freeman, R.E. (1984) ''Strategic Management: A Stakeholder Approach. </ref>
<ref name="PMI">Project Management Institute. (2010) ''A Guide to the Project Management Body of Knowledge (PMBOK Guide)'', Project Management Institute. ISBN: 9781930699458, 193069945X </ref>
<ref name="ISO"> Guidance on Project Management, ISO 21500:2012. </ref>
<ref name="Theory">Fontaine C, Haarman A., Schmid S. (2006), The Stakeholder Theory. </ref>
<ref name="Management">Sanguera P. (2018), Managing the Stakeholders. </ref>
<ref name="Stakeholders">Polonsky M. (1996), Stakeholder management and the stakeholder matrix: Potential strategic marketing tools. </ref>
<ref name="Communication">Hayes, J. (2018), “The Theory and Practice of Change Management </ref>
<ref name="Bourne">Bourne L. (2005), Stakeholder Relationship Management </ref>
<ref name="TSO">The Stationery Office(TSO) (2011), Managing Successful Programmes</ref>
<ref name="Engagement"> Schmeer K. (2000), Stakeholder Analysis Guidelines</ref>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:20:30Z

Thanosfotis:

==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 <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.

==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 <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 the figure 1, in this view 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 the 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 the 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 that they are likely 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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==

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="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"/>:

===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.

===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.

===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.

===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.

==The 100% Rule==
[[File:WBSexample.png|1300px|thumb|right|Figure 6: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

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 undoubtedly a powerful tool at 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 it 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]]

==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.

==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 work should be executed. <ref name="limit"/>

==References==
<references>

<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>
<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="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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:20:16Z

Thanosfotis:

==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 <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.

==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 <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 the figure 1, in this view 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 the 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 the 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 that they are likely 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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==

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="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"/>:

===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.

===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.

===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.

===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.

==The 100% Rule==
[[File:WBSexample.png|1300px|thumb|right|Figure 6: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

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 undoubtedly a powerful tool at 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 it 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]]

==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.

==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 work should be executed. <ref name="limit"/>

==References==
<references>

<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>
<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="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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:19:30Z

Thanosfotis:

==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 <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.

==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 <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 the figure 1, in this view 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 the 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 the 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 that they are likely 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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==

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="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"/>:

===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.

===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.

===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.

===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.

==The 100% Rule==
[[File:WBSexample.png|1300px|thumb|right|Figure 6: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

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 undoubtedly a powerful tool at 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 it 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]]

==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.

==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 work should be executed. <ref name="limit"/>

==References==
<references>

<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>
<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="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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:16:27Z

Thanosfotis:

==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 <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.

==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 <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 the figure 2, in this view 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 the figure 3.

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 the 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 that they are likely to communicate more accurately and efficiently the WBS elements to the relevant stakeholders. Figures 4, 5 and 6 present typical examples of tabular 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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 5: Outline WBS View, <ref name="foundation"/>]]

[[File:Fotis7.png|1300px|thumb|center|Figure 6: Tabular View, <ref name="foundation"/>]]
==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 <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"/>:

===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.

===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.

===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.

===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.

==The 100% Rule==
[[File:WBSexample.png|1300px|thumb|right|Figure 1: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

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 following figure 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 undoubtedly a powerful tool at 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 it 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]]

==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.

==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 work should be executed. <ref name="limit"/>

==References==
<references>

<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>
<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="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="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>

File:WBSexample.png

2019-05-19T13:14:41Z

Thanosfotis: Thanosfotis uploaded a new version of "File:WBSexample.png"

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:13:16Z

Thanosfotis:

==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 <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.

==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 <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 the figure 2, in this view 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 the figure 3.

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 the 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 that they are likely to communicate more accurately and efficiently the WBS elements to the relevant stakeholders. Figures 4, 5 and 6 present typical examples of tabular 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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 5: Outline WBS View, <ref name="foundation"/>]]

[[File:Fotis7.png|1300px|thumb|center|Figure 6: Tabular View, <ref name="foundation"/>]]
==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 <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"/>:

===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.

===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.

===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.

===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.

==The 100% Rule==
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 following figure 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.

[[File:WBSexample.png|1300px|thumb|center|Figure 1: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

==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 undoubtedly a powerful tool at 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 it 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]]

==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.

==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 work should be executed. <ref name="limit"/>

==References==
<references>

<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>
<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="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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:12:31Z

Thanosfotis:

==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 <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.

==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 <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 2: Organization Chart Style WBS , <ref name="foundation"/>]]
[[File:WBS_horizontal.png|1300px|thumb|right|Figure 3: Horizontal WBS , <ref name="foundation"/>]]
[[File:Fotis4.png|1300px|thumb|right|Figure 4: 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 the figure 2, in this view 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 the figure 3.

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 the 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 that they are likely to communicate more accurately and efficiently the WBS elements to the relevant stakeholders. Figures 4, 5 and 6 present typical examples of tabular 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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 5: Outline WBS View, <ref name="foundation"/>]]

[[File:Fotis7.png|1300px|thumb|center|Figure 6: Tabular View, <ref name="foundation"/>]]
==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 <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"/>:

===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.

===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.

===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.

===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.

==The 100% Rule==
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 following figure 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.

[[File:WBSexample.png|1300px|thumb|center|Figure 1: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

==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 undoubtedly a powerful tool at 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 it 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]]

==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.

==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 work should be executed. <ref name="limit"/>

==References==
<references>

<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>
<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="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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:05:46Z

Thanosfotis:

==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 <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.

==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 <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 2: Organization Chart Style WBS , <ref name="foundation"/>]]
[[File:WBS_horizontal.png|1300px|thumb|right|Figure 3: Horizontal WBS , <ref name="foundation"/>]]
[[File:Fotis4.png|1300px|thumb|right|Figure 4: 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 the figure 2, in this view 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 the figure 3.

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 the 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 that they are likely to communicate more accurately and efficiently the WBS elements to the relevant stakeholders. Figures 4, 5 and 6 present typical examples of tabular 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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 5: Outline WBS View, <ref name="foundation"/>]]

[[File:Fotis7.png|1300px|thumb|center|Figure 6: Tabular View, <ref name="foundation"/>]]
==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 <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"/>:

===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.

===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.

===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.

===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.

==The 100% Rule==
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 Example==

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 everything is related in the WBS elements. The WBS consists one of the first steps of the planning process, since it allows that all outcomes are 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 with the project in order to be completed and finally achieve the desired outcome.

In the following figure is clearly illustrated how the 100% rule can be applied in the WBS of a project. 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
The 100% rule is clearly illustrated in the following figure which represents the WBS of a project according with the 100% rule’s principles. The project has a deliverable which is defined in the top level of the WBS and The main deliverable which consists the level 1 of the WBS is the construction of the house.

[[File:WBSexample.png|1300px|thumb|center|Figure 1: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

==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 undoubtedly a powerful tool at 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 it 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]]

==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.

==Limitations==

==References==
<references>

<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>
<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="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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:05:31Z

Thanosfotis:

==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 <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.

==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 <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 2: Organization Chart Style WBS , <ref name="foundation"/>]]
[[File:WBS_horizontal.png|1300px|thumb|right|Figure 3: Horizontal WBS , <ref name="foundation"/>]]
[[File:Fotis4.png|1300px|thumb|right|Figure 4: 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 the figure 2, in this view 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 the figure 3.

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 the 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 that they are likely to communicate more accurately and efficiently the WBS elements to the relevant stakeholders. Figures 4, 5 and 6 present typical examples of tabular 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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 5: Outline WBS View, <ref name="foundation"/>]]

[[File:Fotis7.png|1300px|thumb|center|Figure 6: Tabular View, <ref name="foundation"/>]]
==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 <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"/>:

===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.

===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.

===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.

===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.

==The 100% Rule==
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 Example==

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 everything is related in the WBS elements. The WBS consists one of the first steps of the planning process, since it allows that all outcomes are 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 with the project in order to be completed and finally achieve the desired outcome.

In the following figure is clearly illustrated how the 100% rule can be applied in the WBS of a project. 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
The 100% rule is clearly illustrated in the following figure which represents the WBS of a project according with the 100% rule’s principles. The project has a deliverable which is defined in the top level of the WBS and The main deliverable which consists the level 1 of the WBS is the construction of the house.

[[File:WBSexample.png|1300px|thumb|center|Figure 1: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

==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 undoubtedly a powerful tool at 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 it 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]]

==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.

==Limitations==

==References==
<references>

<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>
<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="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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T13:02:45Z

Thanosfotis:

==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 <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.

==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 <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 2: Organization Chart Style WBS , <ref name="foundation"/>]]
[[File:WBS_horizontal.png|1300px|thumb|right|Figure 3: Horizontal WBS , <ref name="foundation"/>]]
[[File:Fotis4.png|1300px|thumb|right|Figure 4: 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 the figure 2, in this view 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 the figure 3.

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 the 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 that they are likely to communicate more accurately and efficiently the WBS elements to the relevant stakeholders. Figures 4, 5 and 6 present typical examples of tabular 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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 5: Outline WBS View, <ref name="foundation"/>]]

[[File:Fotis7.png|1300px|thumb|center|Figure 6: Tabular View, <ref name="foundation"/>]]
==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 <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"/>:

===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.

===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.

===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.

===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.

==The 100% Rule==
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 Example==

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 everything is related in the WBS elements. The WBS consists one of the first steps of the planning process, since it allows that all outcomes are 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 with the project in order to be completed and finally achieve the desired outcome.

In the following figure is clearly illustrated how the 100% rule can be applied in the WBS of a project. 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
The 100% rule is clearly illustrated in the following figure which represents the WBS of a project according with the 100% rule’s principles. The project has a deliverable which is defined in the top level of the WBS and The main deliverable which consists the level 1 of the WBS is the construction of the house.

[[File:WBSexample.png|1300px|thumb|center|Figure 1: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

==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 undoubtedly a powerful tool at 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 it 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]]

==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.

==Limitations==

==References==
<references>

<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>
<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="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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T12:59:55Z

Thanosfotis:

==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 <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.

==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 <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 2: Organization Chart Style WBS , <ref name="foundation"/>]]
[[File:WBS_horizontal.png|1300px|thumb|right|Figure 3: Horizontal WBS , <ref name="foundation"/>]]
[[File:Fotis4.png|1300px|thumb|right|Figure 4: 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 the figure 2, in this view 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 the figure 3.

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 the 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 that they are likely to communicate more accurately and efficiently the WBS elements to the relevant stakeholders. Figures 4, 5 and 6 present typical examples of tabular 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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 5: Outline WBS View, <ref name="foundation"/>]]

[[File:Fotis7.png|1300px|thumb|center|Figure 6: Tabular View, <ref name="foundation"/>]]

==The 100% Rule==
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 Example==

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 everything is related in the WBS elements. The WBS consists one of the first steps of the planning process, since it allows that all outcomes are 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 with the project in order to be completed and finally achieve the desired outcome.

In the following figure is clearly illustrated how the 100% rule can be applied in the WBS of a project. 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
The 100% rule is clearly illustrated in the following figure which represents the WBS of a project according with the 100% rule’s principles. The project has a deliverable which is defined in the top level of the WBS and The main deliverable which consists the level 1 of the WBS is the construction of the house.

[[File:WBSexample.png|1300px|thumb|center|Figure 1: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

==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 <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"/>:

*'''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.

*'''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.

*'''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.

*'''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.

==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 undoubtedly a powerful tool at 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 it 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]]

==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.

==Limitations==

==References==
<references>

<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>
<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="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="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>

Stakeholder analysis

2019-05-19T01:10:18Z

Thanosfotis:

=Abstract=
A stakeholder can be shortly described either as an individual, group or organisation who is likely to affect or to be affected by the output of a project, program or portfolio. Companies have already initiated the stakeholder identification in the early 1930's, whereas the first official definition is detected in 1963 at Stanford Research Institute (SRI). However, the original stakeholder definition and stakeholder model owe their origin to Freeman (1984). Stakeholder analysis is a critical step for the success of the project and it aims to identify all the relevant stakeholders, to categorise and prioritise them according to different criteria like their interest, influence and power with the usage of alternative mapping techniques, to profile stakeholders and plan their engagement and, in conclusion, to decide on the stakeholder management processes. A stakeholder analysis should be conducted in the initiation of the project but since it is a dynamic process should be updated regularly. Although performing a stakeholder analysis may be a painful and time consuming process, it is considered valuable and it should not be neglected.

'''Key words:''' Stakeholder, stakeholder analysis, stakeholder identification, stakeholder prioritisation, stakeholder engagement, stakeholder management, mapping stakeholders, Project Management, Portfolio Management, Program Management

=Stakeholders and stakeholder analysis=
According to the classic definition of stakeholders from Project Management Institute (PMI) that is relevant for any project case “Stakeholders of a project are individuals, groups, or organisations that are affected or recognised to be affected either in a positive or negative way by a decision, action, or output of a project” <ref name="PMI"/>.
Stakeholder analysis is referred as the systematic gathering and analysis of quantitative and qualitative data to decide whose interests should be taken into consideration throughout the project. The objective of performing a stakeholder analysis is to provide the project manager and project team an overview of the people who have interest or influence in the project. It should be one of the first steps of each project and it aims to identify everyone with a concern who needs to be involved.

=History=
The term stakeholder in reference to definition, use and purpose constitutes a quite unclear concept in the literature and it tend to vary over the years. The first time the term ‘stakeholder’ appeared in the bibliography was in 1963 at the Stanford Research Institute (SRI) and originally included owners, employees, customers, supplier, lenders and society. However, it is truth that the business world was thinking and utilising the stakeholder idea many years before 1960s. According to Dodd (1932), GEC was identifying shareholders, employees, customers, and the general public as the main groups that they had to handle. Sapieca (1990) stated that Johnson & Johnson determined in 1947 customers, employees, managers, and the general public as the most important individuals and groups to deal with. Igor Ansoff and Robert Steward developed further the term based on the SRI’s approach <ref name="Theory"/>.
Freeman (1984) presented the definition of stakeholders as “any group or individual who can affect or is affected by the achievement of the organisation objectives” in his book “Strategic Management: A Stakeholder Approach” <ref name="Freeman"/> . This is one of the most popular definitions as 20 out of 75 in total found in the literature share this approach. In the figure below, the original stakeholder model developed from Freeman is presented.

[[File:Freemanmodel.png|1300px|thumb|center|Figure 1: The original stakeholder model Freeman (1984).<ref name="Freeman"/>]]

=Stakeholder analysis process=

There are several approaches regarding the stakeholder analysis process in the bibliography, but most of them have a common philosophy and can be summarised in four principal steps: Identifying, Prioritising, Profiling and Managing Stakeholders. In the initial stage, there is a need of recognising all the people who are affected or influenced by the project and have an interest in a successful or unsuccessful result. Stakeholders can be internal such as managers and employees or external like customers or suppliers. Stakeholders can be also characterised primary with a direct interest and stake to the project (employees, customer, suppliers) or secondary who do not engage in direct exchange but they are affected by or they can affect the project (business partners, competitors, regulatory authorities). The next step is to assess and prioritise stakeholders according to their importance related to the project. Subsequently, stakeholder profiling and engagement and stakeholder management are following in order for the stakeholder analysis to be completed.

===Identify Stakeholders===

The first key step in stakeholder analysis process is to identify all the people (individuals or groups) and organisations that are impacted by the project, and report all relevant information concerning their interests, engagement, influence and effect on project success.
Possible project stakeholders may be people who are <ref name="PMI"/>:
*employed on the project
*sponsoring it or supporting it
*competitors
*contributing to the requirements or are determined to use the final product, process, service, or outcome of the project like regulatory agencies and potential customers
*involved in the marketing and advertising of the product or the service
*responsible for the financial sustainability of the project
*offering goods and services that are consumed by the project (suppliers)
*using the result of the project (customers)

[[File:ISO.png|1300px|thumb|left|Figure 2: Project Stakeholders (ISO 21500:2012).<ref name="ISO"/>]]

There might be also other stakeholders indirectly involved like those contributing in recruitment activities, suppliers who contribute by offering resources to the project, shareholders, those performing administrative and logistic tasks, the project management office that might perform various activities like governance, standardisation, project management trainings and so on. It is of crucial importance that the project team starts with identification of right (and legal) stakeholders, identifying their needs, demands, wishes, preferences dreams and priorities. It is important to take into consideration that stakeholder identification is not a stable activity that is done only in the initial days of the project, but it is a dynamic process that needs to be continuously updated as the project is in progress. Once the stakeholders are identified, they are listed in a stakeholder table or represented in a diagram.

Stakeholders can be categorised in two different main groups: internal and external <ref name="PMI"/>.

'''Internal Stakeholders''' are individuals or groups inside the organisation with a direct interest or influence to the project, for instance employees, owners, and managers. They have substantial interest in the success of the organisation and they are in most cases highly affected by the ongoing activities, decisions, and outcomes of a project.

'''External stakeholders''' are individuals, groups, and organisations that are outside the business area, and they are likely to affect or be affected in a positive or negative way by the outcome of the project. External stakeholder might, for instance, be suppliers, shareholders, regulatory authorities and competitors and undoubtedly the customers.

In order to better understand the different categories of stakeholders, a diagram from '''ISO 21500:2012, Guidance on Project Management''', an international standard developed by the International Organisation for Standardisation, is used. It includes any person inside and outside the project as is represented in the figure below. It categorises the stakeholders in three main groups:

#'''Project organisation''' that includes the project team, the project management team and the project manager.
#'''Project Governance''' that may include the project steering Committee or board and the project Sponsors.
#'''Additional stakeholders''' like employees, customers, suppliers, shareholders, business partners, finance providers, regulatory authorities, Project Management Office (PMO) and stakeholders with special interest.

===Prioritise Stakeholders===

Once the stakeholders are identified, they are listed in a stakeholder table or represented in a diagram. The next step in the stakeholder analysis process is to prioritise the stakeholders and is commonly performed with the use of mapping techniques <ref name="Stakeholders"/>.
Some of the most commonly used mapping techniques constitute the power-interest grid, the power-influence grid, the influence-impact grid, the stakeholder tube and the salience model and they are further analysed below <ref name="Management"/>:

[[File:Interest-influence-stakeholder-matrix.png|thumb|right|1300px|Figure 3: Power/Interest Grid<ref name="TSO"/>]]

'''Power/ Interest Grid''': In the power-interest grid, also known as Power/Interest matrix, the stakeholders are placed on a two-dimensional graph. The horizontal axis represents the interest level whereas the vertical axis symbolises the power and the authority related to the project. For example, on the one hand, in the case that a stakeholder has both a high influence and interest in the project, it is considered as key stakeholder with a high importance in the project. On the other hand, if a stakeholder lacks influence in the project, then he is not likely to affect the project in a high level, even in the case that he has high interest. A typical Power/ Interest grid is presented in figure 3. The Power/ Interest Grid is the one of the most commonly methods for mapping and prioritising stakeholders.

'''Power/ Influence Grid''': The Power/ Interest grid model presents similar structure with the aforementioned model and plots the stakeholders in a two-dimensional graph. The axis Y represents the authority level whereas the axis X the capability to influence the decisions and the output of the project.

'''Influence/ Impact Grid''': The Influence/ Impact Grid plots the stakeholders in a two-dimensional graph, representing their capability to affect the project compared with their ability to cause changes in the project management and execution, and cons in the final outcome.

'''Stakeholder Cube''': The Stakeholder Cube model maps out the stakeholders in a three-dimensional graphical representation and prioritises stakeholders based on their interest, power and attitude.
*Interest (active or passive)
*Power (influential or unsubstantial) and
*Attitude (backer or blocker).

A stakeholder cube is represented in the figure 4 to provide a clear overview and better understanding of the model <ref name="Bourne"/>.

[[File:Stakeholder_cube.png‎|thumb|left|1300px|Figure 4: Stakeholder Cube <ref name="Bourne"/>]]
[[File:1.png|900px|thumb|Figure 5: Salience Model .<ref name="Bourne"/>]]

'''Salience Model''': The Salience Model assesses and prioritises the various stakeholders according to three different factors: power, legitimacy and urgency in the organisation.

*Power: the capability of stakeholders to force their desire
*Urgency: the necessity for immediate actions
*Legitimacy: the assessment of their involvement to the project's decisions

A graphical representation is used to depict the different stakeholder prioritisation categories that spring from the salience model utilisation.

===Profile Stakeholders===
Next step in stakeholder analysis process is to profile the stakeholders and plan the stakeholder engagement. The main object of this step is to develop approaches to include project stakeholders in regards with their needs, anticipations, interests, and potential influence on the project. The substantial advantage that stakeholder engagement provides is that constitutes an actionable plan to interact efficiently with stakeholders. This process is executed regularly throughout the project according to the project management needs and the most common method is constructing a stakeholder engagement table. <ref name="PMI"/>. There are many aspects that can be included in the stakeholder table and there are different stakeholder engagement tables in the literature. However, most characteristics are common and they usually involved in one of the following categories <ref name="Engagement"/>:
*the stakeholder role in the organisation
*the interest of the stakeholder in the success of a project
* the influence of the stakeholder to the decisions of the project
*the benefits and the disadvantages that the stakeholder has regarding to the project
*the relationship to other stakeholders
*unique facts related to the stakeholder
*expectations and
*an effective way to handle expectations.

===Stakeholder Management Processes===
Identification, prioritisation and engagement of the stakeholders are the main principles that the stakeholder management strategy is based on. According to PMI, one of the most well-known project management techniques for stakeholder management is the communication plan.

The communication plan is an initial and critical step in the stakeholder management process. The objective of this plan is to communicate the project to all the relevant stakeholders and to prioritise issues when forming the communication strategy. There are different channels and strategies for a communication plan.
'''Communicating channels''' can be in general categorised into written and oral means. Written channels can be emails, hard copies, tweets and blogs, whereas the most typical oral means are face to face communication, telephone and video conferencing. Both oral and written channels have advantages and the selection depends on the circumstances and the need for communication [O’Reilly and Pondy 1979] <ref name="Communication"/> .
For instance, oral communication seems to be more effective when there is a need for feedback, different opinions and justifications. On the other hand, oral means tend to be effective when different vocabularies are used between people as they offer the opportunity to study and better understand the message. Except for the benefits of different channels, there are also external limitations in a business unit that lead in the final selection in terms of cost and time. Face to face communication may be more effective in terms of sharing opinions and collaboration. However, it needs time, cost and energy, whereas an email is an efficient, instant and “cheap” channel, but less effective than personal contact.

[[File:Communication_strategies.png‎|thumb|1300px|Figure 6: Amount of information vs Communication Effectiveness <ref name="Communication"/>]]
Except for different channels for a communication plan, there are also various '''communication strategies''' that can be used depending on the willingness of the top management members to share information and details with the employees regarding their content and directionality. Five different communication strategies can be found in the bibliography [Clampitt et al. 2000] <ref name="Communication"/>:

*Spray and Pray
*Tell and sell
*Underscore and explore
*Identify and reply
*Withhold and uphold

The communication strategies' graph depicts the effectiveness in the communication regarding the different communication strategies. As is evident the most effective method is the underscore and explore that balances the optimum ratio of transmitted information and effectiveness.

Auditing the effectiveness of the communication strategy is vital for the success of a project and this can be achieved by using the “regular auditing of communication”, as Hargie and Tourish (2000) recommended. A clear overview of the communication objectives is required answering in questions like: “Who is communicating with whom?”, “What issues are they talking about?”, “Do people understand and use the information they receive?” etc. This discussion aims to clarify ‘what, when, who and how’ [Hayes 2018]. Moreover, it is also worth pointing out that the communication plan should not be based only in the aforementioned questions, especially if it is considered that there are not ready answers to these questions. Ergo, project managers should also focus on how they understand, interpret and finally use the information provided by other people according to the specific circumstances.

=Challenges and uncertainty=
Stakeholder identification and analysis may be an long and painful process. The number of stakeholders constitutes an uncertain factor depended on the circumstances and can vary significantly between different projects. Complex and extensive projects may include more than 50 different stakeholders. Therefore, the analysis require a substantial amount of work in terms of time and cost.

Another important uncertainty regarding this process is the fact that the power, interest, influence and other aspects that are used for the prioritisation process are not measurable parameters and a qualitative data analysis is required to obtain the data. In addition, this process requires a number of assumptions and thus, the robustness of the analysis is questionable.

=Conclusion=

Stakeholder analysis is a powerful tool in the field of project, program and portfolio management. It gives the opportunity to identify the people and groups inside and outside the organisation that can affect or be affected by the outcome of the project, program and portfolio. Understanding the key stakeholders, their interests, power and needs, prioritising them according to different criteria and prepare the stakeholder engagement and management processes creates additional value for the company and contributes significantly to the success of the project. Although it may be a time consuming process, it should never be disregarded and the extent to which should be conducted depends on the circumstances and the requirements of the project, program or portfolio.

=Annotated Bibliography=
'''Freeman, R.E. (1984), Strategic Management: A Stakeholder Approach.'''
The Strategic Management: A Stakeholder Approach published for first time in 1984 provides significant input regarding the stakeholder definition development and history. It also analyses in depth the identification and prioritisation steps, presenting techniques and giving relevant examples.

'''Project Management Institute (2013), A Guide to the Project Management Body of Knowledge (PMBOK® Guide). '''
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is a collection of best practices and tools for project managers providing the foundation of Project, Program and Portfolio Management. It gives the stakeholder definition and substantial information regarding the stakeholder analysis process.

'''Guidance on Project Management, ISO 21500:2012. '''
The International Organisation fo Standardisation developed the Guidance on Project Management, ISO 21500:2012 that provides guidance on concepts and processes of project management that are important for the success of projects. Regarding the stakeholder analysis, it provides significant and detailed input and an useful graphical representation of the different stakeholder categories.

=References=

<references>

<ref name="Freeman">Freeman, R.E. (1984) ''Strategic Management: A Stakeholder Approach. </ref>
<ref name="PMI">Project Management Institute. (2010) ''A Guide to the Project Management Body of Knowledge (PMBOK Guide)'', Project Management Institute. ISBN: 9781930699458, 193069945X </ref>
<ref name="ISO"> Guidance on Project Management, ISO 21500:2012. </ref>
<ref name="Theory">Fontaine C, Haarman A., Schmid S. (2006), The Stakeholder Theory. </ref>
<ref name="Management">Sanguera P. (2018), Managing the Stakeholders. </ref>
<ref name="Stakeholders">Polonsky M. (1996), Stakeholder management and the stakeholder matrix: Potential strategic marketing tools. </ref>
<ref name="Communication">Hayes, J. (2018), “The Theory and Practice of Change Management </ref>
<ref name="Bourne">Bourne L. (2005), Stakeholder Relationship Management </ref>
<ref name="TSO">The Stationery Office(TSO) (2011), Managing Successful Programmes</ref>
<ref name="Engagement"> Schmeer K. (2000), Stakeholder Analysis Guidelines</ref>

Stakeholder analysis

2019-05-19T01:09:57Z

Thanosfotis:

=Abstract=
A stakeholder can be shortly described either as an individual, group or organisation who is likely to affect or to be affected by the output of a project, program or portfolio. Companies have already initiated the stakeholder identification in the early 1930's, whereas the first official definition is detected in 1963 at Stanford Research Institute (SRI). However, the original stakeholder definition and stakeholder model owe their origin to Freeman (1984). Stakeholder analysis is a critical step for the success of the project and it aims to identify all the relevant stakeholders, to categorise and prioritise them according to different criteria like their interest, influence and power with the usage of alternative mapping techniques, to profile stakeholders and plan their engagement and, in conclusion, to decide on the stakeholder management processes. A stakeholder analysis should be conducted in the initiation of the project but since it is a dynamic process should be updated regularly. Although performing a stakeholder analysis may be a painful and time consuming process, it is considered valuable and it should not be neglected.

'''Key words:''' Stakeholder, stakeholder analysis, stakeholder identification, stakeholder prioritisation, stakeholder engagement, stakeholder management, mapping stakeholders, Project Management, Portfolio Management, Program Management

=Stakeholders and stakeholder analysis=
According to the classic definition of stakeholders from Project Management Institute (PMI) that is relevant for any project case “Stakeholders of a project are individuals, groups, or organisations that are affected or recognised to be affected either in a positive or negative way by a decision, action, or output of a project” <ref name="PMI"/>.
Stakeholder analysis is referred as the systematic gathering and analysis of quantitative and qualitative data to decide whose interests should be taken into consideration throughout the project. The objective of performing a stakeholder analysis is to provide the project manager and project team an overview of the people who have interest or influence in the project. It should be one of the first steps of each project and it aims to identify everyone with a concern who needs to be involved.

=History=
The term stakeholder in reference to definition, use and purpose constitutes a quite unclear concept in the literature and it tend to vary over the years. The first time the term ‘stakeholder’ appeared in the bibliography was in 1963 at the Stanford Research Institute (SRI) and originally included owners, employees, customers, supplier, lenders and society. However, it is truth that the business world was thinking and utilising the stakeholder idea many years before 1960s. According to Dodd (1932), GEC was identifying shareholders, employees, customers, and the general public as the main groups that they had to handle. Sapieca (1990) stated that Johnson & Johnson determined in 1947 customers, employees, managers, and the general public as the most important individuals and groups to deal with. Igor Ansoff and Robert Steward developed further the term based on the SRI’s approach <ref name="Theory"/>.
Freeman (1984) presented the definition of stakeholders as “any group or individual who can affect or is affected by the achievement of the organisation objectives” in his book “Strategic Management: A Stakeholder Approach” <ref name="Freeman"/> . This is one of the most popular definitions as 20 out of 75 in total found in the literature share this approach. In the figure below, the original stakeholder model developed from Freeman is presented.

[[File:Freemanmodel.png|1300px|thumb|center|Figure 1: The original stakeholder model Freeman (1984).<ref name="Freeman"/>]]

=Stakeholder analysis process=

There are several approaches regarding the stakeholder analysis process in the bibliography, but most of them have a common philosophy and can be summarised in four principal steps: Identifying, Prioritising, Profiling and Managing Stakeholders. In the initial stage, there is a need of recognising all the people who are affected or influenced by the project and have an interest in a successful or unsuccessful result. Stakeholders can be internal such as managers and employees or external like customers or suppliers. Stakeholders can be also characterised primary with a direct interest and stake to the project (employees, customer, suppliers) or secondary who do not engage in direct exchange but they are affected by or they can affect the project (business partners, competitors, regulatory authorities). The next step is to assess and prioritise stakeholders according to their importance related to the project. Subsequently, stakeholder profiling and engagement and stakeholder management are following in order for the stakeholder analysis to be completed.

===Identify Stakeholders===

The first key step in stakeholder analysis process is to identify all the people (individuals or groups) and organisations that are impacted by the project, and report all relevant information concerning their interests, engagement, influence and effect on project success.
Possible project stakeholders may be people who are <ref name="PMI"/>:
*employed on the project
*sponsoring it or supporting it
*competitors
*contributing to the requirements or are determined to use the final product, process, service, or outcome of the project like regulatory agencies and potential customers
*involved in the marketing and advertising of the product or the service
*responsible for the financial sustainability of the project
*offering goods and services that are consumed by the project (suppliers)
*using the result of the project (customers)

[[File:ISO.png|1300px|thumb|left|Figure 2: Project Stakeholders (ISO 21500:2012).<ref name="ISO"/>]]

There might be also other stakeholders indirectly involved like those contributing in recruitment activities, suppliers who contribute by offering resources to the project, shareholders, those performing administrative and logistic tasks, the project management office that might perform various activities like governance, standardisation, project management trainings and so on. It is of crucial importance that the project team starts with identification of right (and legal) stakeholders, identifying their needs, demands, wishes, preferences dreams and priorities. It is important to take into consideration that stakeholder identification is not a stable activity that is done only in the initial days of the project, but it is a dynamic process that needs to be continuously updated as the project is in progress. Once the stakeholders are identified, they are listed in a stakeholder table or represented in a diagram.

Stakeholders can be categorised in two different main groups: internal and external <ref name="PMI"/>.

'''Internal Stakeholders''' are individuals or groups inside the organisation with a direct interest or influence to the project, for instance employees, owners, and managers. They have substantial interest in the success of the organisation and they are in most cases highly affected by the ongoing activities, decisions, and outcomes of a project.

'''External stakeholders''' are individuals, groups, and organisations that are outside the business area, and they are likely to affect or be affected in a positive or negative way by the outcome of the project. External stakeholder might, for instance, be suppliers, shareholders, regulatory authorities and competitors and undoubtedly the customers.

In order to better understand the different categories of stakeholders, a diagram from '''ISO 21500:2012, Guidance on Project Management''', an international standard developed by the International Organisation for Standardisation, is used. It includes any person inside and outside the project as is represented in the figure below. It categorises the stakeholders in three main groups:

#'''Project organisation''' that includes the project team, the project management team and the project manager.
#'''Project Governance''' that may include the project steering Committee or board and the project Sponsors.
#'''Additional stakeholders''' like employees, customers, suppliers, shareholders, business partners, finance providers, regulatory authorities, Project Management Office (PMO) and stakeholders with special interest.

===Prioritise Stakeholders===

Once the stakeholders are identified, they are listed in a stakeholder table or represented in a diagram. The next step in the stakeholder analysis process is to prioritise the stakeholders and is commonly performed with the use of mapping techniques <ref name="Stakeholders"/>.
Some of the most commonly used mapping techniques constitute the power-interest grid, the power-influence grid, the influence-impact grid, the stakeholder tube and the salience model and they are further analysed below <ref name="Management"/>:

[[File:Interest-influence-stakeholder-matrix.png|thumb|right|1300px|Figure 3: Power/Interest Grid<ref name="TSO"/>]]

'''Power/ Interest Grid''': In the power-interest grid, also known as Power/Interest matrix, the stakeholders are placed on a two-dimensional graph. The horizontal axis represents the interest level whereas the vertical axis symbolises the power and the authority related to the project. For example, on the one hand, in the case that a stakeholder has both a high influence and interest in the project, it is considered as key stakeholder with a high importance in the project. On the other hand, if a stakeholder lacks influence in the project, then he is not likely to affect the project in a high level, even in the case that he has high interest. A typical Power/ Interest grid is presented in figure 3. The Power/ Interest Grid is the one of the most commonly methods for mapping and prioritising stakeholders.

'''Power/ Influence Grid''': The Power/ Interest grid model presents similar structure with the aforementioned model and plots the stakeholders in a two-dimensional graph. The axis Y represents the authority level whereas the axis X the capability to influence the decisions and the output of the project.

'''Influence/ Impact Grid''': The Influence/ Impact Grid plots the stakeholders in a two-dimensional graph, representing their capability to affect the project compared with their ability to cause changes in the project management and execution, and cons in the final outcome.

'''Stakeholder Cube''': The Stakeholder Cube model maps out the stakeholders in a three-dimensional graphical representation and prioritises stakeholders based on their interest, power and attitude.
*Interest (active or passive)
*Power (influential or unsubstantial) and
*Attitude (backer or blocker).

A stakeholder cube is represented in the figure 4 to provide a clear overview and better understanding of the model <ref name="Bourne"/>.

[[File:Stakeholder_cube.png‎|thumb|left|1300px|Figure 4: Stakeholder Cube <ref name="Bourne"/>]]
[[File:1.png|900px|thumb|Figure 5: Salience Model .<ref name="Bourne"/>]]

'''Salience Model''': The Salience Model asseses and prioritises the various stakeholders according to three different factors: power, legitimacy and urgency in the organisation.

*Power: the capability of stakeholders to force their desire
*Urgency: the necessity for immediate actions
*Legitimacy: the assessment of their involvement to the project's decisions

A graphical representation is used to depict the different stakeholder prioritisation categories that spring from the salience model utilisation.

===Profile Stakeholders===
Next step in stakeholder analysis process is to profile the stakeholders and plan the stakeholder engagement. The main object of this step is to develop approaches to include project stakeholders in regards with their needs, anticipations, interests, and potential influence on the project. The substantial advantage that stakeholder engagement provides is that constitutes an actionable plan to interact efficiently with stakeholders. This process is executed regularly throughout the project according to the project management needs and the most common method is constructing a stakeholder engagement table. <ref name="PMI"/>. There are many aspects that can be included in the stakeholder table and there are different stakeholder engagement tables in the literature. However, most characteristics are common and they usually involved in one of the following categories <ref name="Engagement"/>:
*the stakeholder role in the organisation
*the interest of the stakeholder in the success of a project
* the influence of the stakeholder to the decisions of the project
*the benefits and the disadvantages that the stakeholder has regarding to the project
*the relationship to other stakeholders
*unique facts related to the stakeholder
*expectations and
*an effective way to handle expectations.

===Stakeholder Management Processes===
Identification, prioritisation and engagement of the stakeholders are the main principles that the stakeholder management strategy is based on. According to PMI, one of the most well-known project management techniques for stakeholder management is the communication plan.

The communication plan is an initial and critical step in the stakeholder management process. The objective of this plan is to communicate the project to all the relevant stakeholders and to prioritise issues when forming the communication strategy. There are different channels and strategies for a communication plan.
'''Communicating channels''' can be in general categorised into written and oral means. Written channels can be emails, hard copies, tweets and blogs, whereas the most typical oral means are face to face communication, telephone and video conferencing. Both oral and written channels have advantages and the selection depends on the circumstances and the need for communication [O’Reilly and Pondy 1979] <ref name="Communication"/> .
For instance, oral communication seems to be more effective when there is a need for feedback, different opinions and justifications. On the other hand, oral means tend to be effective when different vocabularies are used between people as they offer the opportunity to study and better understand the message. Except for the benefits of different channels, there are also external limitations in a business unit that lead in the final selection in terms of cost and time. Face to face communication may be more effective in terms of sharing opinions and collaboration. However, it needs time, cost and energy, whereas an email is an efficient, instant and “cheap” channel, but less effective than personal contact.

[[File:Communication_strategies.png‎|thumb|1300px|Figure 6: Amount of information vs Communication Effectiveness <ref name="Communication"/>]]
Except for different channels for a communication plan, there are also various '''communication strategies''' that can be used depending on the willingness of the top management members to share information and details with the employees regarding their content and directionality. Five different communication strategies can be found in the bibliography [Clampitt et al. 2000] <ref name="Communication"/>:

*Spray and Pray
*Tell and sell
*Underscore and explore
*Identify and reply
*Withhold and uphold

The communication strategies' graph depicts the effectiveness in the communication regarding the different communication strategies. As is evident the most effective method is the underscore and explore that balances the optimum ratio of transmitted information and effectiveness.

Auditing the effectiveness of the communication strategy is vital for the success of a project and this can be achieved by using the “regular auditing of communication”, as Hargie and Tourish (2000) recommended. A clear overview of the communication objectives is required answering in questions like: “Who is communicating with whom?”, “What issues are they talking about?”, “Do people understand and use the information they receive?” etc. This discussion aims to clarify ‘what, when, who and how’ [Hayes 2018]. Moreover, it is also worth pointing out that the communication plan should not be based only in the aforementioned questions, especially if it is considered that there are not ready answers to these questions. Ergo, project managers should also focus on how they understand, interpret and finally use the information provided by other people according to the specific circumstances.

=Challenges and uncertainty=
Stakeholder identification and analysis may be an long and painful process. The number of stakeholders constitutes an uncertain factor depended on the circumstances and can vary significantly between different projects. Complex and extensive projects may include more than 50 different stakeholders. Therefore, the analysis require a substantial amount of work in terms of time and cost.

Another important uncertainty regarding this process is the fact that the power, interest, influence and other aspects that are used for the prioritisation process are not measurable parameters and a qualitative data analysis is required to obtain the data. In addition, this process requires a number of assumptions and thus, the robustness of the analysis is questionable.

=Conclusion=

Stakeholder analysis is a powerful tool in the field of project, program and portfolio management. It gives the opportunity to identify the people and groups inside and outside the organisation that can affect or be affected by the outcome of the project, program and portfolio. Understanding the key stakeholders, their interests, power and needs, prioritising them according to different criteria and prepare the stakeholder engagement and management processes creates additional value for the company and contributes significantly to the success of the project. Although it may be a time consuming process, it should never be disregarded and the extent to which should be conducted depends on the circumstances and the requirements of the project, program or portfolio.

=Annotated Bibliography=
'''Freeman, R.E. (1984), Strategic Management: A Stakeholder Approach.'''
The Strategic Management: A Stakeholder Approach published for first time in 1984 provides significant input regarding the stakeholder definition development and history. It also analyses in depth the identification and prioritisation steps, presenting techniques and giving relevant examples.

'''Project Management Institute (2013), A Guide to the Project Management Body of Knowledge (PMBOK® Guide). '''
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is a collection of best practices and tools for project managers providing the foundation of Project, Program and Portfolio Management. It gives the stakeholder definition and substantial information regarding the stakeholder analysis process.

'''Guidance on Project Management, ISO 21500:2012. '''
The International Organisation fo Standardisation developed the Guidance on Project Management, ISO 21500:2012 that provides guidance on concepts and processes of project management that are important for the success of projects. Regarding the stakeholder analysis, it provides significant and detailed input and an useful graphical representation of the different stakeholder categories.

=References=

<references>

<ref name="Freeman">Freeman, R.E. (1984) ''Strategic Management: A Stakeholder Approach. </ref>
<ref name="PMI">Project Management Institute. (2010) ''A Guide to the Project Management Body of Knowledge (PMBOK Guide)'', Project Management Institute. ISBN: 9781930699458, 193069945X </ref>
<ref name="ISO"> Guidance on Project Management, ISO 21500:2012. </ref>
<ref name="Theory">Fontaine C, Haarman A., Schmid S. (2006), The Stakeholder Theory. </ref>
<ref name="Management">Sanguera P. (2018), Managing the Stakeholders. </ref>
<ref name="Stakeholders">Polonsky M. (1996), Stakeholder management and the stakeholder matrix: Potential strategic marketing tools. </ref>
<ref name="Communication">Hayes, J. (2018), “The Theory and Practice of Change Management </ref>
<ref name="Bourne">Bourne L. (2005), Stakeholder Relationship Management </ref>
<ref name="TSO">The Stationery Office(TSO) (2011), Managing Successful Programmes</ref>
<ref name="Engagement"> Schmeer K. (2000), Stakeholder Analysis Guidelines</ref>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T01:04:38Z

Thanosfotis:

==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 <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.

==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 <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"/>.

==The 100% Rule==
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 Example==

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 everything is related in the WBS elements. The WBS consists one of the first steps of the planning process, since it allows that all outcomes are 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 with the project in order to be completed and finally achieve the desired outcome.

In the following figure is clearly illustrated how the 100% rule can be applied in the WBS of a project. 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
The 100% rule is clearly illustrated in the following figure which represents the WBS of a project according with the 100% rule’s principles. The project has a deliverable which is defined in the top level of the WBS and The main deliverable which consists the level 1 of the WBS is the construction of the house.

[[File:WBSexample.png|1300px|thumb|center|Figure 1: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

==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 <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"/>:

*'''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.

*'''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.

*'''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.

*'''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.

==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 2: Organization Chart Style WBS , <ref name="foundation"/>]]
[[File:WBS_horizontal.png|1300px|thumb|right|Figure 3: Horizontal WBS , <ref name="foundation"/>]]
[[File:Fotis4.png|1300px|thumb|right|Figure 4: 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 the figure 2, in this view 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 the figure 3.

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 the 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 that they are likely to communicate more accurately and efficiently the WBS elements to the relevant stakeholders. Figures 4, 5 and 6 present typical examples of tabular 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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 5: Outline WBS View, <ref name="foundation"/>]]

[[File:Fotis7.png|1300px|thumb|center|Figure 6: Tabular View, <ref name="foundation"/>]]

==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 undoubtedly a powerful tool at 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 it 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]]

==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>

<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>
<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="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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T01:04:15Z

Thanosfotis:

==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 <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.

==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 <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"/>.

==The 100% Rule==
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 Example==

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 everything is related in the WBS elements. The WBS consists one of the first steps of the planning process, since it allows that all outcomes are 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 with the project in order to be completed and finally achieve the desired outcome.

In the following figure is clearly illustrated how the 100% rule can be applied in the WBS of a project. 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
The 100% rule is clearly illustrated in the following figure which represents the WBS of a project according with the 100% rule’s principles. The project has a deliverable which is defined in the top level of the WBS and The main deliverable which consists the level 1 of the WBS is the construction of the house.

[[File:WBSexample.png|1300px|thumb|center|Figure 1: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

==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 <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"/>:

*'''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.

*'''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.

*'''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.

*'''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.

==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 2: Organization Chart Style WBS , <ref name="foundation"/>]]
[[File:WBS_horizontal.png|1300px|thumb|right|Figure 3: Horizontal WBS , <ref name="foundation"/>]]
[[File:Fotis4.png|1300px|thumb|right|Figure 4: 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 the figure 2, in this view 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 the figure 3.

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 the 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 that they are likely to communicate more accurately and efficiently the WBS elements to the relevant stakeholders. Figures 4, 5 and 6 present typical examples of tabular 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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 5: Outline WBS View, <ref name="foundation"/>]]

[[File:Fotis7.png|1300px|thumb|center|Figure 6: Tabular View, <ref name="foundation"/>]]

==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 undoubtedly a powerful tool at 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 it 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]]

==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>

<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>
<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="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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T01:03:53Z

Thanosfotis:

==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 <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.

==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 <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"/>.

==The 100% Rule==
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 Example==

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 everything is related in the WBS elements. The WBS consists one of the first steps of the planning process, since it allows that all outcomes are 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 with the project in order to be completed and finally achieve the desired outcome.

In the following figure is clearly illustrated how the 100% rule can be applied in the WBS of a project. 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
The 100% rule is clearly illustrated in the following figure which represents the WBS of a project according with the 100% rule’s principles. The project has a deliverable which is defined in the top level of the WBS and The main deliverable which consists the level 1 of the WBS is the construction of the house.

[[File:WBSexample.png|1300px|thumb|center|Figure 1: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

==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 <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"/>:

*'''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.

*'''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.

*'''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.

*'''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.

==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 2: Organization Chart Style WBS , <ref name="foundation"/>]]
[[File:WBS_horizontal.png|1300px|thumb|right|Figure 3: Horizontal WBS , <ref name="foundation"/>]]
[[File:Fotis4.png|1300px|thumb|right|Figure 4: 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 the figure 2, in this view 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 the figure 3.

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 the 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 that they are likely to communicate more accurately and efficiently the WBS elements to the relevant stakeholders. Figures 4, 5 and 6 present typical examples of tabular 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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 5: Outline WBS View, <ref name="foundation"/>]]

[[File:Fotis7.png|1300px|thumb|center|Figure 6: Tabular View, <ref name="foundation"/>]]

==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 undoubtedly a powerful tool at 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 it 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]]

==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>

<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>
<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="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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T01:02:59Z

Thanosfotis:

==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 <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.

==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 <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"/>.

==The 100% Rule==
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 Example==

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 everything is related in the WBS elements. The WBS consists one of the first steps of the planning process, since it allows that all outcomes are 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 with the project in order to be completed and finally achieve the desired outcome.

In the following figure is clearly illustrated how the 100% rule can be applied in the WBS of a project. 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
The 100% rule is clearly illustrated in the following figure which represents the WBS of a project according with the 100% rule’s principles. The project has a deliverable which is defined in the top level of the WBS and The main deliverable which consists the level 1 of the WBS is the construction of the house.

[[File:WBSexample.png|1300px|thumb|center|Figure 1: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

==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 <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"/>:

*'''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.

*'''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.

*'''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.

*'''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.

==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 2: Organization Chart Style WBS , <ref name="foundation"/>]]
[[File:WBS_horizontal.png|1300px|thumb|right|Figure 3: Horizontal WBS , <ref name="foundation"/>]]
[[File:Fotis4.png|1300px|thumb|right|Figure 4: 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 the figure 2, in this view 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 the figure 3.

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 the 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 that they are likely to communicate more accurately and efficiently the WBS elements to the relevant stakeholders. Figures 4, 5 and 6 present typical examples of tabular 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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 5: Outline WBS View, <ref name="foundation"/>]]

[[File:Fotis7.png|1300px|thumb|center|Figure 6: Tabular View, <ref name="foundation"/>]]

==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 undoubtedly a powerful tool at 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 it 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]]

==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>

<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>
<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="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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T01:00:20Z

Thanosfotis:

==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 <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.

==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 <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"/>.

==The 100% Rule==
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 Example==

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 everything is related in the WBS elements. The WBS consists one of the first steps of the planning process, since it allows that all outcomes are 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 with the project in order to be completed and finally achieve the desired outcome.

In the following figure is clearly illustrated how the 100% rule can be applied in the WBS of a project. 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
The 100% rule is clearly illustrated in the following figure which represents the WBS of a project according with the 100% rule’s principles. The project has a deliverable which is defined in the top level of the WBS and The main deliverable which consists the level 1 of the WBS is the construction of the house.

[[File:WBSexample.png|1300px|thumb|center|Figure 1: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

==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 <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"/>:

*'''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.

*'''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.

*'''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.

*'''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.

==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 2: Organization Chart Style WBS , <ref name="foundation"/>]]
[[File:WBS_horizontal.png|1300px|thumb|right|Figure 3: Horizontal WBS , <ref name="foundation"/>]]
[[File:Fotis4.png|1300px|thumb|right|Figure 4: 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 the figure 2, in this view 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 the figure 3.

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 the 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 that they are likely to communicate more accurately and efficiently the WBS elements to the relevant stakeholders. Figures 4, 5 and 6 present typical examples of tabular 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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 5: Outline WBS View, <ref name="foundation"/>]]

[[File:Fotis7.png|1300px|thumb|center|Figure 6: Tabular View, <ref name="foundation"/>]]

==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 undoubtedly a powerful tool at 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 it 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]]

==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>

<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>
<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="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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T00:43:05Z

Thanosfotis:

==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 <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.

==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 <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.

==The 100% Rule==
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 Example==

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 everything is related in the WBS elements. The WBS consists one of the first steps of the planning process, since it allows that all outcomes are 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 with the project in order to be completed and finally achieve the desired outcome.

In the following figure is clearly illustrated how the 100% rule can be applied in the WBS of a project. 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
The 100% rule is clearly illustrated in the following figure which represents the WBS of a project according with the 100% rule’s principles. The project has a deliverable which is defined in the top level of the WBS and The main deliverable which consists the level 1 of the WBS is the construction of the house.

[[File:WBSexample.png|1300px|thumb|center|Figure 1: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

==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 <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"/>:

*'''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.

*'''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.

*'''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.

*'''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.

==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 2: Organization Chart Style WBS , <ref name="foundation"/>]]
[[File:WBS_horizontal.png|1300px|thumb|right|Figure 3: Horizontal WBS , <ref name="foundation"/>]]
[[File:Fotis4.png|1300px|thumb|right|Figure 4: 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 the figure 2, in this view 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 the figure 3.

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 the 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 that they are likely to communicate more accurately and efficiently the WBS elements to the relevant stakeholders. Figures 4, 5 and 6 present typical examples of tabular 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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 5: Outline WBS View, <ref name="foundation"/>]]

[[File:Fotis7.png|1300px|thumb|center|Figure 6: Tabular View, <ref name="foundation"/>]]

==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 undoubtedly a powerful tool at 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 it 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]]

==References==
<references>

<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>
<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="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="ISO"> Guidance on Project Management, ISO 21500:2012. </ref>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T00:38:42Z

Thanosfotis:

==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 <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.

==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 <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.

==The 100% Rule==
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 Example==

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 everything is related in the WBS elements. The WBS consists one of the first steps of the planning process, since it allows that all outcomes are 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 with the project in order to be completed and finally achieve the desired outcome.

In the following figure is clearly illustrated how the 100% rule can be applied in the WBS of a project. 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
The 100% rule is clearly illustrated in the following figure which represents the WBS of a project according with the 100% rule’s principles. The project has a deliverable which is defined in the top level of the WBS and The main deliverable which consists the level 1 of the WBS is the construction of the house.

[[File:WBSexample.png|1300px|thumb|center|Figure 1: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

==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 <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.

*'''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.

*'''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.

*'''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.

==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 2: Organization Chart Style WBS , <ref name="foundation"/>]]
[[File:WBS_horizontal.png|1300px|thumb|right|Figure 3: Horizontal WBS , <ref name="foundation"/>]]
[[File:Fotis4.png|1300px|thumb|right|Figure 4: 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 the figure 2, in this view 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 the figure 3.

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 the 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 that they are likely to communicate more accurately and efficiently the WBS elements to the relevant stakeholders. Figures 4, 5 and 6 present typical examples of tabular 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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 5: Outline WBS View, <ref name="foundation"/>]]

[[File:Fotis7.png|1300px|thumb|center|Figure 6: Tabular View, <ref name="foundation"/>]]

==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 undoubtedly a powerful tool at 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 it 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]]

==References==
<references>

<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, p.17 </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="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>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T00:33:57Z

Thanosfotis:

==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 <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.

==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. (ISO 21500 Standard, p. 18). 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.

==The 100% Rule==
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 Example==

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 everything is related in the WBS elements. The WBS consists one of the first steps of the planning process, since it allows that all outcomes are 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 with the project in order to be completed and finally achieve the desired outcome.

In the following figure is clearly illustrated how the 100% rule can be applied in the WBS of a project. 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
The 100% rule is clearly illustrated in the following figure which represents the WBS of a project according with the 100% rule’s principles. The project has a deliverable which is defined in the top level of the WBS and The main deliverable which consists the level 1 of the WBS is the construction of the house.

[[File:WBSexample.png|1300px|thumb|center|Figure 1: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

==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 <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.

*'''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.

*'''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.

*'''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.

==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 2: Organization Chart Style WBS , <ref name="foundation"/>]]
[[File:WBS_horizontal.png|1300px|thumb|right|Figure 3: Horizontal WBS , <ref name="foundation"/>]]
[[File:Fotis4.png|1300px|thumb|right|Figure 4: 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 the figure 2, in this view 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 the figure 3.

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 the 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 that they are likely to communicate more accurately and efficiently the WBS elements to the relevant stakeholders. Figures 4, 5 and 6 present typical examples of tabular 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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 5: Outline WBS View, <ref name="foundation"/>]]

[[File:Fotis7.png|1300px|thumb|center|Figure 6: Tabular View, <ref name="foundation"/>]]

==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 undoubtedly a powerful tool at 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 it 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]]

==References==
<references>

<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, p.17 </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="foundation"> Eric S. Norman, Shelly A. Brotherton, Robert T. Fried. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008 </ref>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T00:32:49Z

Thanosfotis:

==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 <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.

==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. (ISO 21500 Standard, p. 18). 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.

==The 100% Rule==
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 Example==

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 everything is related in the WBS elements. The WBS consists one of the first steps of the planning process, since it allows that all outcomes are 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 with the project in order to be completed and finally achieve the desired outcome.

In the following figure is clearly illustrated how the 100% rule can be applied in the WBS of a project. 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
The 100% rule is clearly illustrated in the following figure which represents the WBS of a project according with the 100% rule’s principles. The project has a deliverable which is defined in the top level of the WBS and The main deliverable which consists the level 1 of the WBS is the construction of the house.

[[File:WBSexample.png|1300px|thumb|center|Figure 1: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

==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 <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.

*'''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.

*'''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.

*'''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.

==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 2: Organization Chart Style WBS , <ref name="foundation"/>]]
[[File:WBS_horizontal.png|1300px|thumb|right|Figure 3: Horizontal WBS , <ref name="foundation"/>]]
[[File:Fotis4.png|1300px|thumb|right|Figure 4: 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 the figure 2, in this view 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 the figure 3.

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 the 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 that they are likely to communicate more accurately and efficiently the WBS elements to the relevant stakeholders. Figures 4, 5 and 6 present typical examples of tabular 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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 5: Outline WBS View, <ref name="foundation"/>]]

[[File:Fotis7.png|1300px|thumb|center|Figure 6: Tabular View, <ref name="foundation"/>]]

==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 undoubtedly a powerful tool at 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 it 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==

#'''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.
#'''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]]

#'''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]]

==References==
<references>

<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, p.17 </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="foundation"> Eric S. Norman, Shelly A. Brotherton, Robert T. Fried. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008 </ref>

Work Breakdown Structure (WBS) in Project Management

2019-05-19T00:31:40Z

Thanosfotis:

==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 <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.

==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. (ISO 21500 Standard, p. 18). 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.

==The 100% Rule==
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 Example==

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 everything is related in the WBS elements. The WBS consists one of the first steps of the planning process, since it allows that all outcomes are 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 with the project in order to be completed and finally achieve the desired outcome.

In the following figure is clearly illustrated how the 100% rule can be applied in the WBS of a project. 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
The 100% rule is clearly illustrated in the following figure which represents the WBS of a project according with the 100% rule’s principles. The project has a deliverable which is defined in the top level of the WBS and The main deliverable which consists the level 1 of the WBS is the construction of the house.

[[File:WBSexample.png|1300px|thumb|center|Figure 1: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

==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 <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.

*'''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.

*'''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.

*'''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.

==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 2: Organization Chart Style WBS , <ref name="foundation"/>]]
[[File:WBS_horizontal.png|1300px|thumb|right|Figure 3: Horizontal WBS , <ref name="foundation"/>]]
[[File:Fotis4.png|1300px|thumb|right|Figure 4: 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 the figure 2, in this view 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 the figure 3.

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 the 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 that they are likely to communicate more accurately and efficiently the WBS elements to the relevant stakeholders. Figures 4, 5 and 6 present typical examples of tabular 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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 5: Outline WBS View, <ref name="foundation"/>]]

[[File:Fotis7.png|1300px|thumb|center|Figure 6: Tabular View, <ref name="foundation"/>]]

==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 undoubtedly a powerful tool at 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 it 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==

#'''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.

#'''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]]

#'''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]]

==References==
<references>

<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, p.17 </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="foundation"> Eric S. Norman, Shelly A. Brotherton, Robert T. Fried. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008 </ref>

File:Fotis8.png

2019-05-19T00:31:36Z

Thanosfotis:

Work Breakdown Structure (WBS) in Project Management

2019-05-19T00:26:09Z

Thanosfotis:

==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 <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.

==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. (ISO 21500 Standard, p. 18). 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.

==The 100% Rule==
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 Example==

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 everything is related in the WBS elements. The WBS consists one of the first steps of the planning process, since it allows that all outcomes are 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 with the project in order to be completed and finally achieve the desired outcome.

In the following figure is clearly illustrated how the 100% rule can be applied in the WBS of a project. 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
The 100% rule is clearly illustrated in the following figure which represents the WBS of a project according with the 100% rule’s principles. The project has a deliverable which is defined in the top level of the WBS and The main deliverable which consists the level 1 of the WBS is the construction of the house.

[[File:WBSexample.png|1300px|thumb|center|Figure 1: Work Breakdown Structure of a House Construction, inspired by www.workbreakdownstructures.com.]]

==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 <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.

*'''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.

*'''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.

*'''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.

==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 2: Organization Chart Style WBS , <ref name="foundation"/>]]
[[File:WBS_horizontal.png|1300px|thumb|right|Figure 3: Horizontal WBS , <ref name="foundation"/>]]
[[File:Fotis4.png|1300px|thumb|right|Figure 4: 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 the figure 2, in this view 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 the figure 3.

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 the 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 that they are likely to communicate more accurately and efficiently the WBS elements to the relevant stakeholders. Figures 4, 5 and 6 present typical examples of tabular 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 certainly on the project’s circumstances, but the most important factor is the human characteristics. Some people prefer visual representations, whereas others are supporters of 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 5: Outline WBS View, <ref name="foundation"/>]]

[[File:Fotis7.png|1300px|thumb|center|Figure 6: Tabular View, <ref name="foundation"/>]]

==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 undoubtedly a powerful tool at 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 it 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.

==References==
<references>

<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, p.17 </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="foundation"> Eric S. Norman, Shelly A. Brotherton, Robert T. Fried. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008 </ref>