Work Breakdown Structure in project management

Latest revision as of 00:38, 1 March 2021

[edit] Abstract

This article will examine the Work Breakdown Structure, which is commonly abbreviated as WBS. It is a method of dividing a project into smaller tasks and putting them into a hierarchy. The idea is to clarify the functions in a project, by breaking the charges down to a manageable size. By breaking down the tasks, and putting into a hierarchy, one will notice the prioritization and place affiliation to the various functions. When placing the target itself in a box at the top, one will make subcategories such as analysis, requirements specification, and development. These subcategories will furthermore be broken down to even smaller tasks, and once finalized one will reach the specific tasks. With these methods, one will achieve a more manageable planning and an excellent way to graphically present the charges to the rest of the project group. It will be easier to estimate the entire project process, as one has clarified the project's scope and what it contains.^[1]

[edit] Big Idea

History

The United States Department of Defense (DoD) developed the Work Breakdown Structure in collaboration with NASA by developing the Program Evaluation and Review Technique (PERT). The PERT was a method to analyze and describe the project's process and how they relate together. The PERT's purpose was to assist the development of the Polaris missile program and the military in general. At the begging of the product, the term Work Breakdown Structure was not used. The document about PERT/COST got distributed by DoD and NASA in 1962. This document was the first edition of the WBS. Further, throughout the years, the WBS got more developed and spread to the labor market. Project Management Institute (PMI) was established in the United States in 1969 as a stakeholder organization. The PMI created a guidebook about different project management tools called Project Management Book Of Knowledge (PMBOK).^[2] This book explains the various terms and methods in project management and how to implement them in projects.^[3]

Importance of WBS and why to use it

WBS is an efficient tool for planning a project. Implementing the WBS in the planning process makes the task more efficient and increases the opportunities to finish the project. There are some benefits and advantages of designing a WBS. The benefits of a WBS help develop the organization's culture and process and not the project only. The services will be to calculate the organization's budget quickly, determine the cost, schedule projects and by having a WBS, the organization will see where the problem areas and flag the organization's issues. Therefore, the WBS is useful for projects and the whole organization as well. Some benefits are that it can help the project manager predict results based on various scenarios and organize the project details. Besides, it also increases the organization's communication and gives the team precise tasks to correct risks, costs, and time. It also provides a better overview of the project so the team will focus on end goals, prevent problems, and address schedule issues. A WBS's advantages are that it offers a visual representation of all parts of a project and repeatable ways to make useful knowledge. It also makes people on the projects responsible for different parts so that everyone knows what to do, and this will ensure no gaps and overlap in resources or responsibility.^[4]

A project manager knows that many things can go wrong in projects despite the planning and implementation of the work. When component and full-project failures occur, they can frequently be traced to a nonexistent or poorly developed WBS. A badly created WBS can cause opposite project results and ongoing budget overrun, scope creep or unmanageable, repeated project re-plans and extensions, delivered features, unclear work assignments, missed deadlines and unusable new products, or frequently changing content.^[4]

The concepts of WBS

A WBS is defined as in the PMBOK "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. It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project work. The WBS is decomposed into work packages. The deliverable orientation of the hierarchy includes both internal and external deliverables." This definition shows that the WBS gives a clear statement of the work's deliverables and objectives to be completed. It is a description of the project's deliverables, scope, and outcomes. The WBS is limited explicitly to describing and dealing with the project's scope or results, not a description of the process followed to complete the project, nor is it addressing the schedule that defines when or how the deliverables will be made. The WBS is a primary component of project management. It is a critical input to other project management deliverables and processes such as project and program schedules, activity definitions, control tools, project organization, risk analysis and response, project schedule network diagrams, or performance reports. ^[4]

Defining the WBS

