Work Breakdown Structure (WBS)
(→Work Breakdown Structure main Charactheristics) |
CrewMember (Talk | contribs) (→Potential Misunderstanding, Disadventages and Advantages) |
||
| (14 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | ''Developed by Stefano Almanzi'' | ||
| + | |||
Work Breakdown Structure (WBS) is a tool used in project management context that separates in different levels of details a deliverable-oriented project in hierarchical order. The primary objective is to support the project manager by giving an overview of different steps, resources and costs involved in the project. | Work Breakdown Structure (WBS) is a tool used in project management context that separates in different levels of details a deliverable-oriented project in hierarchical order. The primary objective is to support the project manager by giving an overview of different steps, resources and costs involved in the project. | ||
| Line 28: | Line 30: | ||
This first requirement is the most important one, it state that a WBS should be deliverable-oriented, this guaranty a WBS that can be taken under control thanks to a “Milestone Structure”. Moreover, the final scope of the Project is more easily defined. To underpin the importance of this requirement, the PMI includes deliverable orientation as part of definition of a WBS. | This first requirement is the most important one, it state that a WBS should be deliverable-oriented, this guaranty a WBS that can be taken under control thanks to a “Milestone Structure”. Moreover, the final scope of the Project is more easily defined. To underpin the importance of this requirement, the PMI includes deliverable orientation as part of definition of a WBS. | ||
| − | A WBS must take into consideration the full scope of the project including all internal, external and interim deliverables. For facilitating this task a WBS has an hierarchal approach with at least two levels, to understand better the connection between the elements a coding scheme of different levels should be provided [[File:Coding_wbs.png|200px|thumb| | + | A WBS must take into consideration the full scope of the project including all internal, external and interim deliverables. For facilitating this task a WBS has an hierarchal approach with at least two levels, to understand better the connection between the elements a coding scheme of different levels should be provided [[File:Coding_wbs.png|200px|thumb|right| Figure 1: WBS with Coding scheme]] '''Figure 1''', each level must include100% of works connection belonging to the lower level 6, Nevertheless is not permitted to included element out of this project scope. |
Nouns and adjectives define each level’s component but the use of verbs is not permitted. This ensures the deliverable of the element otherwise could be understood as a task. In case arises the need of clarification a “WBS Dictionary” can be added for defining the outcomes. In addition, since this tool is used for “real-case” applications require to be updated while work are in progress. | Nouns and adjectives define each level’s component but the use of verbs is not permitted. This ensures the deliverable of the element otherwise could be understood as a task. In case arises the need of clarification a “WBS Dictionary” can be added for defining the outcomes. In addition, since this tool is used for “real-case” applications require to be updated while work are in progress. | ||
| − | + | A quality WBS is constructed by definition in a way that satisfies all of its intended needs, so why do we need to develop different types of WBS ? Of course, all Work Breakdown Structures are different from each other depending on the scope. For this reason a WBS is defined as a Use-Related Characteristics tool, where additional attributes that vary from one project to next, among industries, environments or in the way the WBS is applied within the project. Then this implies that the quality of the WBS increase with the number of the listed features that it meets: | |
| − | + | ||
| − | + | ||
| − | + | ||
* Achieves a sufficient level of decomposition to enable appropriate management and control | * Achieves a sufficient level of decomposition to enable appropriate management and control | ||
| Line 42: | Line 41: | ||
* Clearly enables the assignment of accountability at the appropriate level, regardless of whether the WBS is for a program or an | * Clearly enables the assignment of accountability at the appropriate level, regardless of whether the WBS is for a program or an | ||
individual project | individual project | ||
| + | <ref> Eric S. Norman, Shelly A. Brotherton, Robert T. Fried Work Breakdown Structures: The Foundation for Project Management Excellence, Wiley, 2010</ref> | ||
==Representation== | ==Representation== | ||
| − | As mentioned before the aim of a WBS is to show at best the | + | As mentioned before the aim of a WBS is to show at best the purpose of the project, program or portfolio taken into consideration. There is no one exact or mandatory way of representing a WBS. Nevertheless, all of them have in common a tree structure. The most use tree structure is the inverted Tree Structure [[File: Horizontal_WBS.png|200px|thumb|right| Figure 2: Inverted tree structure]] '''''Figure 2''''', in this representation the project has the aspect of an organization chart. However there are other two types of representation: the one shown In [[File: Horizontal_WBS.png|200px|thumb|left| Figure 3: Horizontal WBS]] '''''Figure 3''''', that has the root on the left side and growth from the right side and the last one called centralized tree structure .[[File:Centralized_tree_structure_WBS.png|200px|thumb|right| Figure 4: Centralized_tree_structure_WBS]] '''''Figure 4''''' This can help the project development session. |
| − | The graphical representation is not the only way of representing a WBS | + | The graphical representation is not the only way of representing a WBS: tabular views are also used. This approach has the advantage to be clearer in case the WBS has many levels. An example is shown in figure [[File: List_wbs.png|200px|thumb|right| Figure 5: Tabular WBS]] '''''Figure 5'''''. Usually at top level is shown the main deliverable that can change depending what kind of project is analyzed. Lower level provide information to the project managers like schedule development, cost estimating, resource allocation, and risk assessment. The lowest level called Work Packages, is defined by PMI as:” A deliverable or project work component at the lowest level of the Work Breakdown Structure. The work package includes the schedule activities and schedule milestones required to complete the work package deliverable or project work component’.It is a good habit as suggested by NASA of not having more than seven levels. Each element of a WBS is recognizable by a clear, descriptive title and by a numbering scheme |
Depending on the level the management might assign responsibility for technical, schedule, and cost performance. A Control Account is usually established to guaranty at best he intersection between of WBS element and organization unit. | Depending on the level the management might assign responsibility for technical, schedule, and cost performance. A Control Account is usually established to guaranty at best he intersection between of WBS element and organization unit. | ||
==Decomposition procedures== | ==Decomposition procedures== | ||
| − | Overall a WBS is the result of a decomposition process, which goes from the project and terminates to a certain level of details necessary for effective communication at the project's stakeholder. Meaning that there | + | Overall a WBS is the result of a decomposition process, which goes from the project's aim and terminates to a certain level of details necessary for effective communication at the project's stakeholder. Meaning that there no rule regarding how much in detail the WBS should go, it depends from project to project. This supports the statement that identify WBS as Use-Related Characteristics tool. Nevertheless, is important to find a good balance between communication, complexity and the need for control <ref> Stephen A. Devaux. 1 edition (September 18, 2014). Managing Projects as Investments: Earned Value to Business Value </ref>. |
The most common method for decomposing a WBS are the following methods: | The most common method for decomposing a WBS are the following methods: | ||
| Line 57: | Line 57: | ||
Project’s deliverables are collected by business function for facilitating communication to stakeholders. This WBS is focusing on operations or activities that should be performed. | Project’s deliverables are collected by business function for facilitating communication to stakeholders. This WBS is focusing on operations or activities that should be performed. | ||
*Role | *Role | ||
| − | Similar to the previous one, this | + | Similar to the previous one, this focuses more on responsibility. |
*Method | *Method | ||
The project derivable is based on methodology or delivery process, this type of WBS is easy to understand and is mainly use for showing the projects outcomes. | The project derivable is based on methodology or delivery process, this type of WBS is easy to understand and is mainly use for showing the projects outcomes. | ||
*Deliverables (components) | *Deliverables (components) | ||
| − | + | This is most common used.It can be used for every types of projects. The project’s deliverables are collected by business function | |
| − | + | ||
==100% Rule== | ==100% Rule== | ||
| − | One of the most important principles for developing a WBS is called 100% rule. This rule is | + | One of the most important principles for developing a WBS is called 100% rule. This rule is set from Project Management Institute (PMI). |
| − | This 100% rule | + | This 100% rule establish that a WBS must Include the 100% of the work defined from the project and includes all the necessary for its realization (Internal, contractor, subcontractor) included the management of the project itself. The 100% rule is one of the most important guideline for developing the decomposition and evaluation of a WBS. The rule is applied at all levels of the hierarchical structure : ‘the next level of decomposition of a WBS element (child level) must represent 100 percent of the work applicable to the next higher (parent) element’’ <ref> Haugan, Gregory T. 2002. Effective Work Breakdown Structures. Vienna, VA Management Concepts</ref> (Haugan p. 17).. |
The WBS can not include jobs out of the project’s border, meaning that should not include more of the 100%. | The WBS can not include jobs out of the project’s border, meaning that should not include more of the 100%. | ||
| − | + | The application of the 100% Rule permit the manager to know that all efforts in each area are caught where they belong and also that nothing unrelated is included in an element. Application of the 100% Rule allows all outcomes to be defined before the schedule planning begins. The WBS is the initiator in the planning process. If output are insufficiently defined, the project will not succeed. Awareness of the 100% Rule ensure and communicates the full understanding of all necessary output. Once the project is in progress the 100% Rule assists in assuring that project costs are well presented in the accounting system. This is valid for all projects, either they are performed for another division in a company or a regular paying customer. Application of the 100% Rule permits accurate costing, which is essential to budget similar efforts in the future. | |
===100% Rule Application=== | ===100% Rule Application=== | ||
| − | This example provides a practical use of the 100% rule and the "progressive elaboration" technique. | + | This example provides a practical use of the 100% rule and the "progressive elaboration" technique. [[File:Wbs_house.png|200px|thumb|right| Figure 6: Work Breakdown Structure of a House]] '''''Figure 6''''' , is shown a WBS that has the objective the Construction of an house. |
| − | At the top level (Level 1) the project manager has | + | At the top level (Level 1) the project manager has assigned 100 points to the whole project, meaning the entire building process of the house. Breaking down to level number 2 we have more than one deliverable. By summing the points of each deliverable the result will be of 100. The points allocated in each element are the result of a project manager’s consideration, meaning that these points are not an estimation of Cost/Time, etc. but represent the overall effort needed to complete the task. Some elements (the once that needs a higher detail of decomposition) have a lower level (Level 3) that represents in this case the lowest level of this WBS. However, if is needed this breaks down process can continue until the project manager is not satisfed regarding the level of details that want to achieve. The procedure just used is called “progressive elaboration”. |
As in this example, is totally fine if have different level of decomposition through different elements | As in this example, is totally fine if have different level of decomposition through different elements | ||
| − | It is suggested that the project manager | + | It is suggested that the project manager uses a software support, as a spreadsheet, to have an auto-sum operations. This could seem a silly recommendation, but the WBS of a portfolio can have hundred of branches a spreadsheet will be very useful. Another recommended procedure is to discuss together with the project team regarding the numbers of points that belong to each element, this collaborative practice helps to achieve an high resolution of the reality because different people with different skills are involved during this process. |
==Specific Type of WBS== | ==Specific Type of WBS== | ||
| − | As | + | As mentioned previously WBS is a tool introduced during the 60’.However up to present different WBS’s related tools have been developed. |
===Value breakdown structure=== | ===Value breakdown structure=== | ||
| − | This tool is mainly used for assessing a project’s expected value, as WBS has a hierarchical structure. There is one fundamental difference | + | This tool is mainly used for assessing a project’s expected value, as WBS has a hierarchical structure. There is one fundamental difference: in this tool the 100% rule is not used, this because the value is not additive as the cost. For instance, a Helicopter manufacturer wants to produce a 10-seat helicopter the budget is 1000000$, and the Expected monetary value is 1700000$. By using an hierarchical approach we should decompose the helicopter in different parts and define for each part all the necessary process until to get these components (cockpit, landing skid, passenger seats, engine, rotor, tail rotor, blade ). Let's image that we have all the components except the engine. The cost resources until this stage could be 900000$, but the actual value of this helicopter without the engine is namely 0 because no one wants a Helicopter without the engine. Meaning that the added Value of the engine is equal or close to the entire value of the projects. On one hand, we do not have any value until the motor is not mounted on the helicopter (VBS approach), on the other hand, we have costs for the resources used until now (WBS approach). |
===Goals Breakdown Structure=== | ===Goals Breakdown Structure=== | ||
| − | As a WBS, the Goals Breakdown Structure (GBS) has a hierarchical tree structure | + | As a WBS, the Goals Breakdown Structure (GBS) has a hierarchical tree structure. It can be considered like a WBS specially design for goal’s achievement. In the highest level is positioned the overall goal of the projects, at the lower level are located mid-term goals needed for achieving the top level mission. The GBS elements might include different peculiarities that characterize each goal, for instance, profit, market share, etc. At the third level the products/process needed for achieving the organizational goals are defined. |
As written in A Guide to the Project Management Body of Knowledge (PMBOK(R)[1] Guide) it follows rules similar to WBS. For the breakdown decomposition the WBS follows two general rules: | As written in A Guide to the Project Management Body of Knowledge (PMBOK(R)[1] Guide) it follows rules similar to WBS. For the breakdown decomposition the WBS follows two general rules: | ||
*'''Nothing Extra''' Is not allowed to include an element that does not contribute to the upper-level goals. No layer should contain any extraneous goals. | *'''Nothing Extra''' Is not allowed to include an element that does not contribute to the upper-level goals. No layer should contain any extraneous goals. | ||
| − | *'''Nothing Missing''' Each level must define all the goals necessary to ensure the project achieves the next higher-level goals. | + | *'''Nothing Missing''' Each level must define all the goals necessary to ensure that the project achieves the next higher-level goals. |
| − | The first rule is needed to make sure that the project is | + | The first rule is needed to make sure that the project is focused in only one objective without losing the resource that does not contribute any organization’s value. The second one ensures that everything that is needed for adding value to the project is take into consideration. |
The general scope of a GBS is to analyze all the goals and only the goals needed to achieve the project's higher-level goals. | The general scope of a GBS is to analyze all the goals and only the goals needed to achieve the project's higher-level goals. | ||
| − | ==Potential Misunderstanding, | + | ==Potential Misunderstanding, Disadvantages and Advantages== |
| − | A WBS is not an organizational hierarchy chart. A common error is to develop a WBS in accordance to the organizational hierarchy so is important to decompose the works depending the relations between processes than between | + | A WBS is not an organizational hierarchy chart. A common error is to develop a WBS in accordance to the organizational hierarchy, so is important to decompose the works depending the relations between processes than between organizational hierarchy. |
| − | A WBS is not a project’s development planning neither a list in chronological order. Is not | + | A WBS is not a project’s development planning neither a list in chronological order. Is not suggested to plan a project without having developed its WBS. In other words, is like plan the manufacturing process for building an airplane, even before the completion of its project. In this case is even difficult to apply the 100% rules, because the goals are not well defined. Moreover once that a WBS is defined, in case of error is not possible to fix it without starting from the beginning, because all the processes are connected to each other. |
| − | For this reason | + | For this reason building and maintaining a WBS is a process that require a strong effort in terms of times and HR , due to that fact that many people should be involved to increase the common sharing knowledge about the projects. Moreover, it should be periodically review to ensure the WBS’s reliability, this has influence on future decision that the PM will take. As said reviewing a WBS has a cost, due to that WBS encourages rigid structure for the project. Thus, it reduces managerial flexibility to initiate and lead changes during the project life cycle. (Salvendy, 2001) <ref> Salvendy, G. 2001, Handbook of Industrial Engineering, 3rd ed, John Wiley & Sons, Inc, Canada</ref>. |
However | However | ||
# The WBS reflects the project objectives, by listing all the activities required to accomplish these objectives, it prevents confusion and doubts as to the aim of the project. | # The WBS reflects the project objectives, by listing all the activities required to accomplish these objectives, it prevents confusion and doubts as to the aim of the project. | ||
| − | # It creates a common database and dictionary of common notation that | + | # It creates a common database and dictionary of common notation that serve as a reference point for all involved parties. |
| − | # | + | # The WBS permit smooth communications among the project team members and between them and customers, suppliers. |
| − | # It | + | # It can be used as an archive that can later facilitate knowledge transfer to other projects or learning by new members of the Human-resources. |
| − | # The WBS is | + | # The WBS is a powerful tool for resource management. |
==References== | ==References== | ||
<references/> | <references/> | ||
Latest revision as of 15:46, 10 February 2022
Developed by Stefano Almanzi
Work Breakdown Structure (WBS) is a tool used in project management context that separates in different levels of details a deliverable-oriented project in hierarchical order. The primary objective is to support the project manager by giving an overview of different steps, resources and costs involved in the project.
Moreover during the project executions it may include the percentage of steps completed. This ensures better control and guidance in case during the project development occur changes. It is graphically represented by a hierarchical tree, where the job of each components is given by the sum of elements underneath connected (sublevels). These elements may represent a product, data, service or any combination thereof.
Contents |
[edit] History
The WBS was initially developed by the U.S. defense, back to the 1950’s and 60’s in cooperation with NASA. Both agencies were adopting the Program Evaluation and Review Technique (PERT) [1] . During 1962, United State Airforce released “Study Of Methods For Evaluation Of The Pert/Cost Management System”. In this document was mentioned WBS as a useful tool for Controlling and Planning large acquisition projects [2] . As understandable, most of NASA projects involve many actors (contractors) with totally different tasks. Nevertheless, all of them are parts of the same project and work for the same final purpose. The WBS was used to ‘‘ . . . ensure that the total project is fully planned and that all derivative plans contribute directly to the desired objectives’’ (NASA, 1962)[3]. After this first approach NASA decided to keep update this document because believed valid and useful. In 1968, due to its success, the Department of Defense released "Work Breakdown Structures for Defense Materiel Items" (MIL-STD-881), a military standard procedure which is obligatory for all programs under the Department of Defense. This standard is constantly updated; the latest version refers to 2001 [4]. During 1987 Project Management Institute (PMI) started to release a number of documents for a non-military purpose. These documents have been collected in one, as result The Project Management Body of Knowledge (PMBOK) has been released. The first version is from 1987, other versions have been released during 1987, 1996, 2000, 2004, 2009, 2013 [5]. The main concept of subdividing different activities through different levels remains the same of the early years. However, the approach goes from “A task- oriented ‘family tree’ of activities 1987” PMBOKfirst Guide to “A deliverable- oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables” (PMBOK Guide — Third).
On one hand, the documents from PMI give an overview of the WBS concept, on the other hand, the document released from the Department of Defense can be considered as a Handbook.
[edit] Work Breakdown Structure main Charactheristics
WBS could be considered a general tool that can be used in most of projects and program. Due to this reason its features can vary from a WBS to another to best adapt the project manager needs. However, is important to underline which core characteristics that this tool should have to define a quality WBS.
In this case the term “quality” is properly define from Project Management Institute’s (PMI) that in 2006 released the paper “Practice Standard for Work Breakdown Structures”. In this document the definition of a quality WBS is given from two statements:
- A quality WBS is constructed in such a way that it satisfies all of the requirements for its use in a project.
- For the all level of the WBS, quality characteristics must be implemented.
In other words a quality WBS must comply with all requirements for its use, no matters is the scope project, program or portfolio.
This first requirement is the most important one, it state that a WBS should be deliverable-oriented, this guaranty a WBS that can be taken under control thanks to a “Milestone Structure”. Moreover, the final scope of the Project is more easily defined. To underpin the importance of this requirement, the PMI includes deliverable orientation as part of definition of a WBS.
A WBS must take into consideration the full scope of the project including all internal, external and interim deliverables. For facilitating this task a WBS has an hierarchal approach with at least two levels, to understand better the connection between the elements a coding scheme of different levels should be provided
Nouns and adjectives define each level’s component but the use of verbs is not permitted. This ensures the deliverable of the element otherwise could be understood as a task. In case arises the need of clarification a “WBS Dictionary” can be added for defining the outcomes. In addition, since this tool is used for “real-case” applications require to be updated while work are in progress.
A quality WBS is constructed by definition in a way that satisfies all of its intended needs, so why do we need to develop different types of WBS ? Of course, all Work Breakdown Structures are different from each other depending on the scope. For this reason a WBS is defined as a Use-Related Characteristics tool, where additional attributes that vary from one project to next, among industries, environments or in the way the WBS is applied within the project. Then this implies that the quality of the WBS increase with the number of the listed features that it meets:
- Achieves a sufficient level of decomposition to enable appropriate management and control
- Provides sufficient detail for bounding and communicating the scope of the project in its entirety
- Contains specific types of WBS elements necessary for the project
- Clearly enables the assignment of accountability at the appropriate level, regardless of whether the WBS is for a program or an
individual project [6]
[edit] Representation
As mentioned before the aim of a WBS is to show at best the purpose of the project, program or portfolio taken into consideration. There is no one exact or mandatory way of representing a WBS. Nevertheless, all of them have in common a tree structure. The most use tree structure is the inverted Tree Structure
Depending on the level the management might assign responsibility for technical, schedule, and cost performance. A Control Account is usually established to guaranty at best he intersection between of WBS element and organization unit.
[edit] Decomposition procedures
Overall a WBS is the result of a decomposition process, which goes from the project's aim and terminates to a certain level of details necessary for effective communication at the project's stakeholder. Meaning that there no rule regarding how much in detail the WBS should go, it depends from project to project. This supports the statement that identify WBS as Use-Related Characteristics tool. Nevertheless, is important to find a good balance between communication, complexity and the need for control [7].
The most common method for decomposing a WBS are the following methods:
- Function
Project’s deliverables are collected by business function for facilitating communication to stakeholders. This WBS is focusing on operations or activities that should be performed.
- Role
Similar to the previous one, this focuses more on responsibility.
- Method
The project derivable is based on methodology or delivery process, this type of WBS is easy to understand and is mainly use for showing the projects outcomes.
- Deliverables (components)
This is most common used.It can be used for every types of projects. The project’s deliverables are collected by business function
[edit] 100% Rule
One of the most important principles for developing a WBS is called 100% rule. This rule is set from Project Management Institute (PMI).
This 100% rule establish that a WBS must Include the 100% of the work defined from the project and includes all the necessary for its realization (Internal, contractor, subcontractor) included the management of the project itself. The 100% rule is one of the most important guideline for developing the decomposition and evaluation of a WBS. The rule is applied at all levels of the hierarchical structure : ‘the next level of decomposition of a WBS element (child level) must represent 100 percent of the work applicable to the next higher (parent) element’’ [8] (Haugan p. 17).. The WBS can not include jobs out of the project’s border, meaning that should not include more of the 100%.
The application of the 100% Rule permit the manager to know that all efforts in each area are caught where they belong and also that nothing unrelated is included in an element. Application of the 100% Rule allows all outcomes to be defined before the schedule planning begins. The WBS is the initiator in the planning process. If output are insufficiently defined, the project will not succeed. Awareness of the 100% Rule ensure and communicates the full understanding of all necessary output. Once the project is in progress the 100% Rule assists in assuring that project costs are well presented in the accounting system. This is valid for all projects, either they are performed for another division in a company or a regular paying customer. Application of the 100% Rule permits accurate costing, which is essential to budget similar efforts in the future.
[edit] 100% Rule Application
This example provides a practical use of the 100% rule and the "progressive elaboration" technique.
At the top level (Level 1) the project manager has assigned 100 points to the whole project, meaning the entire building process of the house. Breaking down to level number 2 we have more than one deliverable. By summing the points of each deliverable the result will be of 100. The points allocated in each element are the result of a project manager’s consideration, meaning that these points are not an estimation of Cost/Time, etc. but represent the overall effort needed to complete the task. Some elements (the once that needs a higher detail of decomposition) have a lower level (Level 3) that represents in this case the lowest level of this WBS. However, if is needed this breaks down process can continue until the project manager is not satisfed regarding the level of details that want to achieve. The procedure just used is called “progressive elaboration”.
As in this example, is totally fine if have different level of decomposition through different elements
It is suggested that the project manager uses a software support, as a spreadsheet, to have an auto-sum operations. This could seem a silly recommendation, but the WBS of a portfolio can have hundred of branches a spreadsheet will be very useful. Another recommended procedure is to discuss together with the project team regarding the numbers of points that belong to each element, this collaborative practice helps to achieve an high resolution of the reality because different people with different skills are involved during this process.
[edit] Specific Type of WBS
As mentioned previously WBS is a tool introduced during the 60’.However up to present different WBS’s related tools have been developed.
[edit] Value breakdown structure
This tool is mainly used for assessing a project’s expected value, as WBS has a hierarchical structure. There is one fundamental difference: in this tool the 100% rule is not used, this because the value is not additive as the cost. For instance, a Helicopter manufacturer wants to produce a 10-seat helicopter the budget is 1000000$, and the Expected monetary value is 1700000$. By using an hierarchical approach we should decompose the helicopter in different parts and define for each part all the necessary process until to get these components (cockpit, landing skid, passenger seats, engine, rotor, tail rotor, blade ). Let's image that we have all the components except the engine. The cost resources until this stage could be 900000$, but the actual value of this helicopter without the engine is namely 0 because no one wants a Helicopter without the engine. Meaning that the added Value of the engine is equal or close to the entire value of the projects. On one hand, we do not have any value until the motor is not mounted on the helicopter (VBS approach), on the other hand, we have costs for the resources used until now (WBS approach).
[edit] Goals Breakdown Structure
As a WBS, the Goals Breakdown Structure (GBS) has a hierarchical tree structure. It can be considered like a WBS specially design for goal’s achievement. In the highest level is positioned the overall goal of the projects, at the lower level are located mid-term goals needed for achieving the top level mission. The GBS elements might include different peculiarities that characterize each goal, for instance, profit, market share, etc. At the third level the products/process needed for achieving the organizational goals are defined.
As written in A Guide to the Project Management Body of Knowledge (PMBOK(R)[1] Guide) it follows rules similar to WBS. For the breakdown decomposition the WBS follows two general rules:
- Nothing Extra Is not allowed to include an element that does not contribute to the upper-level goals. No layer should contain any extraneous goals.
- Nothing Missing Each level must define all the goals necessary to ensure that the project achieves the next higher-level goals.
The first rule is needed to make sure that the project is focused in only one objective without losing the resource that does not contribute any organization’s value. The second one ensures that everything that is needed for adding value to the project is take into consideration. The general scope of a GBS is to analyze all the goals and only the goals needed to achieve the project's higher-level goals.
[edit] Potential Misunderstanding, Disadvantages and Advantages
A WBS is not an organizational hierarchy chart. A common error is to develop a WBS in accordance to the organizational hierarchy, so is important to decompose the works depending the relations between processes than between organizational hierarchy.
A WBS is not a project’s development planning neither a list in chronological order. Is not suggested to plan a project without having developed its WBS. In other words, is like plan the manufacturing process for building an airplane, even before the completion of its project. In this case is even difficult to apply the 100% rules, because the goals are not well defined. Moreover once that a WBS is defined, in case of error is not possible to fix it without starting from the beginning, because all the processes are connected to each other.
For this reason building and maintaining a WBS is a process that require a strong effort in terms of times and HR , due to that fact that many people should be involved to increase the common sharing knowledge about the projects. Moreover, it should be periodically review to ensure the WBS’s reliability, this has influence on future decision that the PM will take. As said reviewing a WBS has a cost, due to that WBS encourages rigid structure for the project. Thus, it reduces managerial flexibility to initiate and lead changes during the project life cycle. (Salvendy, 2001) [9].
However
- The WBS reflects the project objectives, by listing all the activities required to accomplish these objectives, it prevents confusion and doubts as to the aim of the project.
- It creates a common database and dictionary of common notation that serve as a reference point for all involved parties.
- The WBS permit smooth communications among the project team members and between them and customers, suppliers.
- It can be used as an archive that can later facilitate knowledge transfer to other projects or learning by new members of the Human-resources.
- The WBS is a powerful tool for resource management.
[edit] References
- ↑ S1 Cleland, David I. and Roland Gareis, Global Project Management Handbook, McGraw-Hill Professional, 2006
- ↑ Eric S. Norman, Shelly A. Brotherton, Robert T. Fried Work Breakdown Structures: The Foundation for Project Management Excellence, Wiley, 2010
- ↑ "Background and Key Concepts COPYRIGHTED MATERIAL." Web. 20 Sep. 2015
- ↑ Military-Standard-881C, 3 October 2011
- ↑ "Guide, A. "Project Management Body of Knowledge (PMBOK® GUIDE & STANDARD)." Project Management Institute. 2001.
- ↑ Eric S. Norman, Shelly A. Brotherton, Robert T. Fried Work Breakdown Structures: The Foundation for Project Management Excellence, Wiley, 2010
- ↑ Stephen A. Devaux. 1 edition (September 18, 2014). Managing Projects as Investments: Earned Value to Business Value
- ↑ Haugan, Gregory T. 2002. Effective Work Breakdown Structures. Vienna, VA Management Concepts
- ↑ Salvendy, G. 2001, Handbook of Industrial Engineering, 3rd ed, John Wiley & Sons, Inc, Canada
