Work Breakdown Structure in project management

Abstract

WBS stands for Work Breakdown Structure. It is a method of dividing a project into smaller tasks and putting them into a hierarchy. The idea is that you want to clarify the tasks in a project, and you do this by breaking the tasks down to a manageable size. By breaking down the tasks, you put them into a hierarchy, so you can easily and see the prioritization and place of affiliation to the various tasks. You start by putting the target itself in a box at the top. Then you make some subcategories such as analysis, requirements specification and development. Then you take one of the subcategories and break it down into even smaller tasks. This is how you sort until you have come down to specific tasks. With these methods, you will achieve a more manageable planning and a good way to graphically present the tasks to the rest of the project group. It will be easier to make a time estimate of the entire project process, as you have clarified the scope of the project and what it contains.

History

Work Breakdown Structure was developed by The United States Department of Defense (DoD) with the Program Evaluation and Review Technique (PERT). In 1957, PERT was introduced to U.S. Navy to assist the development of Polaris missile program. DoD and NASA published in June 1962 a document about PERT/COST, it was the first approach to WBS. This guide was implemented in all services across DoD as a military standard.

Importance of WBS

As a project manager, you know that many things can wrong in projects regarding how effectively they plan and implement their 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 as well as 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 scope.

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 deliverables and objectives of the work to be completed. It is a description of the project’s deliverables, scope, and outcomes. The WBS is specifically limited to describe and deal with the project’s scope or outcomes, and 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 and 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.

Defining the WBS

The WBS is known for having at least 3 levels. The first level also known as the upper level reflects the major deliverable work areas and is broken down into logical groupings of work. The first level's content can depend on the type of industry and project involved. The second level provides proper focus and detail for support of 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 definitions of the work 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, we can spend on the project, the project manager can have a look at the structure and determine it. When we add up the budgets for each item of the structure, we get the total budget of the project and as we execute the project plan. If we find we are always spending in some areas that forces the project manager to look at other areas that are either in progress or haven’t 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 we can do with the WBS is looking at the types of skills we need.

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 by yourself. By involving the team in the planning stage, you get a better understanding of what and who needs to be done/do the tasks. When creating the WBS build it by defining what deliverables needs to be made.

- There should at least be 3 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 size and complexity of the project.

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

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

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

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

- You should only decompose WBS components, so they give more logical sense and not more than this. This means that the tasks must be small enough to be allocated to individual resources.

- There will be made the 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.

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

References

DOD and NASA Guide, PERT/COST System Design, June 1962 https://www.mosaicprojects.com.au/PDF/PERT-Cost_Evaluation_1964.pdf