The WBS is known for having at least three levels. The first level, also known as the upper level, reflects the major deliverable work areas and is broken down into logical work groupings. The first level's content can depend on the type of industry and project involved. The second level provides proper focus and detail for project management processes equally to risk assessment, schedule development, resource allocation, and cost estimating. Work Packages is the third and lowest level and contains the work definitions that must be tracked and performed. The WBS gives the project manager an insight into managing and allocate the budget for the project. When there is a certain amount of money that can be spent on the project, the project manager can look at the structure and determine it. By adding up the budgets for each item of the design, the project manager can get the project's total budget and then execute the project. In case that it is over-spending in some areas that force the project manager to look at other sites that are either in progress or have not been started yet and start to remove money from those budgets to compensate for the overrun, or the other alternative is to go out and raise more money. The other thing that can be done with the WBS is looking at the skills we need. ^[4]

Figure 1: Example of WBS levels. Own creation. Made with inspiration from ^[5]

[edit] Application

Design Work Breakdown Structure

The first thing the project manager must do when creating a WBS is to bring the team. The team members will be able to develop the WBS by knowing something about the different deliverables that have to be handed in. By collaborating with the whole team, it will be possible to list all the tasks that need to be made and avoid gaps or overlap. When start making the WBS, some documents are required to create the WBS. These documents can be the project definition, project charter, contracts, and agreements. To make an effective WBS, it should contain a statement of the project and a list of tasks that must be delivered. Also, the project should be defining the phases. As a start, it is best to make a brainstorm to catch all the information that is needed before jumping into creating the WBS. There are three primary levels in the WBS. Start by defining the first level, the main deliverable, and add many details to it before moving over to the next level. This will make the task easier. The Work Breakdown Structure is a hierarchical decomposition of the work of the total scope that has to be done by the project team to complete the project purposes and make the deliverables. It defines and organizes the project's entire range and signifies the work in the project scope statement. Work packages are the planned work that is at the lowest level of the WBS. The work packages can define the activities where the work is monitored, estimated, controlled, and scheduled. The WBS context is the work products or deliverables of the action and not the activity itself.^[4]

The process of designing a WBS is to divide the deliverables and project work into smaller tasks. The gain of this method is it gives an illustration of what must be delivered. You must go through three stages when creating WBS and are inputs, tools & techniques, and outputs.

Figure 2: Create WBS - Inputs, tools & techniques and outputs - Own creating. made with information from ^[1]

Inputs

Inputs are the first step you make when creating the WBS. The figure shows that there are some documents you have to make at this stage. You have to define the project scope statement as the first thing and make project documents that describe the work that will be performed and describe the detailed requirements for the project. ^[6][1]

Tools and Techniques

Expert judgment

Expert judgment is essential while creating a WBS because the experts have the expertise to analyze the information needed to decompose the deliverables of a project into smaller tasks. This method is used to reconcile differences in opinions on how to break down the scope in the best way.^[6][1]

Decomposition

Decomposition is a method used to divide and subdivide the scope and deliverables of a project into smaller and more manageable parts. The decomposition level is guided by the degree of control needed to manage the project effectively. Work packages are at the lowest level of the WBS, which defines the work for cost and the duration collected and estimated. Work packages detail will vary with the complexity and size of the project. The process of decomposition the project into work packages includes the activities below.

• Classify and analyze the deliverables and work related to the project.
• Organize and structure the WBS
• Decompose the upper levels of WBS into complex components in the lower level.
• Assign and develop the identification codes to the components of the WBS
• Verify the degree of the deliverables of decomposing is appropriate^[6][1]

Top-Down Method

The top-down method is a decomposition based on the project's general characteristics and not on detailed design components. This method continues the decay until the work or tasks reach a level where they can be estimated and defined. The top-down process is more logical because it starts by defining a solution to the problem and then analyzing the solution with the steps required to implement them. It is also more natural to first begin by defining the problem and then narrow it more down. Below is listed some steps that describe the top-down method to develop the WBS:

