The Work Breakdown Structure (WBS) is a hierarchical decomposition of the total scope of work to be carried out by the project team. It breaks the project down into smaller, manageable components called work packages — the lowest level of the WBS, where work can be estimated, scheduled, and assigned.
Think of it as a family tree for your project's deliverables. You start with the entire project at the top and progressively break it down until each piece is small enough to plan and control.
WBS Example
Here's a simplified WBS for a website redesign project:
1.2 Competitor analysis
1.3 Content audit
2.2 Visual design
2.3 Prototype
3.2 CMS integration
3.3 Testing & QA
Key Concepts
1. The 100% Rule
The WBS must capture 100% of the project scope. Every deliverable defined in the scope statement must appear somewhere in the WBS. Conversely, nothing should appear in the WBS that isn't in scope. If it's not in the WBS, it doesn't get done. If it's not in scope, it shouldn't be in the WBS.
2. Work Packages
The lowest level of the WBS is the work package. This is where actual estimation happens. A good work package is:
- Small enough to estimate duration and cost accurately (typically 8–80 hours of effort)
- Assignable to a single person or team
- Produces a measurable deliverable or outcome
- Has clearly defined start and completion criteria
3. Deliverable-Oriented, Not Activity-Oriented
A critical distinction: the WBS describes what will be delivered, not how the work will be done. "User research report" is a deliverable; "conduct interviews" is an activity. Activities are defined later when creating the schedule. This keeps the WBS focused on outcomes.
4. WBS Dictionary
Each element in the WBS is described in detail in the WBS Dictionary — a companion document that provides:
- WBS ID number (e.g., 2.1.3)
- Description of the work package
- Responsible person or team
- Estimated effort and cost
- Acceptance criteria
- Dependencies and constraints
Decomposition Approaches
Start with the project, then break it into major deliverables, then sub-deliverables, and so on until you reach work packages.
Best for: Experienced PMs who understand the full scope. Most common approach.
Start by brainstorming all the individual tasks and deliverables, then group them into logical categories and build up to the project level.
Best for: New domains, complex projects, or when the team has more expertise than the PM.
Levels of Decomposition
| Level | Name | Example |
|---|---|---|
| Level 0 | Project | Website Redesign Project |
| Level 1 | Major Deliverables / Phases | Discovery, Design, Development, Launch |
| Level 2 | Sub-Deliverables | Wireframes, Visual Design, Prototype |
| Level 3 | Work Packages | Homepage wireframe, Product page wireframe |
There's no fixed rule for how many levels a WBS should have. Small projects might have 2–3 levels; large, complex projects might have 5 or more. Stop decomposing when work packages are small enough to estimate and assign with confidence.
Common Mistakes
- Listing activities instead of deliverables: "Hold kickoff meeting" is an activity. "Kickoff meeting minutes and action items" is a deliverable.
- Decomposing too deep or too shallow: Too deep creates micromanagement and overhead. Too shallow makes estimation unreliable.
- Violating the 100% rule: Missing deliverables means missing scope — which means missing budget and schedule.
- Not involving the team: The PM should lead the WBS creation, but the team doing the work should contribute. They understand the details better.
- Treating it as a one-time exercise: The WBS can be updated through change control as scope evolves, especially in hybrid approaches.