WBS: Work Breakdown Structure or
Wild Bovine Secretion
PMBOK® Guide Definition:
Work Breakdown Structure (WBS): 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.
Work Package: The work defined at the lowest level of the work breakdown structure for which cost and duration can be estimated and managed.
Work Breakdown Structure Component: An entry in the work breakdown structure that can be at any level.
100% Rule: The total of the work at the lowest levels should roll up to the higher levels so that nothing is left out and no extra work is performed.
Practical Definition:
Work Breakdown Structure (WBS): A deliverable-oriented, hierarchical decomposition of the project. Deliverables (work packages) create the results of the project so the project objectives are met.
Work Package: The project deliverables defined so they can be accurately scheduled, resourced, and budgeted. They are described as the “nouns” of the project – tangible project results. Also known as work packets.
Work Breakdown Structure Component: A component of work in the WBS; may be at any level.
100% Rule: The WBS contains all the work and nothing but the work required to complete the project.
8/80 Rule: The level to which we decompose the WBS structure representing nothing less than 8 hours and nothing more than 80 hours of effort to complete that WBS components.
1/10 Rule: The level to which we decompose the WBS structure representing nothing less than 1% and nothing more than 10% of the estimated project duration to complete that WBS components.
Introducing the Work Breakdown Structure Concept
To many, the abbreviation WBS expands to Work Breakdown Structure. To many others, it means wild bovine secretions and a lot of extra work. Yet unknowingly, many project managers and teams develop a work breakdown structure without formalizing it. After managing several projects of similar types, teams realize they must consider many perspectives, define the high-level categories of work and break them down to bite-sized pieces to meet the project objectives.
The teams will gather in a room, brainstorm the various steps needed, order them into a plan and then attack the project work. Ask the same team to put it into a formal structure or follow a defined process, they bulk at the “extra” work which they have already completed 90% of it. Interestingly, by documenting their effort, they can save themselves a lot of effort in future projects by simply using the previous “WBS” and modifying it with updates pertinent to the current effort.
We learned this while consulting to a large telecommunications company. We were hired to manage a large-scale introduction of services to the telephone network. Although we had managed many projects of similar nature throughout our careers we, like most, had no formal education in project management. We learned our lessons as others had: School of Hard Knocks and watching other people.
The magnitude of this project was very large. Our immediate team exclaimed, “Where do we start?” Our response was, “Well, let’s start here” and proceeded to list the various components of the system on the board. The components essentially represented the various divisions which needed to be involved: Product Management, Product Marketing, Sales, Billing, Provisioning, Customer Service, Operations and Maintenance, R&D, etc. Those divisions became our top level of what we learned later was called the work breakdown structure. We further refined our divisional listing into smaller pieces and applied names to the “boxes” so we could contact those people to learn more about what they needed to do on the project in order for us to be successful. For many on the team, this was the first time they had “seen” such a structure of a telecommunications project. Years later, several team members contacted us to let us know they were still using the model.
What did we do? We defined the project in terms of company divisions. We represented the project by listing those who needed to be involved and learned from them the work necessary to accomplish the project goals.
Defining the Work Breakdown Structure (WBS)
The WBS is a hierarchical decomposition of the total scope of work to be completed to accomplish the desired results of the project. Stakeholders have expectations on the project. The WBS gives us the ability to systematically break the project scope into smaller pieces using a graphical format. When finished, the work breakdown structure represents all the work to be accomplished on the project and includes no work that should not be done. We like to say the WBS is the contract between the project manager and sponsoring company. If the work is represented in the WBS, project managers are contractually obligated to perform it. If it is not in the WBS, we are contractually obligated to not perform it. By sticking with this hard line, project managers begin to control scope creep, which is implementing work not formally approved for the project.
Once created and approved, the work breakdown structure helps direct the project work. It can be changed through proper change control so additions to the WBS can be fully understood. We must understand the impact to the schedule, budget and resources before we implement the change. If we don’t perform this analysis, we severely impact our project results, especially the “on-time, on-budget and on-scope” measurement.
We decompose the WBS to the work package, a.k.a., work packet, level. Decompose is a fancy term for breaking the problem into smaller pieces for better understanding. Work packages represent the deliverables of the project. We can determine the schedule (duration), budget and resources required to complete the deliverable. As we complete each deliverable, we can calculate the earned value of the project and determine the state of the project. See our Earned Value Management article series for a complete understanding of Earned Value Management. When all the deliverables, or work packages, are complete, the project is complete.
So, the Work breakdown structure is a hierarchical decomposition of the project to the work package level. It represents the entirety of the project.
Work Breakdown Structure Example
Let’s say, we are remodeling a room in the basement. The current room’s condition is
- Concrete floor which causes the room to be chilly and damp
- Walls currently insulated and dry-walled, previously painted but some water damage at bottom
- Suspended ceiling with damaged tiles – must decide to keep or replace with dry-wall
The remodeling goal is to provide a den for children and their friends. Room should be comfortable and inviting. As an added bonus, room should easily convert to man-cave once children leave the nest.
Below is a simple work breakdown structure of the four major components of the project:
- Ceiling
- Walls
- Audio/Visual
- Floors
The WBS decomposes to 13 work packages outlined in red dashed lines. Each work package is considered a deliverable in the project. The cost to produce the work package will be tracked through receipts for the materials. Labor is being provided by the home owner, so no charge.
Here is a hierarchical graph representing the project:
 |
