Work Breakdown Structure (WBS): Examples and How-To

What is a work breakdown structure (WBS)?

A work breakdown structure (WBS) is a hierarchical, deliverable-oriented breakdown of a project's total scope into progressively smaller pieces. The top level is the whole project; each level below divides its parent into components, down to work packages that can be estimated, assigned and tracked. A WBS shows *what* will be delivered, not when or how.

PMI's PMBOK Guide defines the WBS as a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. In PMI's framework, the approved scope statement, the WBS and the WBS dictionary together form the scope baseline, which is the reference point for measuring and controlling scope.

The technique has its roots in large US defence and space programmes, and the US Department of Defense still maintains a WBS standard (MIL-STD-881). PMI also publishes a dedicated *Practice Standard for Work Breakdown Structures*. You do not need a defence-sized project to benefit, though: a simple three-level WBS on a whiteboard is often enough for a small team.

A WBS is usually drawn as a tree diagram (like an organisation chart) or written as an indented, numbered outline or table. Both show the same thing: the whole project broken into parts that add up exactly to the whole.

Why a WBS matters

A WBS takes a few hours to build and pays for itself throughout the project. It helps you:

• See the complete scope. Breaking work down exposes deliverables that would otherwise be forgotten, such as training, data migration or documentation.
• Estimate more accurately. Small, well-defined work packages are far easier to estimate than a whole project. See our guide to cost estimation.
• Assign clear ownership. Every work package has one owner, which makes accountability visible. A RACI matrix can map roles to WBS elements.
• Build the schedule and budget. Activities, durations and costs are planned per work package and roll up through the WBS.
• Control scope. Work that does not fit anywhere in the WBS is a signal of scope creep.
• Identify risks. Walking through each element is a structured way to ask "what could go wrong here?"
• Communicate. A one-page WBS diagram gives sponsors and teams a shared picture of what the project includes.

The WBS is a central part of the project management plan: the schedule, cost baseline and resource plan are all organised around it.

Key rules for a good WBS

The 100% rule

The 100% rule is the most important principle. The WBS includes 100% of the work defined by the project scope, including project management work, and nothing outside it. It applies at every level: the children of any element must add up to exactly 100% of that element's work, no more and no less. If a child element contains work that is not part of its parent, it is out of scope; if the children do not cover all of the parent, something is missing.

Deliverables, not activities

Name WBS elements as nouns that describe outcomes ("Payment integration", "User guide", "Venue") rather than verbs that describe actions ("Integrate payments", "Write guide", "Book venue"). Deliverable-oriented elements make it easier to check completeness and define acceptance criteria. The activities needed to produce each work package are listed later, in the schedule.

Mutually exclusive elements

No piece of work should appear in two places. Overlap leads to double-counted estimates, confused ownership and arguments about who is doing what.

Decompose to the right level

Stop decomposing when a work package is small enough to estimate reliably, assign to one owner and track, but not so small that managing it takes more effort than doing it. Common rules of thumb (not formal standards) include:

• The 8/80 rule: a work package should take roughly between 8 and 80 hours of effort.
• The reporting period rule: a work package should not span more than one or two reporting periods, so progress is visible.
• The "if it makes sense" rule: decompose further only if it improves estimating, assignment or control.

Most projects need three or four levels. Large programmes may need more, and small projects may need only two.

One owner per work package

Every work package should have a single accountable owner, even if several people contribute. Shared ownership usually means no ownership.

WBS levels and components

WBS levels are numbered from the top. The exact labels vary between organisations, but a typical structure looks like this:

Activities and tasks sit below work packages, but they belong in the project schedule rather than in the WBS itself. Our guide to project tasks and activities explains the difference.

Other components you will come across:

• WBS codes: a numbering scheme (1, 1.1, 1.1.1) that gives every element a unique identifier and shows where it sits in the hierarchy. Codes link the WBS to the schedule, budget and timesheets.
• Work packages: the lowest level of the WBS, where effort, cost and duration are estimated and work is assigned. See our work package guide.
• Control accounts: management points above work packages where scope, budget and actual cost are compared, often used with earned value management.
• Planning packages: placeholders for work that is known to be in scope but not yet detailed enough to break into work packages.
• WBS dictionary: the companion document that describes each element in detail (covered below).

Work packages are where the plan becomes real work.

Types of work breakdown structure

The main choice is how to organise level 2. The two most common approaches are deliverable-based and phase-based.

Many teams use a hybrid: phases at level 2 and deliverables at level 3. Whichever you choose, apply it consistently at each level. Other organising options include by location (sites or buildings), by subsystem (engineering) or by organisational unit, although organising by department tends to break the deliverable focus.

