Part 1: Introduction
Here’s what PMBOK says,
“A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives (Scope) and create the required deliverables”
It’s hard to follow and even if you understand it, you wouldn’t be sure why to use it or how to use it.
Have a look at the Work Breakdown Structure below,
Imagine you have a document and you have to search for something particular. Would you be able to find it? Yes, Sure.
But it will be a nightmare to search through hundreds of pages.
When you have a Work Breakdown Structure, it gives you a brief idea of how the project is to be completed and clearly defines every aspect of it.
Initially, the Scope is defined and WBS is created, and every element of it is explained in detail in the WBS dictionary.
So that every aspect of the project is clear and every team involved in the project is aware of their roles and responsibilities.
Let’s try to understand this with examples.
Example #1
Consider a flyover project by the government that has to be completed within a year. Hundreds of tasks will have to be completed before it is ready for the public.
You need engineers, workers, and equipment handlers for the project, and all of them have to collaborate for the project to be completed.
For the construction of support columns, a few people could be responsible for reinforcement, and another could be responsible for concrete mixing and pouring.
In short, when multiple groups are involved in part of the work, it becomes difficult to manage them or to comprehend the overall scenario.
Example #2
Let’s try to understand with another example,
A company manufacturing motorcycles has a lot of complex parts and needs to be efficient enough to keep the assembly line running.
Collaboration between different departments is key to achieving their targets. As each step of manufacturing is dependent on the others.
With WBS, you get a brief idea of what the work is at every step of the process.
Before trying to create a WBS you have to be aware of a few of the terminologies related to WBS.
- Project Scope is the work needed to be completed to achieve the desired outcome of a project or service.
- Deliverables are the outcome of the project.
- WBS dictionary is a detailed document explaining every element of the WBS. Deliverables and Scope are defined at every stage, it also include the schedule and cost of the elements if needed.
Before creating a WBS for a project, a few guidelines need to be followed for it to be successful.
Design Principles:
- 100% rule
While creating a WBS, you will be tempted to include every aspect of your project in the WBS, and I can understand why. But it’s necessary to keep things short and concise. The sum of work at every level should not be more than 100% of the work of the above level. And the scope of work at any level should not be outside the scope of the project.
- Mutually exclusive elements.
All the tasks involved in the WBS should be mutually exclusive, and the tasks shouldn’t overlap. Thereby solving the problem of accountability. This also ensures that the same work is not done twice and prevents duplicate work. To ensure this, you should be able to define every element independently.
- Outcome-driven approach.
Each element of a WBS should be an outcome, not an action. Because the very idea behind WBS is that it should be deliverable-oriented.
Product Breakdown structure is a very good example of an outcome-driven approach. Each element at every stage is a component. Have a look at the PBS of a smartphone.
- Coding Scheme
The elements of a WBS are coded in a specific way to help understand various aspects of it. After creating a WBS, a WBS dictionary is made, detailing every element to a sufficient level. So the coding scheme comes in handy while searching through the WBS dictionary. Looking at the image below, we can see that numbering at every stage is placed after the decimal point. And every new element in a stage is numbered accordingly.
