A work breakdown structure is straightforward to explain and easy to get wrong. The failure is almost always the same: teams decompose by activity or by team instead of by deliverable, and end up with an org chart or a task list wearing a WBS costume.
Step 1 — Write the objective at level 1
The root of the tree is the project outcome, phrased as a result rather than an activity. "New customer portal in production" rather than "portal project".
If you cannot phrase the root as something that will exist at the end, the project is not ready to decompose. Go back to framing.
Step 2 — Identify the major deliverables at level 2
Ask what has to exist for the objective to be met. Not what has to be done — what has to exist. The distinction produces very different trees.
Aim for five to nine items at level 2. Fewer usually means the decomposition is too coarse to check; many more usually means activities have crept in.
Decompose by deliverable, not by phase
A phase-based level 2 ("analysis, design, build, test") reads naturally and hides gaps: a missing deliverable does not stand out when everything is filed under "build". A deliverable-based level 2 makes omissions obvious, because a missing item has no home.
You can always map phases onto a deliverable-based WBS afterwards. The reverse does not work.
Step 3 — Decompose until you reach work packages
Continue breaking down each branch. Stop when a component satisfies three conditions:
- it can be estimated with reasonable confidence
- it can be assigned to a single owner
- its completion can be verified — someone can say yes or no
Most projects reach this at level 3 or 4. Going deeper adds tracking overhead without adding clarity: if you are decomposing to half-day activities, you have left the WBS and started writing a to-do list.
Step 4 — Apply the 100% rule, node by node
This is the validation step, and it is the one teams skip.
Take each parent node and ask: do its children represent exactly 100% of it? Not roughly. Exactly.
- Missing children mean scope that is not funded, not scheduled and not owned. It will appear during execution as "new" work.
- Overlapping children mean double estimates and disputed ownership.
Run this check bottom-up as well as top-down. The gaps that matter are usually the boring ones: environments, data migration, integration, documentation, handover.
Step 5 — Write the dictionary
For each work package, record what it includes, what it excludes, the definition of done, the owner, and what it depends on.
The exclusions are the part that pays for itself. They are what turn the WBS from a diagram into a scope agreement you can point at when someone says "I assumed that was in there".
Step 6 — Hand it to the dependency model
A WBS tells you what must be produced. It says nothing about order. That is the job of a dependency network, which takes the work packages as its input.
Only once both exist does a schedule become a calculation rather than a guess — and the critical path becomes something you can read off the structure instead of estimating by intuition.
The three most common mistakes
- Decomposing by team. Produces an org chart. Work that falls between teams disappears.
- Mixing deliverables and activities at the same level. Makes the 100% check impossible to apply.
- Building it alone. A WBS built by one person records that person's assumptions. Its main value is that it forces disagreement into the open early — which requires the people who disagree to be in the room.
