What is Work Breakdown Structure?
Work Breakdown Structure or WBS is a method used to decompose a project or large work into smaller manageable chunks of work. The PMBOK defines WBS as a "deliverable-oriented hierarchical decomposition of the work to be executed by the project team." It is widely used in the area of project management to break down a project into smaller tasks.
The smaller tasks are also known as "work packages." Work Breakdown Structure is predominantly displayed in a tree-like hierarchy format. This visualization makes it easy to see how the tasks are broken down. However, it is common to also a table-based approach.
Work Breakdown Structure (WBS)
Why do you need a work breakdown structure?
A project can have some tasks, and some can take a very long time to complete. As a project manager, you should track the progress every week (at the least). For you to track every week, you should ascertain if the tasks for this week are complete. To able to verify that you need smaller tasks so that you can know if they are complete.
Having a WBS also increases visibility as to who is doing what. Without WBS, the whole project would be just a big task. Without proper visibility, it would be difficult to know the progress and who is responsible for what. So, using WBS increases accountability in the project team.
Work breakdown structure also reduces risk by identifying task inter-dependencies as you actually go through the process of breaking down the tasks. When you have a big task, it is difficult to know the inter-dependencies.
WBS is an important communication and reporting tool. Color-coded tasks can represent status or delimit scope and accountability by identifying the different teams involved. The WBS should be clearly defined and built with the project team to be used as the scope baseline for the project.
What is the 100% rule in Work Breakdown Structure?
If not in the WBS, then not part of the scope; if in scope, then needs to be in the WBS - this is the 100% rule. When you apply the 100% rule, everything planned as part of the project deliverable is present in the WBS. There are a few advantages of this rule.
Following the 100% rule will assure the project manager that all the tasks have been covered in the WBS. This, in turn, will help in providing an accurate schedule and timelines. The project schedule is derived based on the estimate required to complete the work. The schedule affects the overall timeline of the project.
If everything is estimated for and included in the project scope, then there is a good chance that the project will run to the plan. On the other hand, if WBS does not include all the tasks, then some of the tasks may have to add later to the scope, resulting in the schedule getting delayed.
The key to effective resource planning is knowing what skills will be needed. A 100% complete WBS can be of great help as it will detail all the tasks, and reviewing the tasks, a project manager should identify the skills required. If the project manager is sure that everything is included in the WBS, he can confidently manage the project's changes. A simple rule can be that if it not in the WBS, then it is a scope change.
If the schedule, resources, and scope can be managed, then the project's budget will also automatically be managed.
How to create a Work Breakdown Structure?
Creating a WBS depends on the domain or the area of the project. A straightforward approach starts from the top and then works downwards, breaking the tasks into smaller tasks. I find it useful to ask two questions to determine when you should stop breaking down further.
First, will the task need to be done by more than one person? If yes, then you should break the tasks into 2. Second, is the task going to take more than 5 days? If yes, then break it down further. If a task is smaller than 5 days and can be done by one person, it is manageable. When a task is manageable, it is easier to track and is small enough to fix the ability to rework.
How to create a work breakdown structure
Step 1: Understand the work being done in the project.
As a project manager, you should know what the actual work being done is. It is essential to understand the domain. If it is a website building project, then understand the real tasks that need to be done. It does not need to be a detailed understanding, but it can be getting an overview from someone in the team or referring to similar projects done in the past.
Step 2: Organize a planning workshop this is a very effective way of coming up with the WBS
Getting together with the team and brainstorming can be very useful. Ensure you get everyone in the team involved in this meeting. Start from the top big task and then work your way downwards. When you reach the actual people who will be doing the work involved, you will always get additional details and any risks associated with the task.
Step 3: Document the Work Breakdown Structure
You can either use a template or software tool to document the WBS tasks captured. While there are many different ways of documenting a WBS, my preferred method is using Excel or MS Project. The hierarchy structure is suitable for visualization, but I personally find the table approach more useful. Also, you can use codes for task numbers. But there is no harm in keeping the task numbers as it is. The real value of a WBS is when you can use the information to manage the tasks.
Step 4: Socialize the WBS
It is also important to share the WBS created with everyone on the team. Sharing the documented WBS will ensure that the team knows what they are signing up for. It also gives everyone one last chance before the WBS becomes part of your project plan. If possible, review the WBS with a senior manager or SME who might provide some valuable feedback.
Step 5: Integrate the WBS into your project plan
Once the team WBS is ready, it is time to integrate it into your project plan. This is an essential step, as only after the WBS integration will you get an accurate picture of your project timeline. Integrate the major tasks in the WBS as you project milestones.
Work Breakdown Structure Template Excel
Excel is the most popular choice for documenting WBS. Our excel template comes with a dictionary that captures additional information about the tasks in the WBS. The template captures the WBS Code and Task Name as basic info.
Work Breakdown Structure Template Excel
You can filter the view to see the different levels in the WBS. The WBS Dictionary intends to remove any ambiguity from the project scope and provide robust information to enable successful delivery. The WBS Dictionary is a valuable communication tool, particularly when involving third parties in scope delivery.
The WBS Dictionary expands the WBS further by providing information about:
- Description of the task.
- The person is responsible for delivering that task.
- Resources required to complete the task.
- Acceptance criteria that will be used for sign-off.
- Constraints regarding time, cost, and others (e.g., quality).
Work Breakdown Structure Example: WBS for Software Testing
Breaking down the “Testing” tasks requires understanding the process of testing the software coded by the build team and the full scope of the testing work. There are a few good sources for this information: The SOW, input from the testing team, past similar projects, etc.
Once it is understood what the full scope and process are, it is then good practice to see if any smaller work blocks have different owners. If yes, then a further breaking down is needed. For example, let’s examine the “writing scripts” work block: there are 5 modules that need to do this task, each with its own team leader.
This means that this work block has 5 different owners and is in contrast to best practice #3. The result is that this work block is broken down into 5 smaller work blocks, one for each module. Since the scripts are all for the same procedure, it isn’t necessary to break them down further.
Work Breakdown Structure in MS Project
To add the WBS column, just right-click anywhere on the header of the table, and choose “Insert Column” or go to the “Format” ribbon and click on the “Insert Column” button.
Then scroll down to find WBS, or type it in the header of the column. The default column will present a basic numeric hierarchy, starting at 1 and adding a dot and an additional number for each indentation.
For example, the top summary task will be automatically numbered “1”, and the tasks under it will be numbered “1.1”, “1.2”, etc. If one of the tasks has a subtask, then an additional dot and number will be added.
For example, “1.2.1” means that the second task under the first summary tasks has a subtask. Each additional summary task will be in sequential numbering order; for example, the second summary task will be numbered “2”, and so on.
WBS MS Project
Customizing the WBS Column
Once the column is added to the table, it can be customized pretty easily. First, go to the “Project” ribbon and then click on the “WBS-> Define Code” button. The following menu will appear –
In the top field of the menu, the user will see a preview of the customized WBS code that will appear in each row. In the second field, the user can add a prefix for each WBS code, for example, “Dev” for a development work plan. It is recommended to add a dash “-“ at the end of the prefix.
The “Level” area is where it’s possible to change the appearance of the WBS column by using the following three columns –
- “Sequence”: The user can choose between numbers, uppercase letters, lowercase letters, and characters. If the user decides numbers in the top row, uppercase letters in the second row, and characters in the third, then the WBS sequence will be 1.A.*. The numbers and letters are sequential (ordered), but the characters are random.
- “Length”: Here, it is possible to limit the number of numbers, letters, or characters. The default is “Any,” which means that MSP will add characters as needed. If the user chooses “2” in the numbers row, then 1 will turn into 01. If the user chooses “3” in the uppercase row, then A will turn into AAA. It is recommended to leave the default “Any.”At the bottom of the menu, there are 2 checkboxes, and it is recommended to check them both. This will result in MSP automatically adding a WBS number to any rows that are added, and that it will make sure that there aren’t any duplicates in the WBS code.
The menu below will result in the following WBS structure: Dev-“Number”-“Uppercase Letter”-“Character.”
Read How Does A Smart WBS Enhance the Performance of Your Project?
Best Practices when working with WBS
- Top-Down: The preferred method of building a WBS file is by starting with the high-level plan. Each task in the HLP should be represented in the first tier of the WBS. Then break each task into smaller work blocks.
- 100% rule: Make sure that all of the needed efforts that go into completing the project appear in the WBS. This means that if the WBS is all done, then the project is as well.
- No overlap: Each WBS block must have one clear owner, and no task from the project’s scope should appear twice in the WBS.
- Deliverable is driven: The WBS shouldn’t be driven by effort or action but by deliverables or outcomes.
- Look: Prefer a graphical look over a textual one, which clearly states the hierarchy.
- Grammar: Use nouns over verbs. For example: “Analysis Document” over “Analysis Gathering.”
- Levels: A WBS should contain at least 2 hierarchy levels. Otherwise, it is a to-do list.
- KIS (Keep it Simple): Don’t go into a lot of detail; try not to create more than 6-7 tiers of work blocks.
- If you have access to Visio, prefer it over Word.