You can present the same WBS in several formats:

• Tree diagram: best for communicating the top three levels to sponsors and teams.
• Outline: an indented, numbered list; quick to create and edit.
• Table or spreadsheet: one row per element with code, owner, effort and cost; ideal for detail and roll-ups.
• In a scheduling tool: the WBS becomes the summary-task structure of a Gantt chart.

Work breakdown structure examples

These examples show the same principles applied to different types of project. Use them as a starting point and adapt the elements to your own scope.

Example 1: customer portal (deliverable-based)

This mirrors the example in our free WBS template, where effort and cost entered for each element roll up to the project total.

Example 2: the same project, phase-based

The phase-based version is easier for stage-gate reviews, but notice that the main deliverables are hidden inside "Execution". You would need a further level to make them visible.

Example 3: office relocation

Note the easily forgotten deliverable at 1.6. Exiting the old premises is real work with real cost, and a WBS makes it visible early.

Example 4: conference

How to create a work breakdown structure

Follow these steps to build a WBS for any project. For a small project you can do this in a single workshop; larger projects may need several sessions.

1. Start from the approved scope. Gather the project charter, scope statement, requirements and any contract or statement of work. You cannot break down scope that has not been defined.
2. Define level 1. Write the project's final deliverable or name at the top.
3. Choose how to organise level 2. Decide between major deliverables and phases (see above), and include a project management branch.
4. Decompose each element. Break each level 2 element into its component deliverables. Ask "what does this consist of?" rather than "what do we need to do?"
5. Stop at work packages. Continue until each lowest-level element can be estimated, assigned to one owner and tracked within a reporting period.
6. Apply the 100% rule. For each parent, check that its children cover all its work and nothing more. Look for gaps and overlaps.
7. Number the elements. Give every element a unique WBS code so it can be referenced in the schedule, budget and reports.
8. Write the WBS dictionary. Describe each work package: scope, deliverables, acceptance criteria, owner, assumptions and estimates.
9. Review with the team and stakeholders. The people doing the work spot missing elements and unrealistic splits; stakeholders confirm nothing is out of scope.
10. Baseline and maintain it. Once approved, the WBS becomes part of the scope baseline. Update it only through change control.

The WBS dictionary

A WBS dictionary is the companion document to the WBS. The WBS shows the structure; the dictionary explains each element so that everyone understands exactly what is included. It is particularly useful for work packages, where it acts as a mini-brief for the owner.

A dictionary entry typically includes:

• WBS code and element name.
• Description of the work and what is included and excluded.
• Deliverables and acceptance criteria.
• Owner (responsible person or organisation).
• Effort, cost and duration estimates.
• Key milestones and dependencies.
• Assumptions, constraints and known risks.
• Resources, quality requirements and references.

Example dictionary entry

For larger work packages you can expand the entry into a full work package description using our work package template.

From WBS to schedule and budget

The WBS is not a schedule, but it is the input to one. Once the WBS is agreed:

1. List the activities needed to produce each work package.
2. Identify task dependencies between activities.
3. Estimate durations and effort; our effort estimation guide explains the main techniques.
4. Build the schedule, find the critical path and add milestones.
5. Estimate cost per work package and roll it up into the project budget.

It helps to be clear about which document answers which question:

Scheduling is the natural next step after the WBS.

Using a WBS in Agile projects

The Scrum Guide does not mention a WBS, and Agile teams usually work from an ordered Product Backlog instead. The underlying idea, breaking a large outcome into smaller pieces of value, is still very much part of Agile.

In our experience, a backlog hierarchy of themes, epics, features and user stories plays a similar role to a deliverable-based WBS, with two key differences: it is ordered by value rather than structured for completeness, and it is expected to change as the team learns.

A light, high-level WBS can still help Agile and hybrid projects:

• To agree the overall scope and budget with a sponsor before the first Sprint.
• To show non-software deliverables, such as training, data migration or procurement, that may not appear in a backlog.
• To support rolling-wave planning: near-term work is decomposed in detail while later work stays as planning packages.
• To integrate Agile teams into a wider programme that reports against a WBS.

Common WBS mistakes

WBS template and tools

Our free work breakdown structure template is available in Google Sheets, Excel and PDF. It includes columns for WBS code, level, deliverable or work package, description, owner, effort (days), cost and status, with effort and cost rolling up to the project total. Pair it with the project cost estimate template for detailed costing and the Gantt chart template to turn work packages into a schedule.

Most project management software can hold a WBS as nested tasks or summary tasks with automatic numbering, which keeps the WBS and the schedule in sync. Our guide to Gantt chart software and our project management software rankings compare the options.

Free templates for this topic

Browse all templates

Frequently asked questions