| Work Breakdown Structure in graphical format |
Placing the WBS in Microsoft Project, we see an outline format.
 |
| Work Breakdown Structure in Microsoft Project |
Each indented level in Microsoft Project represents the successive levels of the WBS. At the top in the Project Summary Task, we see Basement Den Remodeling Project just as we see it in the WBS. The next level of indent list Floors, Walls, Ceilings and Audio/Visual represent another level of decomposition in the WBS, and so forth. Finally, the work packages are listed with their associated time estimates and costs. In Microsoft Project, we would further decompose the work packages into the activities or tasks required to create the work package (deliverable).
For example, under Walls, we see Paint. Here are the activities associated with painting walls:
- Wash original walls to remove dust and dirt
- Spackle and patch dents, holes, scratches
- Remove light switch and outlet covers
- Tape around anything where paint should not go
- Paint
- Cleanup
The WBS does not contain the activity list. It decomposes to the work package level and stops.
WBS Dictionary
An important piece of the work breakdown structure is the WBS dictionary. Each WBS component, especially the work package, should be further described in the WBS dictionary, which is a document. Just as a word dictionary provides the definition for a word, the WBS dictionary provides the definition for the WBS component. The WBS dictionary definition should include the following for each project deliverable:
- WBS code (code of account identifier)
- Description of the work component
- Responsible organization for component completion
- Schedule milestones
- Resources required – special skills, number of resources, etc.
- Cost estimates
- Quality requirements
- Acceptance criteria
- Duration estimates
- Other pertinent information, such as risk factors, dependencies on other components or organizations, etc.
As can be seen, the WBS dictionary contains a thorough understanding of the respective component it describes. And yes, it can be a lot of work. Better upfront planning and understanding has proven to save execution time and rework costs many times over. Plus once established, this information can be valuable and re-used in similar future projects.
WBS Code
Each WBS component is numbered for easy reference and look-up in the WBS dictionary, uniquely identifies it in the WBS graphic and ties the component to the accounting chart of accounts. This code is called the WBS code and the collection of codes is called the code of accounts.
For example, the top level component which contains the project name is numbered zero (0). The first level down, from left to right, the components are number 1.0, 2.0, 3.0, etc. For our example, our four top-level components would be numbered:
1.0 Ceiling
2.0 Walls
3.0 Audio/Visual
4.0 Floors
The next level down is numbered consecutively as a sub-value of the level above:
1.0 Ceiling
1.1 Ceiling Lighting
1.2 Ceiling Decision and Selection
1.3 Ceiling Installation
2.0 Walls
2.1 Theme Decision
2.2 Paint
2.3 Trim
By looking at the code, we can easily tell a component whose code starts with 1 belongs to the Ceiling deliverable. Any tasks which begins with a 2 falls under the Walls. The next level down would simply add another layer of numbering to it. So for our example, the complete set of codes is:
1.0 Ceiling
1.1 Ceiling Lighting
1.1.1 Lighting Selection and Order
1.1.2 Lighting Installation
1.2 Ceiling Decision and Selection
1.3 Ceiling Installation
2.0 Walls
2.1 Theme Decision
2.2 Paint
2.3 Trim
3.0 Audio/Visual
3.1 Audio
3.1.1 Audio Equipment Selection and Order
3.1.2 Audio Equipment Location Decision and Installation
3.2 Video
3.2.1 Video Equipment Selection and Order
3.2.2 Video Equipment Location Decision and Installation
4.0 Floors
4.1 Subfloor
4.1.1 Floor Insulation
4.1.2 Floor Underlayment
4.2 Carpet
4.2.1 Carpet Selection and Order
4.2.2 Carpet Installation
We used a simple coding system here. Companies may use more elaborate schemes whereby the project name, department or division name, product name, etc. may be encoded in the WBS code so it becomes easily identifiable in their accounting system for cost tracking. Regardless of the complexity or simplicity of the code, it must uniquely identify the WBS component in the Work breakdown structure, the WBS dictionary, the code of accounts and the accounting chart of accounts.
Conclusion
To many people, the WBS represents wild BS and yet, they eventually develop it. As can be seen from this article, a methodical and standardized approach to developing the Work breakdown structure is foundational to a well-planned, well-understood project. Although some may consider this work appropriate for only waterfall planning and not applicable to Agile projects, the WBS provides the structure of project planning so the final results matches what the customer envisioned and wants. Agile projects can easily benefit from its guidance as the sprints are concluded and modifications are made.
Yes, the WBS represents additional work for projects, at least initially. Once built, the information can be re-used in similar projects. While not all details may be applicable to the next effort, the high-level structure ensures project aspects are not inadvertently left out of the planning process. As we experienced in managing telecommunications project introducing new features into the telephone networks, the same divisions were involved and much of their work was repeated regardless of the service being deployed. Divisions appreciated the fact we could hand them a “template” of activities making their planning processes easier, shorter and more comprehensive.
So, does WBS really stand for the decomposition of work, a.k.a., the Work Breakdown Structure or does it really mean just some wild bovine secretion? Only you can decide, but we bet, if you are doing any type of planning, you are creating the breakdown structure in some way.
PMBOK® Guide is a registered trademark of the Project Management Institute. All materials are copyright © American Eagle Group. All rights reserved worldwide. Linking to posts is permitted. Copying posts is not.