Work Breakdown Structure (WBS)

Revision as of 20:46, 28 September 2015

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.

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 mention WBS as a useful tool for Controlling and Planning large acquisition projects ^[2] . As understandable, most of NASA projects involves many actors (contractors) with totally different tasks. Nevertheless, all of them are parts of the same project and works 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 decide 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]. Project Management Institute (PMI) during 1987 started to release a number of documents for a non-military purpose. These documents has been collected in one, as result The Project Management Body of Knowledge (PMBOK) has been release. 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 remain 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 gives an overview of the WBS concept, on the other hand, the document released from the Department of Defense can be considered as a Handbook.

Work Breakdown Structure main Charactheristics

WBS could be considered a general tool that can be use in most of projects and program, due to this reason a WBS to another may vary to best adapts the project manager needs. However, is important to underline which core characteristics this tool should have to define a quality WBS.

In this case the terms “quality” is well 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 statement:

1. A quality WBS is constructed in such a way that it satisfies all of the requirements for its use in a project.
2. At 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 matter is the scope project, program or portfolio.

This first requirement is the most important one, it is 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 include 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 differents level should be provided (Picture Under construction) , each level must includes 100% of works connection belonging to the lower level 6, Nevertheless is not permitted to included element out of this project scope. Each level's component is defined by nouns and adjectives but is not permitted the use of verbs, this ensures the deliverable of the element otherwise cold be understood as a task. In case arise the need of clarification can be added a “WBS Dictionary” for defining the outcomes. In addition, since this tool is use for “real-case” application require that can be updated while working are in progress.

If it is true that a quality WBS is constructed in such a way that it satisfies all of its intended needs, then what is it about those needs that differentiate one WBS from another? We are certain that all Work Breakdown Structures are not the same—so what then, separates and makes them unique? This is where the concept of Use-Related Characteristics comes into play. Use-Related Characteristics include those additional attributes that vary from one project to next, across industries, environments or in the way the WBS is applied within the project. With Use-Related Characteristics, the quality of the WBS depends on how well the specific content and types of WBS elements address the full set of needs of the project or program. This then implies that the more needs that the WBS meets, the higher the resulting quality of the WBS.

• 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

Representation

As mentioned before the aim of a WBS is to show at best the scope 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 one called inverted Tree Structure (Picture Under construction) , in this representation the project has the aspect of an organization chart. However there are other two types of representation the one shown In ! (Picture Under construction) , that has the root on the left side and growth from the right side, the last one is called centralized tree structure Picture this can help the development session.

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 (Picture Under construction) ,. 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 also called Work Packages. It 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 suggest 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.

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 is not a 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 find a good balance between communication and complexity the need for control ^[6].

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 is focusing 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)

Most common used, can be use for every types of projects Functional breakdown the project’s deliverables are collected by business function

100% Rule

One of the most important principles for developing a WBS is called 100% rule. This rule is define from Project Management Institute (PMI).

This 100% rule define that a WBS must Include the 100% of the work defined from the project and include 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’’ ^[7] (Haugan p. 17).. The WBS can not include jobs out of the project’s border, meaning that should not include more of the 100%.

Applying the 100% Rule allows the manager to know that all efforts in each area are captured where they belong and also that nothing unrelated is included in an element. Application of the 100% Rule enables all outcomes to be defined before schedule planning begins. The work breakdown structure is the initiator in the planning process, as planned outcomes must be defined before methods and schedules can be considered. If outcomes are insufficiently defined, the project cannot succeed. Awareness of the 100% Rule enables and communicates the full understanding of all necessary outcomes. Once the project is underway the 100% Rule assists in assuring that project costs are properly shown in the accounting system. This is true for all projects, whether they are accomplished for another division in a company or a regular paying customer. Application of the 100% Rule enables accurate costing, which is essential to budget similar efforts in the future.

100% Rule Application

This example provides a practical use of the 100% rule and the "progressive elaboration" technique. In ! (Picture Under construction) , is shown a WBS has the objective the Build of an house. At the top level (Level 1) the project manager has assign 100 point 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 point of each four elements we have the result will be 100. The point allocated in each element is the result of a project manager’s consideration, meaning that these points are not an estimation of Cost/Time, etc. but represents 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 represent in this case the lowest level of this WBS. However, if is needed this breaks down process can continues until the project manager is not satisfy 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 use a software support, as a spreadsheet, for have an auto.sum operations, this could seems a silly recommendation, but a 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 belongs to each element, this collaborative practice helps to achieve an high resolution of the reality because different people with different skills are involve during this process.

Specific Type of WBS

As mention previously WBS is a tool introduced during the 60’, up to present different WBS’s related tools have been developed.

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 is not used the 100% rule, 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 approaches we should decompose the helicopter in different parts, for each parts 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 actual 0 because no one wants a Helicopter without the engine. Meaning that the Value added 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 cost for the resources used until now (WBS approach).

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 for 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 are defined the products/process needed for achieving the organizational goals.

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 the project achieves the next higher-level goals.

The first rule is needed to make sure that the project is a focus in only one objective without losing the resource that does not contribute any organization’s value. The second one ensure that everything that is needed for adding value to the project that takes 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.

Potential Misunderstanding, Disadventage and adventage

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 “powers” organizational.

A WBS is not a project’s development planning neither a list in chronological order. Is not suggest 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 each other. For this reason build and maintain 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 review 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) ^[8]. However

1. 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.
2. It creates a common database and dictionary of common notation that serves as a reference point for all involved parties.
3. The WBS enables smooth communications among the project team members and between them and customers, suppliers, regulators and etc.
4. It serves as an archive that can later facilitate knowledge transfer to other projects or learning by new members of the work force.
5. The WBS is an effective tool for resource management.

References

1. ↑ S1 Cleland, David I. and Roland Gareis, Global Project Management Handbook, McGraw-Hill Professional, 2006
2. ↑ Eric S. Norman, Shelly A. Brotherton, Robert T. Fried Work Breakdown Structures: The Foundation for Project Management Excellence, Wiley, 2010
3. ↑ "Background and Key Concepts COPYRIGHTED MATERIAL." Web. 20 Sep. 2015
4. ↑ Military-Standard-881C, 3 October 2011
5. ↑ "Guide, A. "Project Management Body of Knowledge (PMBOK® GUIDE & STANDARD)." Project Management Institute. 2001.
6. ↑ Stephen A. Devaux. 1 edition (September 18, 2014). Managing Projects as Investments: Earned Value to Business Value
7. ↑ Haugan, Gregory T. 2002. Effective Work Breakdown Structures. Vienna, VA Management Concepts
8. ↑ Salvendy, G. 2001, Handbook of Industrial Engineering, 3rd ed, John Wiley & Sons, Inc, Canada