• Determine the final components of the project. The products that make the project effective and successful are defined at this stage. A simple requirement to accomplish alignment between project requirements and WBS is a detailed overview of high-level project scope documents.
• Determine the project's deliverables, which is the primary importance of the project development but does not satisfy the organizational needs.
• Decomposition of the deliverables to a point makes it easier to manage and control. These WBS elements at each level should present 100% of the work in the upper segment. Each work package should only include in the deliverable.
• Improve and implement the WBS during the project to get a successful project. ^[5]

Bottom-up Method

The Bottom-up method is a brainstorming exercise, where the team makes a list of low-level tasks needed to finish the project. This method can sometimes turn out to be chaotic because the team's functions are not at the same level. The problem can also be time-consuming to ensure that the tasks at the same level have been identified. This method requires that all team members have sufficient knowledge and understanding of the project to integrate and identify the functions at different levels. Below is listed the steps of the bottom-up method

• Identify the deliverables that are related to the project. Do not include activity. Include their deliverables instead. The whole effort will be presented in this way.
• Group the associate work packages.
• Take the deliverables to the next level, so the sum of each level's elements presents 100% of the work. (e.g., the parent level)
• When a group of related tasks is assigned to a parent, perform a subgroup analysis to ensure that no work has been ignored.
• Continue until all the individual elements join a particular "parent" related to the project. Also, check the complete response to the overall project scope.
• Keep improve and make a new revision of the WBS until the project's stakeholders recognize the project's feasibility and the implementation will lead to the expected results.^[5]

The 100% Rule

The 100% rule is a primary essence of the WBS. This rule means that the project scope defines the whole project, and all the deliverables, including the project management, have to be within the 100%. It is one of the most critical principles guiding the decomposition, development, and evaluation of the WBS. The 100% rule is applied to all levels in the hierarchy. The effort at the "child" level should equal 100% of the effort represented at the "parent" level. The WBS work should not fall outside the project scope because it cannot include more than 100% of the work. The 100% rule also applies to the activity level. To complete the work package, the work that is represented by the work packages' activities must be added up to 100% of the work. There is a need for precise identification of the work packages and the project activities, which is the core reason for the WBS's existence. The 100% rule is an essential tool to get a successful outcome project. Implementing this rule gives the project manager the ability to understand the project work and check the required tasks to the project is planned correctly. The team members of the project are needed to often test and review the WBS. This critical rule determines the use of the bottom-up cost estimator, which gives a prominent view of the work packages and the individual activities to calculate the total cost. The decomposition of the works has to follow the 100% rule, then the activities related to the project will be determined before the project's schedule is decided. The cost and resource estimation will take place in the project planning. ^[7]

Example of the 100% Rule

In figure 3, the 100% rule is clearly illustrated. It represents the Work Breakdown Structure of a house project according to the 100% rule. In the top level, the deliverable is shown, construction of a house. In the middle level, three deliverables are illustrated. The activities are decomposed into greater degree to complete the project as it is required in the lower level. When the necessary information is developed to accomplish the outcome, the process of decomposition ends. ^[7]

Figure 3: Example of 100% rule. Own creating. made with information from ^[7]

Outputs

The outputs of the WBS contain scope baseline and project document updates. The scope baseline is an approved version of the project scope statement, the WBS and WBS dictionary. The project scope baseline describes the major deliverables, assumptions, project scope, and limitations in a document. The WBS dictionary is a document that provides and supports activity, scheduling, and detailed deliverable information about the components in the work breakdown structure. The WBS dictionary includes the following aspects:^[6]

• Cost estimation
• Schedule milestones and activity
• Work description
• Limitations and assumptions
• Requirements of quality and resources
• Account identifier code
• The responsible organization
• Acceptance criteria
• Technical references
• Agreement information

The project document updates contain the assumption log and requirements documentation. These documents are documents that contain the updates that may occur when there are changes. ^[6]

Tips for creating WBS

Below are defined some prerequisites for creating a Work Breakdown Structure.

• To achieve a great WBS, you must create it with the whole team and not yourself. By involving the team in the planning stage, you understand what and who needs to be done/do the tasks. When creating the WBS, build it by defining what deliverables needs to be made.^[8]

• There should at least be three levels in the hierarchy. The project is the first level. Projects that are medium to large might have more levels, but it depends on the project's size and complexity. ^[8]

• WBS is not a task but a work component that will be broken down into tasks. While creating WBS, you should not look at the different functions. ^[8]

• The WBS is a list of your work breakdown, and the task list is the breakdown of WBS in action. The tasks belong to the Project Schedule and come after you have made the WBS.^[8]

• The 100% rule: All the higher-level work must be represented in each lower level of decomposition. This means that all higher level's scope must be shown in one of the lower classes. It ensures that the whole scope has been captured and nothing unnecessary is included.^[8]

• You should be prepared for the WBS is rarely not right or complete in the first iteration. The more you learn about the project, the more you will define the WBS. ^[8]

• You should only decompose WBS components, giving more logical sense and not more than this. This means that the tasks must be small enough to be allocated to individual resources.^[8]

• There will be a summary task on the Project plan in the work package (lowest level). Each of the work packages should become a summary task. It is a collection of logically grouped tasks. ^[8]

• The 8/80% rule: This rule says that the work packages should be more than 8 hours and less than 80 hours. This rule is to indicate when you should stop working.^[8]

[edit] Limitations

When creating the WBS, there are some limitations the project manager should consider. The work packages must not contain many details because this will delay the project, making it hard for the project manager to control them. The WBS must include a list of deliverables and not activities or tasks, and this is what the stakeholder will receive when the project is done. The WBS is not a replacement for the project schedule or plan, but it is a visual decomposition of deliverables. Any changes in the WBS influence the process, deliverables, and project scope. There is a difference between the WBS and the Organizational Hierarchy. There always occurs misunderstanding between these two because they are similar in appearance. The WBS is restricted to the project and shows the project scope and the deliverables. While the organizational hierarchy shows things like lines of communication or chain of command. ^[9]

[edit] Annotated bibliography

• Project Management Institute,(2017). A guide to the Project Management Body of Knowledge (PMBOK guide). 6th Edition.

This guide has been used to get information on project management. It is a standard from PMI and contains different principles on project management and various useful tools.

• Project Management Institute,(2011). Practice Standard for Work Breakdown Structures. 2nd Edition.

This standard has been the essential resource of information for the WBS and project management. The book provides an understanding of how to use the WBS as a tool in project management. It presents the principles and gives information in detail on creating WBS to manage a project, program, or portfolio. Furthermore, it states which benefits implementation of the WBS can offer to a project. There can also be found some examples of the tool.

• DOD and NASA Guide, PERT/COST System Design, June 1962

This book is about the evaluation of the management system and how it started. There is information on how DoD and NASA implemented the work breakdown structure and how it developed.

[edit] References

1. ↑ ^{1.0 1.1 1.2 1.3 1.4} Project Management Institute,(2011). Practice Standard for Work Breakdown Structures. 2nd Edition.
2. ↑ Project Management Institute,(2017). A guide to the Project Management Body of Knowledge (PMBOK guide). 6th Edition.
3. ↑ DOD and NASA Guide, PERT/COST System Design, June 1962
4. ↑ ^{4.0 4.1 4.2 4.3 4.4} https://www.pmi.org/learning/library/applying-work-breakdown-structure-project-lifecycle-6979
5. ↑ ^{5.0 5.1 5.2} https://project-management.com/work-breakdown-structure-wbs-top-down-or-bottom-up/
6. ↑ ^{6.0 6.1 6.2 6.3 6.4} https://www.invensislearning.com/articles/pmp/how-to-create-a-work-breakdown-structure
7. ↑ ^{7.0 7.1 7.2} https://www.workbreakdownstructure.com/
8. ↑ ^{8.0 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8} https://www.youtube.com/watch?v=X2XJsjBadSI
9. ↑ https://www.projectsmart.co.uk/work-breakdown-structure-purpose-process-pitfalls.php