WBS (Work Breakdown Structure)
Name variants
- English
- WBS (Work Breakdown Structure)
- Kanji
- 作業分解構成図
Quality / Updated / COI
- Quality
- Reviewed
- Updated
- Source
- Citations & Trust
- COI
- none
TL;DR
A WBS is a hierarchical breakdown of project deliverables into manageable work packages.
Definition
The work breakdown structure decomposes a project scope into smaller, deliverable-based components. It is not a schedule, but a scope map that clarifies what must be produced and who will own each part. A good WBS provides the foundation for estimating effort, assigning responsibility, and controlling scope changes.
Decision impact
- It defines what is in scope by listing deliverables and work packages.
- It improves estimation accuracy by breaking work into measurable pieces.
- It supports assignment and accountability across teams and vendors.
Key takeaways
- Build the WBS around deliverables, not activities or departments.
- Use consistent decomposition levels so estimates are comparable.
- Link each work package to an owner and acceptance criteria.
- Use the WBS to evaluate change requests objectively.
- Keep the WBS updated as scope is refined.
Misconceptions
- A WBS is not the schedule; it is the scope structure.
- A WBS is not an org chart and should not mirror reporting lines.
- Listing tasks without deliverables reduces its value for control.
Worked example
A website redesign project creates a WBS with deliverables such as information architecture, visual design, content migration, and QA. Each deliverable is broken into work packages with clear acceptance criteria. Estimates are produced at the package level and rolled up to a total budget. When a stakeholder requests a new microsite, the team evaluates where it fits in the WBS and updates scope before approving.
Citations & Trust
- Project Management (Open Textbook Library)