How to build a work breakdown structure

Ask someone to plan a kitchen renovation and they'll usually start listing actions: "call a plumber, buy tiles, paint the walls". Within a minute the list is twenty items long, half-overlapping, and missing three things they'll only remember when it's too late. The problem isn't effort. It's that they started with activities instead of deliverables — and that's exactly the mistake a work breakdown structure is designed to prevent.

A work breakdown structure (WBS) is a hierarchical decomposition of everything the project will deliver, broken down level by level until each piece is small enough to estimate, assign, and manage. The crucial word is deliverable. A WBS is not a to-do list and not a schedule — it has no dates, no order, no arrows. It is the answer to one question: what, in total, are we producing? Get that right and the task list, the estimates, and the schedule all fall out of it cleanly. Get it wrong and everything built on top inherits the gaps.

Deliverable-based vs phase-based

There are two ways to draw the top level of a WBS, and the choice sets the tone for everything beneath it.

• Deliverable-based decomposes by thing produced. A website project's top level might be: Designs, Content, Built site, Launch assets. Each branch is a tangible output you could point at.
• Phase-based decomposes by stage of work. The same project: Discovery, Design, Build, Test, Launch. Each branch is a period, and the deliverables sit underneath.

Most modern guidance favours deliverable-based, because it's harder to forget a deliverable than a phase, and because it ties the breakdown to outcomes rather than calendar buckets. Phase-based reads more naturally to people who think in timelines, and it maps tidily onto a Gantt chart later. Neither is wrong. If you're unsure, go deliverable-based at the top and let phases emerge as sub-levels where they help.

The 100% rule

This is the one rule that makes a WBS trustworthy, and it cuts both ways. The children of any element must add up to exactly 100% of that element — no more, no less.

"No less" means if you break "Course content" into modules 1, 2, and 3, but there's actually a module 4, your WBS is lying — it has lost work. "No more" means the children mustn't include anything that isn't part of the parent: if "Build site" sprouts a child called "Plan marketing", that work belongs in a different branch, and you've created overlap. Overlap is insidious because two people both think the other owns it, or both do it, and either way the breakdown stops being a clean map of the work.

Work packages: where the breakdown stops

You don't decompose forever. The lowest level of each branch is called a work package — the smallest unit you'll actually plan and track. A work package is a deliverable small enough that one person (or one small team) can own it, you can estimate its effort with reasonable confidence, and you can tell unambiguously when it's done. "Record module 2" is a work package. "Make the course" is not — it's the whole project. "Press the record button" is too small — it's a step inside a work package, not a unit of management.

How deep should you go? The 8/80 guideline

The most-cited rule of thumb is the 8/80 rule: a work package should represent somewhere between 8 and 80 hours of effort — roughly one day to two weeks. Smaller than a day and you're tracking noise; larger than two weeks and the package is a black box where slippage can hide for too long before anyone notices.

Treat 8/80 as a sanity check, not scripture. A useful companion is the reporting-period rule: no work package should be longer than the gap between your status updates. If you review the plan weekly, a three-week work package will sit at "in progress" for two reviews running and tell you nothing about whether it's on track. Break it down until each piece can plausibly change status between reports.

How to actually build one

Three approaches, all of which reach the same place:

1. Top-down. Start from the final deliverable and keep asking "what are the major parts of this?" Decompose each part the same way. This is the most rigorous route and the easiest to keep aligned with the 100% rule.
2. Mind-map. Put the goal in the centre and branch outward. The visual, radial shape suits people who think better in pictures, and it loosens up a stuck team faster than a formal outline.
3. Sticky notes. One deliverable per note, then cluster them on a wall or a virtual board and pull the clusters into a hierarchy. Brilliant for a group, because everyone adds notes at once and you surface forgotten work through sheer volume.

Whichever you use, do it as a noun exercise, not a verb one. Write "Edited module 1", not "Edit module 1". The grammar is a discipline: nouns force you to name outputs, verbs tempt you back into listing activities. You convert to verbs in the very next step.

A worked example

Here is a small deliverable-based WBS for launching an online course, three levels deep:

• 1. Course content
  • 1.1 Module 1 (script, recording, edited video)
  • 1.2 Module 2 (script, recording, edited video)
  • 1.3 Module 3 (script, recording, edited video)
  • 1.4 Module 4 (script, recording, edited video)
• 2. Sales assets
  • 2.1 Sales page copy and layout
  • 2.2 Email welcome sequence
• 3. Platform setup
  • 3.1 Course uploaded and structured
  • 3.2 Payment and enrolment configured
• 4. Launch
  • 4.1 Announcement published
  • 4.2 First-week enrolment monitored

Notice every leaf is a thing you could hold up and say "done" or "not done", and that the four top branches together cover the entire project with no gaps and no overlap. That's a WBS that will survive contact with reality.

From WBS to task list to Gantt chart

The WBS is the foundation, not the finished plan. To turn it into something you can run, take the lowest-level items — the work packages — and restate each as a task with a verb: "Edited module 1" becomes "Edit module 1". That list of tasks is what you then sequence, estimate, and lay out on a timeline. Our guide on how to make a Gantt chart picks up exactly there, and estimating durations is far easier once each task is a properly-sized work package rather than a vague lump. The WBS feeds straight into both — which is why doing it first, even roughly, repays the time many times over. If you want the bigger picture of where this step sits, see the end-to-end project planning framework.

Common mistakes

• Listing activities instead of deliverables. The original sin. "Call plumber, buy tiles" is a verb list; it has no structure and forgets things. Decompose outputs first, derive activities second.
• Going too deep — or too shallow. A WBS with work packages of two hours buries you in admin; one with packages of two months hides risk. The 8/80 and reporting-period rules exist to keep you in the band where the breakdown is useful.
• Overlap between branches. When two branches both lay claim to a piece of work, ownership blurs and estimates double-count. The 100% rule catches this if you actually apply it box by box.
• Confusing it with a schedule. A WBS has no dates and no dependencies. The instant you start drawing arrows, you've left the WBS and started building the plan — which is fine, as long as you finished the breakdown first.

Frequently asked questions

Is a work breakdown structure the same as a task list?

No. A WBS is a hierarchy of deliverables — the things the project produces — with no dates or order. A task list is the flat set of activities you derive from it. The WBS comes first and is more stable; the task list is what you actually schedule.

How many levels should a WBS have?

However many it takes to reach work packages of roughly one day to two weeks of effort — usually three or four levels for a small-to-medium project. The number of levels is a result of decomposing properly, not a target you set in advance.

Deliverable-based or phase-based — which should I use?

Deliverable-based is the safer default because it is harder to forget a deliverable than a phase. Phase-based reads more naturally if your project is genuinely staged and maps cleanly onto a timeline. You can mix them: deliverables at the top, phases as sub-branches where they clarify things.

Do small projects really need a WBS?

They need the thinking, even if the artefact is just a quick indented list. Decomposing by deliverable for ten minutes catches forgotten work that would otherwise surface mid-project. The formality scales down; the habit of breaking down outputs before listing actions does not.