The Work Breakdown Structure (WBS)

From apppm
Revision as of 20:11, 28 February 2021 by S191852 (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Written by Ariadna Ramos

Contents

Abstract

Successful project management relies on thorough planning. This begins by defining the project objectives with sufficiently detailed information.[1] The Work Breakdown Structure (WBS) is an effective technique based on decomposing a project into hierarchical deliverables. Each one of the deliverables corresponds to a specific outcome that must be accomplished to complete the project. In other words, the WBS provides a clear view of the project’s scope, by schematically showing all the objectives that it englobes and the relations between them. A well-designed WBS that presents information at the appropriate level of detail and in formats and structures meaningful to those performing the work is an invaluable tool in project management.[1]

The following article has been created in order to provide all the information needed to create the WBS of a given project. The first part of the article contains a detailed description of the WBS, together with an explanation of its purpose. After this, the wide benefits the WBS provides to a project during the totality of its life cycle are presented and it is explained how doing the WBS for a project enhances the likelihood of its success. Also, it is shown how the WBS looks like and the specifications its structure must accomplish. The second part of the article presents how to create the WBS, where several methods are proposed. Also, it is indicated in what specific moment of the project’s life cycle the WBS should be created. Moreover, some of the most usual mistakes committed when designing the WBS are specified to anticipate and avoid making them. In the third part of the article the limitations of the WBS are discussed and some advice in order to counteract them is given. The fourth and last part of the article, includes an annotated bibliography where several references with additional information are proposed.

Big idea

What is the WBS

The Work Breakdown Structure (WBS) is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. The WBS organizes and defines the total scope of the project and represents the work specified in the current approved project scope statement.[2]

The WBS' purpose

The Work Breakdown Structure (WBS) is used with the purpose of defining the goals and delimiting the scope of a project. The WBS assists project leaders, participants, and stakeholders in the development of a clear vision of the end products or outcomes produced by the project.[1] Successful project plans are built on the foundation created by an effective WBS.[2] WBS are useful not only for projects, but for programs and portfolios as well.[1] The WBS for a program or a portfolio is performed in the same way as for a project. These differ only in the breadth of the content (scope).

The WBS' structure

Structure of the WBS. Own creation

The deliverables of the WBS are decomposed following a hierarchical structure. Decomposition is a technique used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts. As the work is decomposed to greater levels of detail, the ability to plan, manage, and control the work is enhanced.[2] The level of decomposition varies in between projects, but it usually depends on the degree of control needed to properly manage the work that has to be achieved.

Each one of the deliverables of the WBS corresponds to a specific outcome that must be accomplished to complete the project. Every descending level of the structure includes the deliverables that must be carried out in order to fulfil the outcome located in the level right above. It is important to note that the deliverables must be outcomes, not actions. That is because outcomes are final products or results that can be precisely predicted, whereas the actions and procedures followed to obtain them cannot always be anticipated. Project activities are not listed, as these are components of the project schedule, not the WBS.[1]

The WBS is a process required to ensure the project includes all the work required, and only the work required, to complete the project successfully.[2] This is achieved thanks to the application of the 100% Rule. The 100% Rule is a principle which states that the WBS includes 100% of the project’s scope and 100% of the deliverables that form it. The rule also applies to each one of the levels within the hierarchy. All the deliverables that form a descending level must equal to 100% of the work needed to complete the outcome stated in the previous level. The lowest levels should roll up to the higher levels so that nothing is left out and no extra work is performed.[2]

The deliverables that belong to the lowest level of the WBS are named work packages. For the work packages it is possible to do an estimation of the cost and duration of the activity that must be conducted in order to achieve them. The level of detail for work packages will vary with the size and complexity of the project.[2] Nevertheless, the work packages must always follow the 8 to 80 Rule, which states that the amount of hours dedicated to achieve that outcome should be bigger than 8 hours and smaller than 80. There is no need to have all work packages at the same level. Additionally, not all legs of the WBS must be symmetrical in terms of the number of levels developed.[1]


Example of the WBS. Own creation inspired from[3]

Why the WBS

The WBS enhances the chances of success of a project thanks to the several benefits it provides throughout its life cycle. Some of the main benefits are the following:

  • Provides clear scope and objectives.
The key benefit of this process is that it provides a framework of what has to be delivered.[2] The WBS assists project leaders, participants, and stakeholders in the development of a clear vision of the end products or outcomes produced by the project.[1]
  • Makes work more approachable.
The project is organized in deliverables which are subdivided following a hierarchical structure with the intention of simplifying the work and making it more manageable.
  • Eases the next steps.
It facilitates other project management processes such as estimating, scheduling, resource allocation, risk analysis, and measurement and control of the project.[1]
  • Aligns team expectations.
Since it gives a clear vision of the scope of the project and the goals are defined, the whole team is aware of the reach of the project and the expectations of all the members are aligned.
  • Relieves the project manager.
It also has the added bonus of shortening the process and engaging the team in the work, which will lighten the load on the project manager.[4]
  • Improves the communication with stakeholders.
The WBS facilitates the communication between the project manager and the stakeholders. The WBS establishes the foundation that the project stakeholders use as the basis to creating their project schedule with project activities; network diagrams to sequence work; budgets for estimating and managing costs; and for making all decisions to objectively manage scope creep.[5] Whenever work is logically structured, easily identifiable, and clearly within the capabilities of individuals, project stakeholders can confidently expect that objectives associated with the work can and will be achieved.[1]

Application

How to create the WBS

Some of the more popular methods employed to create a WBS include a top-down approach, a bottom-up approach, the use of organization-specific WBS guidelines or standards, and the use of WBS templates.[1] A summary of each one of the four methods is presented below.

Difference between top-down and bottom-up. Modified from[6]
1. Top-down
This method is based on, as its name indicates, creating the structure of the WBS from the top to the bottom. The following steps must be performed to apply the method:
1. Define the deliverables that belong to level 2.
2. Decompose the deliverables from level 2 to a degree of detail appropriate for management and integrated control. In other words, define the deliverables of the following levels. Keep in mind that the sum of elements of each level should represent 100% of the work below it, as stated in the 100% Rule.
3. Make sure that the structure englobes the whole project scope.
4. Review and refine the WBS until project stakeholders agree that project planning can be successfully completed, and that execution and control will successfully produce the desired deliverables and results.[1]
2. Bottom-Up
This method is based on, as its name indicates, creating the structure of the WBS from the bottom to the top. The following steps must be performed to apply the method:
1. Identify the work packages of the project.
2. Add deliverables to the previous levels.
3. Once a given group of related deliverables have been aggregated to a deliverable of the previous level, make sure that the 100% Rule is verified.
4. Make sure that the structure englobes the whole project scope.
5. Review and refine the WBS until project stakeholders agree that project planning can be successfully completed, and that execution and control will successfully produce the desired deliverables and results.[1]
3. WBS standards
An organizational WBS standard is a set of principles for constructing a WBS and might include a format, numbering scheme, naming convention, or required elements. WBS standards are common in many organizations with a high level of project management maturity. These standards help ensure consistency and completeness in WBSs throughout the organization.[1]
4. WBS templates
A WBS template is a sample of WBS. An organization can have templates for different types of projects and different life cycles. When reusing existing components, it is important to customize the WBS to the specific needs and requirements of the project.[1]


The difference between the top-down and bottom-up methodologies and the standards and templates, is that the first ones are methods to create new WBS from scratch whereas the second ones reuse already existing structures. The top-down and bottom-up methods help assure if the WBS is done at the proper level of detail. The choice between a top-down or a bottom-up approach is somewhat personal, and can depend on the habits and thinking styles of the project team, as well as on organizational practices. The use of standards and templates in the creation of WBSs helps promote quality assurance through the application of successfully applied WBS good practices.[1]

Nevertheless, no matter what method is implemented, the structure must verify the 100% Rule, which assures that the WBS englobes the whole scope of the project and no unnecessary information is included. Moreover, it must be taken into account that the deliverables have to be objectives, not actions, and that the ones situated in the lowest level must follow the 8 to 80 Rule. It is important to take into account that the WBS is an iterative process, it requires several reviews which will lead to several modifications. Therefore, more than one method can be used to obtain the final WBS. For example, a WBS template and the top-down approach may be used initially to determine the overall structure of the WBS, while it might be more appropriate to use the bottom-up method to verify that all the elements are present to achieve a particular deliverable.[1]

When to create the WBS

Developing a WBS is an essential step during the initial project phases.[1] That is because, as mentioned previously, the purpose of the WBS is to define the scope of a project by decomposing it into hierarchical deliverables. Therefore, by defining it at the beginning of the process, and assuring that all key members of the team are involved in its creation provides remarkable benefits. First of all, it provides global awareness of the reach of the project and aligns team expectations. Also, after establishing the WBS, an accurate estimation of the duration and cost of the project can be done. Moreover, the risk level decreases and the changes of success increase. Whereas, when the project team create their project schedule and/or budget without first creating a WBS, they increase the risk of producing unsubstantiated and inaccurate schedules and budgets because they lack information about the product solution deliverables that will meet the objectives of the project.[5] Nevertheless, it must be taken into account that the WBS has to be modified accordingly with the changes applied to the project during its life cycle. This updating process is known as ‘‘progressive elaboration.’’[1]

Usual mistakes when creating the WBS

  • Deliverables as verbs.
A common issue when designing a WBS is stating some deliverables as activities using verb phrases. Ideally, all WBS elements should be stated as nouns that describe decomposed elements of the work. That is because outcomes can be precisely predicted since they are final products or results, whereas the actions and procedures followed to obtain them cannot always be anticipated.[1]
  • Excessive decomposition.
Since the WBS is based on splitting the project into manageable deliverables, sometimes this leads to excessive decomposition. However, excessive decomposition can lead to non-productive management effort, inefficient use of resources, decreased efficiency in performing the work, and difficulty aggregating data over different levels of the WBS.[2]
  • Late setting up.
The scope of a project and the totality of the work are defined in the WBS, and failing to do so early can result in rework, schedule impacts, resource misallocations, and budget increases.[4]
  • Symmetrical WBS.
The level of decomposition in each of the arms of the WBS doesn’t have to be the same. Therefore, not all the work packages have to be in the same level.

Limitations

Traditionally, the project management metrics of time, cost, scope, and quality have been the most important factors in defining the success of a project. More recently, practitioners and scholars have determined that project success should also be measured with consideration toward achievement of the project objectives.[2] The WBS provides information exclusively about the scope and the objectives of the project. It is a very effective tool for this purpose; however, this limits its utilities in the estimation of other factors such as cost and time. The WBS is not a scheduling or a budgeting deliverable; it does not contain project activities, cost estimates, resource assignments or activity dependency information.[5] Nevertheless, it must be taken into account that the work packages, can contribute to do some estimations. The lower WBS elements provide appropriate focus for project management processes such as scope and schedule development, cost estimating and resource allocation, and risk assessment.[1] It is important to note that in order to estimate all the factors of the project, the WBS can be complemented by other project management techniques. In combination with additional data, the WBS is the framework for communicating information that includes, but is not limited to, schedule, risk, performance, dependencies, and budget.[1]

Annotated bibliography

  • Project Management Institute, Inc.. (2006). Practice Standard for Work Breakdown Structures. 2nd Edition.
This standard has been the main source of information for this article. This is because it provides understanding on how to apply the WBS as a project management tool. The standard englobes the WBS' principles and gives detailed information on how to create a high-quality WBS for managing a project, program or portfolio. Moreover, it states the benefits the WBS implementation can offer. It also provides some different examples of the tool. In this reference, additional information on the subject can be found.
The YouTube video provides 10 rules to keep in mind when designing the WBS. The 10 rules englobe all the principles the WBS must fulfil and the guidelines that have to be followed when creating it. In other words, it sums up the concepts stated during this article, therefore it can contribute to a better understanding of the WBS. Moreover, it can also be used as a check list once the WBS is completed to make sure the design accomplishes all the requirements.
  • Project Management Institute, Inc.. (2017). Guide to the Project Management Body of Knowledge (PMBOK® Guide). 6th Edition.
This guide has been used in order to provide the definitions of the key concepts included throughout the article. Therefore, this reference must be used in case of wanting to get deeper detail on the principles stated. It must also be used in the unlucky case that some concepts are unclear. Moreover, it provides some examples of different WBS that could be useful for the better understanding of the tool.

Bibliography

  1. 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 1.13 1.14 1.15 1.16 1.17 1.18 1.19 1.20 Project Management Institute, Inc.. (2006). Practice Standard for Work Breakdown Structures. 2nd Edition.
  2. 2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 Project Management Institute, Inc.. (2017). Guide to the Project Management Body of Knowledge (PMBOK® Guide). 6th Edition.
  3. Project Insight (2021). Project Scheduling: Work Breakdown Structure (WBS). https://projectinsight.com/project-management-basics/project-management-schedule
  4. 4.0 4.1 Jones, C. (2007). Creating an effective WBS with facilitated team involvement. Paper presented at PMI® Global Congress 2007—North America, Atlanta, GA. Newtown Square, PA: Project Management Institute.
  5. 5.0 5.1 5.2 Burek, P. (2013). The ABC basics of the WBS Paul Burek. Paper presented at PMI® Global Congress 2013—North America, New Orleans, LA. Newtown Square, PA: Project Management Institute.
  6. Rabhi, G. (2019). Les richesses cachées des notions Top-Down et Bottom-Up. https://gabriel-rabhi-dev.com/2019/02/14/les-richesses-cachees-des-notions-top-down-et-bottom-up-partie-1-fr/
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox