How do you break down your project into tasks using the WBS structure?

Are you a project manager looking to structure your tasks and plan your project? Use the WBS (Work Breakdown Structure) method!

Breaking down the work to be done into deliverables and sub-tasks helps organize your project into a clear, costable flowchart.

But how do you break down a project? And how do you make a good project WBS? See this article for a 4-step method, examples and tools!

See all software Project Management

WBS: definition and objectives

The WBS method is a project management technique that involves breaking down a parent project into child tasks, which are in turn divided into sub-tasks. The aim is to :

• structure the project,
• identify its overall architecture,
• visualize all expected deliverables and tasks to be carried out.

💡 The WBS, also known as the OTP (organization chart of project tasks), or SDP (project breakdown structure), originated in the Project Management Institute's PMBOK guide.

The WBS can take several forms:

• a flowchart, the most common form of WBS,
• a mind map,
• a list,
• a plan.

7 advantages of the WBS

• Highly visual: at a glance, you can see all the work to be done, priorities and urgencies, and limit the risk of being caught off guard as the project progresses.
• As a complement to the Gantt chart, it helps teams to better understand the dependencies between different tasks.
• It's an excellent communication tool for the various stakeholders, and builds trust with the customer.
• The project manager uses the WBS to allocate the total project budget to the underlying units.
• Improved risk management: at a glance, identify malfunctions, i.e. incomplete or erroneous branches.
• Anticipate possible delays in planning. Has a deliverable not been produced on time? It's easier to react to limit the impact on higher-level units in the same branch.
• Better distribution of efforts within teams: the project roadmap is clearer, and it becomes easier to readjust according to difficulties encountered during project management.

Example of a WBS

The following diagram provides a visual example of a WBS. It shows :

• the project as a whole, also known as the parent project ;
• divided into deliverables, called child tasks;
• themselves divided into sub-deliverables, also known as sub-tasks, depending on the level of granularity required to match the complexity of each task...

... and so on, until the units at the base of the flowchart are as manageable as possible for the teams: tasks at the lowest level, called " work packages" or " work units", no longer need to be broken down.

How do you break down a project using the WBS method?

Step 1: Define the project to be delivered

Start at the top of the structure, with a macro vision of your project. Define the contours of the total, finished project, the one you need to deliver to your customer.

This step gives you the direction to follow, and the meaning of each of the tasks that follow.

Example: a website design project for a local business

Step 2: Identify key deliverables

Next, identify the main deliverables directly below the finished project. Each deliverable marks the progress of the project and contributes to its completion.

In our example, the main deliverables, or child tasks, are :

1. analysis of customer needs,
2. definition and validation of project scope,
3. project planning,
4. site design,
5. site development,
6. testing phase,
7. go-live,
8. maintenance.

Step 3: Divide deliverables into sub-deliverables

Finally, divide each deliverable into sub-deliverables, or sub-tasks.

Our advice 👉 divide the sub-tasks into finer levels of granularity until the work packages at the last level are sufficiently costable and controllable, both from a budget and human resources point of view.

Let's take our example again. The child task "site design" comprises multiple sub-tasks, such as :

1. defining the site's structure, based on what already exists and what new features need to be added,
2. creating mock-ups for each page type,
3. designing site navigation,
4. creating a graphic charter to ensure the site's visual consistency, etc.

Step 4: Fill in the WBS dictionary

Nothing to do with that dear Robert! The WBS dictionary is a document that lists the content of each work package. Each work package has an entry that includes :

• the person in charge
• deliverables
• cost,
• deadlines and deadlines,
• main tasks to be carried out,
• any other relevant information needed to complete the project.

This dictionary is useful for defining the project's repository, including the WBS structure and specifications.

How to create a good WBS? Our tips for using it

Rule 1: follow the 100% rule

Applying the 100% rule means considering that a parent project forms a whole, containing all its "children".

In fact, a set of sub-deliverables must always display all the work required for the next-level deliverable.

Conversely, the sum of the units must not represent more than 100% of this higher level: the WBS method excludes any task that does not concern the project.

Illustration of the 100% rule :

Rule 2: avoid overlapping

When building your WBS, make sure that each unit is exclusive, and does not appear several times in different branches.

By avoiding overlaps, this rule protects you from possible confusion as to which teams are responsible for carrying out which tasks.

Rule no. 3: define the right cutting finesse

How do you determine it? Associate with each work package the estimated :

• the time needed to complete it,
• the associated cost,
• the resources needed to carry it out.

This rule helps you to determine the precision of your breakdown: if a deliverable can be quantified with a high degree of precision, it does not, a priori, require additional ramifications.

Rule 4: don't look for symmetry in the WBS structure

This principle follows on from the previous one: each branch of your WBS does not necessarily have to have the same number of levels, because the depth of the breakdown stops as soon as the lowest unit proves to be sufficiently costable.

As a result, the final shape of your WBS can be " asymmetrical".

Rule no. 5: target deliverables rather than actions

The best way to look at the project is in terms of results, not organizational or functional elements.

Our advice 👉 define your various units in terms of deliverables, not the actions required to achieve them. In this way, you gain flexibility in the process of carrying out each task.

Example of a WBS flowchart based on deliverables :

Choosing the right tool: Excel or dedicated software?

Building your WBS can sometimes be as simple as using a sheet of paper, a whiteboard or post-its. These tools are useful for brainstorming or exchanging ideas... but they quickly reach their limits.

👉 If your project is simple (few deliverables, few stakeholders), you can use Excel for your WBS. You'll find examples of WBS structures to adapt and customize on the Internet.

👉 For medium to large-scale projects, or when teams are dispersed, using software proves crucial to :

• build, and above all reinforce, the visual quality of the WBS - one of the most important prerequisites for its effectiveness,
• manage any modifications to the diagram much more simply,
• add a dimension of collaboration and agility to your project.

🛠️ Which software to choose for a good WBS?

• The advantages of Lucidchart :
  • easy-to-use, intuitive interface,
  • simple drag-and-drop operation,
  • customization of the flowchart created with your own deliverables,
• The advantages of monday.com:
  • an intuitive, visual tool,
  • a system of customizable tables to manage your tasks and sub-tasks,
  • visibility of deadlines for each deliverable.
• Gladys advantages :
  • a customizable dashboard to track project weather, time spent per person, per task and per project,
  • a simple, highly polished, web-adaptive interface (adaptable to all screen types),
  • a collaborative platform featuring tools adapted to your project management (Gantt, Kanban, Mindmap, etc.).

Common mistakes to avoid

Even with the best will in the world, a poorly conceived WBS structure can wreak havoc on your organization. Here are the most common pitfalls to avoid.

1. Confusing tasks with deliverables
We can't stress this enough: the WBS is based on deliverables, not project tasks.
A work breakdown structure (WBS) details what needs to be done.
The WBS indicates what needs to be delivered.
It's a breakdown by result, not by action.

2. Creating unnecessary levels
A WBS structure that is too granular can slow down project management. Each level must have a real purpose. If you have to go as far as "level 12.3.2.bis", it's time to take a break.

3. Forget the 100% rule
Each element of the WBS must represent 100% of the work to be done at its level. Not 80%, not 120%, but 100%. The rest is irrelevant.

4. Cutting and pasting without thinking
An example found online is tempting. But every project is unique. A prefabricated WBS can become a trap if it doesn't reflect your real objectives or resources.

5. Not involving the team
Team members need to be involved in breaking down the project. They often have a better view of the work to be done, especially in certain phases.

6. Forgetting to update the WBS
Projects move. And so must your WBS structure. If it remains static, it loses all interest for real-time monitoring.

7. Do without the right tool
Why not build a WBS on Excel? But as your project grows, a project management tool quickly becomes indispensable. It helps you :

• visualize levels,
• allocate elements,
• keep track.

After WBS

The WBS method provides an overview of the structure of a project at the outset, and of the course to be taken to complete it. Keep in mind that other complementary tools are available to compensate for the shortcomings of the WBS. For example, PERT and Gantt diagrams to identify deadlines and interdependencies between tasks.

Equipping yourself with the right tools will not only make you more flexible and agile, but will also save you time later on when it comes to managing your project.

See all software Project Management

FAQ on the WBS method

What is a WBS in project management?

The WBS, or Work Breakdown Structure, is a hierarchical breakdown of a project into successive deliverables. Each element in the structure corresponds to an expected delivery, not a task. The result: a clear vision of what needs to be produced, at what level, and by whom.

What's the difference between WBS and Gantt?

The WBS structure breaks down the project into deliverables. The Gantt chart, on the other hand, organizes tasks over time. The former structures work content, the latter plans phases and their duration. They complement each other. And no, it's not a Gantt vs. WBS battle: they work hand in hand.

Should WBS be used for all projects?

Not necessarily. If you're organizing a team cocktail party or an office move, there's no need to bring out the WBS structure. But as soon as there are several deliverables, varied resources and structured project management, the WBS becomes an invaluable ally. Even small, complex projects benefit.

How many levels are needed in a WBS?

There's no magic number. Generally speaking, between 3 and 5 levels are sufficient. The aim is not to create a gas factory, but to have a structure that is clear, legible and useful for monitoring work. Too much detail kills organization.

Is it possible to create an agile WBS?

Yes, but with flexibility. In an agile project, the WBS structure can be used to map the major objectives or deliverables expected by sprint or phase. It is then used as a compass, not as a fixed map.