Building a Work Breakdown Structure WBS: A Complete Guide

What do you do when you want to read a simple article from a newspaper? I don’t know you, but I simply get the newspaper, sit on a chair and read the article. Not so much to think of, right? Now another situation: what do you do when you have to read five books of 500 pages each for an exam or certification that’s coming up at a predetermined (and known) future date? Well… You don’t just take the books, sit and read. You break down the content of the books into different sections, and define when you are going to study each of them. Then, you create a schedule and make sure you have resources to document all the important information you go through while studying. This involves much more planning and thinking than the simple task of reading a newspaper article.

In a general way, complex tasks require prior planning as well as the decomposition of its major components into smaller tasks in order to be successful. The Work Breakdown Structure (WBS) is a very powerful concept and tool to help you achieve it. The principles you will learn here are important not only for project management but also for any complex activity you might execute in the future!

So let’s go through all the aspects of what is a work breakdown structure and how to build an effective one.

What Is a Work Breakdown Structure (WBS)?

A WBS is a structured task list of every task involved in the project. It takes the complex project and breaks it down into manageable tasks. It’s like solving a big math formula. You can’t immediately state the final result, but if you start operating the inner parentheses, followed by the outer ones, and finally by bringing the smaller results all together, you get the final answer. A project works in the same way.

The WBS is the tool you will use to clarify the details of many tasks involved in the project. Here are a few benefits of building a WBS:

Visualize the structure of the project scope and its many components. While the project charter will give a conceptual definition, the WBS is necessary for a practical perception.
Check the progress and the current state of the project since the WBS tasks for a unit of measurement.
Precisely estimate the budget and the schedule of the project.
Define the members of the project team. The WBS provides the information needed for understand what will be done, so you can choose the best people to do it.

The WBS is very useful when you are creating the schedule, the estimations and considering the resources you need for your project. Building the WBS is also good as a team building activity, and it helps you gain information from those who are working on the project. Finally, after building the WBS you can discuss more clearly issues like time, risk and resource management.

The Structure of a Work Breakdown Structure

The WBS can be created as a graph or as an outline. Both forms will do the job of defining the tasks and identifying the relationships between them. Here are two examples (just examples, I don’t list all the work packages and summary tasks related to the project since they vary according from company to company), one of each structure. Personally, I prefer the graphic approach as it also provides a nice visual aid to visualize the scope of the project.

Improvement of HR Selection Process [Graphical Approach]

Example Work Breakdown Structure HR Project

Improvement of HR Selection Process [Outline Approach]

Map the current selection process
1. Survey the current documents for selection process
2. Interview the current HR manager
3. Develop a blueprint of the current process
Develop new selection process
1. Identify inefficiency points in current process
2. Propose changes and map the improved process
3. Implement the new process across sectors
Train the staff on the new process
1. Develop training based on the new process
2. Contact experts and organize schedule of training
3. Implement training

There are two types of work elements in the examples: summary tasks and work packages. A summary task involves several subordinate tasks, each one called a work package. In our example, a summary task can be outlines as “Map the current selection process”, and this task can be further broken down into several work packages like “Survey the current documents for selection process”, “Interview the current HR manager”, “Develop a blueprint of the current process”, etc. As you can see, work packages are practical tasks that can be objectively marked as completed. The summary task is marked as complete when all the work packages involved in it are successfully executed.

Don’t go all crazy about detailing every single possible task. Like, there is no need to break down the summary tasks and work packages into extremely small and detailed tasks. We will get to that in the future, when we cover the 8-80 rule, but just keep in mind that it’s important to define tasks in such a way that they are not too narrowly nor too broadly defined.

Building a Work Breakdown Structure

Ready to get your hands dirty? Building a good WBS is critical for the success of your project. But this is not always easy, and you have to be careful not to oversee any fundamental tasks or mess up the structure of the project. There are three practical steps to make sure you stay on track.

Step 01 – Begin at the Top

What are the major deliverables and the most important high-level tasks of your project? Start by listing them in your WBS. And remember that you should also include intermediate deliverables necessary for the final outcome to be achieved. When creating the general structure of your WBS, keep in mind that all deliverables must be included, even if they cannot be all executed at the same time. The goal of the WBS is not to represent time constraints or to focus on a specific planning period. Instead, the WBS should list all the deliverables of your project so you have a detailed overview of what you want to achieve by the end of it. The construction of the schedule and its estimation comes afterwards, and we will cover more of that in the future.

The processes that represent the major sections of your project’s lifecycle are classified as “tier 1” processes.

Do your WBS in “rounds”. What do I mean by that? Don’t expect to sit and, at once, list all the activities and finish the WBS. Instead, write down several things that come to your mind and, when you see your brain is failing you, let the WBS rest for a few hours. Then come back to it and start filling other tasks that come to your mind. Show it to other people so you collect opinions, revisions and improvements.

Step 02 – Name All the Activities Required to Generate Your Deliverables

“Pages 1-37” does not produce any deliverable. “Read through pages 1-37” produces one. The difference? Label the tasks by using verbs that indicate the necessary steps to generate a deliverable. Sounds silly, I know, but it actually helps.

The next step is to break down each of your deliverables into more specific tasks required to develop the outcome of the project. It may seem easy, but this is one of the most complicated parts of the planning process, especially if your project involves technical specifications. In this case, you should consult the experts in your company in order to make sure the WBS is comprehensive and accurate.

This is a great moment to include other members of your team to make sure all the tasks are listed down. In the end, you should reach a consensus among several people to guarantee that the listed tasks are actually the required ones (not more, not less) to successfully accomplish the desired outcome.

Including several people in your WBS allows not only a more detailed document but also higher levels of engagement of members. Don’t be afraid of asking for help, and keep in mind that your role as a project manager is not to do everything alone, but to bring the best of each stakeholder involved in the processes.

If you find it useful, include your members earlier in the WBS process. In fact, my suggestion is to include them early and bring some input to discuss with them. For example, you can schedule a meeting and say “so, these are some tasks I could think while considering the project, but I need your inputs on how to make sure we cover every aspect of it”.

Step 03 – Fine-tune Your WBS

After having defined all the work packages, you are free to play around with them. Maybe the initial hierarchy you designed is not the best one, and you think it’s better to allocate “work package A” under “summary task B” instead of “summary task A”. If it makes sense, do it!

The way you arrange the work packages defines the focus of your project. It may be the case you have the same work packages, but one distribution focuses on the product development, while other one focuses on the product promotion and distribution. Independently of the way you structure the work packages, you should keep in mind that the summary tasks are there for communication purposes, while the work packages are there for practical purposes. If there are summary tasks that communicate nothing (or communicate duplicate information), erase or merge them.

Successful Criteria for Building an Outstanding Work Breakdown Structure

Now that we already covered the basics, time to take a deeper look into the different characteristics that make a WBS successful.

The WBS Must Be Broken Down Starting at the Top

Ok, so what’s the difference between starting at the top and at the bottom? A fundamental one! When you start at the top, you focus on what you want to achieve at the end of the project. You take that final objective and break it down into its several components, and you keep doing so until you have identified all the relevant work packages. If you start at the bottom, it’s very easy to forget to include several work packages. This happens because you don’t have the big picture, and working by adding several smaller pieces to create a bigger one can be a tricky thing. The philosophy is simple: start at the top and ask yourself “what do I need to achieve this?”. And keep doing so for the next levels.

Once you are done, it’s time to revise the WBS and check if it is coherent. Now it makes sense to use a bottom-up strategy. Look at your work packages and their relationship to the summary task. Is the work package a subset of the summary task? Is it correct to place the work package there? Are all work packages nested into a summary task?

This will give you a good picture of the components of a summary task, and you can estimate several things about it based on the work packages. Bring our example back: it is quite hard to estimate the time to “study module 01”, but you can infer with some degree of accuracy the time required to read the pages, take the notes and do the exercises. As long as these are the only components of studying module 01, you can estimate the time necessary to complete the summary task by adding the time of each work package. This works not only for schedule, but also for budget. Once you have the meaningful work packages in place, you can go ahead and build reliable estimations.

Work Packages Must Sum Up to the Respective Summary Tasks

Again, the problem of omitting necessary tasks. This is why you start top-down, so your chances of forgetting something are lower. Still, it might happen. Therefore, when revising your WBS, make sure to test whether the work packages actually add up to the summary task, i.e. if the summary task is completed once the mentioned (and only the mentioned) work packages are executed. If you notice there’s something missing, go ahead and add it.

Summary Tasks and Work Packages Must Be Named Like an Activity that Produces a Result

Why? I like examples, so let me give you one more. You are leading a project in a HR agency, and you write “Selection Process” as one of your summary tasks. A few days later, someone who is not really aware of the project takes the WBS to get more information about it and… “hmmm… Selection process… What do you mean? Is the project going to create a new one? Will it document our current one? Will it restructure it?”

Got it? Despite sounding like a silly advice, a simple verb can make things way clearer! It gives focus to your efforts. By describing your summary tasks and work packages with precise verbs and nouns, you make the WBS (and, consequently, your project) much easier to understand.

How Big Should Your Work Breakdown Structure Be?

Take back our module 01 and our work packages. The work package “read pages 1-37” can be further divided into “read page 1”, “turn the page”, “read page 2”, “turn the…” Enough! There is a limit, you see? One of the biggest problems of building a succinct yet meaningful WBS is exactly finding out when to stop (seems like the fast and furious franchise didn’t learn this lesson in class…).

If a work package is expected to last for months and involve several people in your team, is it really a work package? No! It’s more like a subproject, and it should be treated like so. The problem of having such long work packages is that, inevitably, they become unmanageable. So here are three guidelines to help you decide whether a work package should be further broken down:

The 8/80 rule

Try to define your tasks in a way that their duration is neither shorter than 8 labor hours nor longer than 80 labor hours (i.e. between 1 and 10 working days). The reason is that if it’s shorter than 8 hours, you could be micromanaging, and if it’s longer than 80, you might easily lose track of the work being done. This is a general guideline and you shouldn’t take it as an absolute rule: if you need tasks with different duration, go for it.

The reporting period rule

Your tasks should not be longer than the period between two reporting points. If you have weekly meetings, try to keep the duration of your tasks shorter than a week.

The “if it makes sense” rule

Ok, does it make sense to group several tasks into a bigger one or to break down a bigger task into smaller ones? When thinking about it, consider the following consequences: the task becomes easier to estimate; the task becomes easier to assign; the task becomes easier to track. If these consequences are present when grouping or breaking down tasks, then you should probably go ahead. If it doesn’t make sense, i.e. it doesn’t make a difference to the estimation, assignment or tracking, don’t do it!

Planning for Quality

We all know that it’s cheaper to design a product correctly than to fix it afterwards. The earlier you identify the error, the cheaper it is to fix it. You should keep this in mind while creating your WBS. You can, for example, insert specific work packages related to quality check throughout the life cycle of the project. Later on, while developing your schedule, you can position these quality checks in key places to make sure your product or service meets the quality criteria. How can project management help you achieve a better quality, more reliable product? We have two major tools: risk management and completion criteria. We will dedicate an entire article to risk management, but the completion criteria can be discussed here.

Understanding the Completion Criterion

How do you know a work package is completed? Not only that, but how do you know whether it was done correctly? These questions should be asked as early as possible, and you should clearly define what are your quality criteria. But is it that easy to measure the quality and the completion of all parts of a project? The answer is an obvious “no”. How can you measure the quality of a document like the blueprint of your new selection and hiring process? Or of a new, reformulated business plan? Measuring the quality of such outcomes is not that straightforward, but here are a few suggestions:

Look for peer reviews. Several heads think better than one. Get together a group of people related to the project (include an expert if possible) and walk through the plans and the estimations related to your outcomes. This should be done as soon as possible (preferably before the executing phase, to avoid any change of course due to a mistake). Despite not guaranteeing perfection, peer review brings way better results than a sole endeavor.
Use checklists. The checklists should cover the standard tests and the required components of the product you are developing. Of course, whenever you run a project to create something, this something is supposed to be unique (if not, you might be just running operational activities). Therefore, it is not possible to develop in advance a complete checklist to something that doesn’t exist yet (that would be the same thing as developing the WBS, duuh…), but you can use your experience to create a checklist for the common, standard components of your new product or service. This is a very good practice, and past knowledge can be particularly useful when building this document.
Run systematic testings. Systematic tests can be used throughout the development, execution and quality control of your product or service. They submit the outcome to specific conditions in order to check whether it meets the quality criteria previously established.

So what is your completion criterion? Using the three suggestions from above, we can think of a few examples of what a completion criterion can be: receiving the approval of your peers, passing a checklist, successfully passing all your tests, etc. By setting these points as benchmarks, you have a good answer to our two initial questions. You know that the product or service is completed successfully when it meets the criteria defined in the previous processes.

What Comes Next?

We covered a lot of ground here! By now, you should be an expert in developing a great WBS and we can move on to the next topics related to planning your project. In the next article, we will discuss how to estimate the duration of your tasks and how to create a time schedule.

The Ultimate Guide To Building a Work Breakdown Structure