What is the work breakdown structure (WBS) in project management and how is it implemented?
What is the work breakdown structure (WBS) in project management and how is it implemented? The work breakdown structure is the translation of the term Work Breakdown Structure, which is known by the abbreviation (WBS). This issue can be confusing especially for new managers. But we should know that, contrary to its name and translation, this issue has nothing to do with the failures and downward trend of a project. Rather, dividing activity into small and partial categories, it prevents the failure of that project.
What is a Work Breakdown Structure (WBS)?
Sometimes, in a general definition, they mean this problem in the following way:
“A breakdown of the work delivery hierarchy, which is executed by the project team to realize the project objectives and create the deliverables required by the customer”.
Basically, the work breakdown structure defines the “how to do” the project. Everything you need to do in the project is displayed in a single, easy-to-understand diagram. The purpose of this diagram is to break down complex activities into smaller and more manageable elements.
For example
Here is an example of a work breakdown structure for an aircraft system. Obviously, developing an aircraft system is a very complex task. You need an aircraft (which itself is quite a complex undertaking), a system for training the staff and pilots, a way to manage the infrastructure, etc.
As shown above, a work breakdown structure breaks down all these complex activities into smaller, manageable constituent parts.
So, you might have a group responsible for building the aircraft. Within this group, there may be a team focused on building the airframe, another on creating the propulsion system, and so on.
Important note
It is common to have three levels of decomposition in a work breakdown structure. If you do very complex projects, you may have a fourth or even a fifth level. But for most projects, three levels are enough.
Describable items
You’ll notice that the job failure structure doesn’t describe any actions. Instead, each item is a noun that describes a finished product. A bicycle seat, fork, steering wheel, and…
For example, if you are creating a work breakdown structure for car manufacturing, items such as “car body” (a deliverable) should be described, not items such as “steel welding” (an activity).
Required terms
When working with the system related to the work breakdown structure, you will come across terms like “work”, “deliverables”, “work package”, etc. In the context of project management, these terms often have very specific definitions:
-
Work
In terms of the project life cycle (PMBOK), work refers to the “products of an activity (the deliverables that are the result of the effort, not the effort itself). That is, “work” determines the final result of any activity. The work remains the same even if the amount of effort required to achieve it is low or high.
-
Deliverable products
The project life cycle states that “any product, result, or unique and verifiable capability to perform a service that is required to be produced to complete a process, stage, or project.” Deliverables will vary from project to project and client to client.
-
work package
According to the definition of project delivery time estimate (PERT), a work package is “the work required to complete a specific task or process, such as a report, plan, all or part of a document requirement, a piece of hardware, or a service.” But the project life cycle has a simpler definition: “A work package at the lowest level of the breakdown structure is the deliverable work product.”
Essentials for the work package
- Be independent: The work package should be mutually exclusive and have no dependencies on other continuous elements.
- Defined: The work package must have a clear beginning and end and be understandable to all project participants.
- Be Estimable: You must be able to estimate the duration of the work package and resource requirements.
- Controllable: The package should represent “a meaningful unit of work”.
For example, if you are making bicycles, a “bicycle seat” might be one of your deliverables. All work required to create the chair (cutting the leather, shaping the floor, creating the metal frame, etc.) is part of the package.
Two planning methods for determining work packages
- Rule 80/8: each work package should not last more than 80 hours in total and at least 8 hours per day. If it’s longer, break it down further. If it’s shorter, consider moving up a level.
- Reporting Period: Limit each work package to a reporting period. If doing this takes more than one reporting period (monthly, weekly, etc.), break it down further.
What are the characteristics of the work breakdown structure?
Not every project deliverable analysis can be classified as a work breakdown structure. To be called a work breakdown structure, it must have certain characteristics:
1. Hierarchy
The work breakdown structure has a hierarchical nature. Each level will have a strict hierarchical relationship with the level before and after it.
2. 100% rule
Each decomposition level must be 100% of the parent level. It must also have at least two level elements before it.
3. Monopoly in communication
All elements at a particular level of a work breakdown structure must be unique while being related to each other. There should be no extra analysis of the delivery of products and their work. This is to reduce miscommunication and duplication of work.
4. Focused result
Instead of focusing on the activities required to achieve the product, the work breakdown structure should focus on the outcome of the work, i.e. the deliverable product. Each element must be described through a noun, not a verb. This is a great source of confusion for beginners of the work breakdown structure.
Examples of work breakdown structure
The best way to understand how work breakdown structures work is to look at different examples of work breakdown structures. While work breakdown structures are technically supposed to focus on deliverables, not activities (ie, nouns, not verbs), many project managers ignore this rule in real projects.
That’s why you’ll see examples of work breakdown structures where the high-level “deliverable” actually describes the activities.
Check Also:
