Skip to content

Work Breakdown Structure (WBS)

At a glance

  • Purpose: Decompose all the project's scope into pieces small enough to estimate, assign, and track — with nothing missing and nothing extra.
  • Use it when: After the scope statement is agreed and before estimating and scheduling. It is the source of activities, the basis of the cost estimate, and the structure the traceability matrix maps onto.
  • Owner: The project manager with the team; the deliverable level is agreed with the sponsor.
  • Related: Module 05 · Lab 07

A WBS decomposes project scope into smaller, manageable pieces — ending at work packages that can be estimated, assigned, and tracked.

Copy the skeleton below and replace the bracketed text.

WBS skeleton

# Work Breakdown Structure — [Project name]

| | |
| --- | --- |
| **Date** | [YYYY-MM-DD] |
| **Owner** | [Who] |
| **Scope baseline version** | [0.1] |

## Decomposition

Use a hierarchical numbering scheme (1, 1.1, 1.1.1). Stop decomposing when a package can be
estimated and owned by one person or pair.

- **1. [Major deliverable]**
  - 1.1 [Sub-deliverable]
    - 1.1.1 [Work package] — [owner] — [estimate]
    - 1.1.2 [Work package] — [owner] — [estimate]
  - 1.2 [Sub-deliverable]
    - 1.2.1 [Work package] — [owner] — [estimate]
- **2. [Major deliverable]**
  - 2.1 [Sub-deliverable]
    - 2.1.1 [Work package] — [owner] — [estimate]

## Work package table

| ID | Work package | Description | Deliverable | Owner | Estimate |
| --- | --- | --- | --- | --- | --- |
| 1.1.1 | [Name] | [What it involves] | [Output] | [Who] | [e.g. 3 days] |

## Out of scope

| Excluded | Reason |
| --- | --- |
| [Item] | [Why] |

Visual form

A WBS is often shown as a tree. Mermaid renders it from text, so the diagram stays reviewable in the repository:

flowchart TD
    accTitle: A three-level work breakdown structure
    accDescr {
    The project contains Deliverable A and Deliverable B. Deliverable A contains sub-deliverable
    1.1, which contains work packages 1.1.1 and 1.1.2. Deliverable B contains sub-deliverable 2.1.
    }
    R[Project] --> A[1. Deliverable A]
    R --> B[2. Deliverable B]
    A --> A1[1.1 Sub-deliverable]
    A1 --> A11[1.1.1 Work package]
    A1 --> A12[1.1.2 Work package]
    B --> B1[2.1 Sub-deliverable]

How to use this template

  1. Start from the scope statement's in-scope list, so the WBS has a source. Anything not traceable to scope is either missing scope or gold plating.
  2. Decompose by deliverable to the top levels, then stop at work packages — pieces one person or pair can own, and that you can estimate in days rather than weeks.
  3. Apply the 100% rule: the children of a node must represent all of that node's work and nothing else. This is the only reliable check on completeness.
  4. Give every work package an owner and an estimate, or you have a contents page rather than a plan. Estimates here become the schedule's durations and the estimate's cost base.
  5. Build the WBS with the people who will do the work. A WBS constructed alone is usually wrong at exactly the level where it matters.
  6. Keep one WBS per project baselined; a second, differently structured WBS for reporting is how numbers stop reconciling.

Field descriptions

Field What goes in it Watch out for
ID Hierarchical numbering (1, 1.1, 1.1.1) Renumbering after baselining, which breaks every reference
Level Deliverable, sub-deliverable, work package Decomposition below work-package level
Work package A piece one person or pair can own Packages spanning a whole discipline
Description What the work involves A scope statement restated
Deliverable The output that closes the package "Coding complete" instead of an artefact
Owner A role or person Unassigned packages
Estimate Effort in person-days, with a basis Precision on things nobody has done before
Dependencies Other packages that must precede it Dependencies left for the schedule to reveal
Traceability The requirement or scope item it serves Packages with no source

Worked example

From Lab 07, on the admission portal — invented estimates for teaching. An extract, with a deliberate comparison:

ID Work package Deliverable Owner Estimate
3.1 Applicant submission form Working form on the test environment Frontend developer 6 pd
3.2 Document upload Upload with size and type validation Frontend developer 8 pd
3.3 Supporting document storage Documents retrievable by staff Backend developer 4 pd
4.1 Administrative review console List, filter, and open an application Frontend developer 5 pd
5.2 Performance verification at realistic volumes Test report at 1,200 records Tester 3 pd
Weak version Why it fails
"3. Development" with no further levels Cannot be estimated, owned, or tracked
"3.1 Coding of the form" Describes an activity rather than a deliverable, so completion cannot be recognised
"3.2 Upload everything" Too large to own; hides the storage work that another package needs

Note package 5.2: performance verification is a work package with an owner and an estimate, not an assumption that testing happens at the end. In Lab 25 the absence of exactly this package — realistic volumes, owned by someone — is one of the causes of the project's late recovery.

Common mistakes

  • Decomposing by activity or by team. "Coding", "testing", "the backend team" produce packages that cannot be completed or accepted, and they duplicate work across branches.
  • Breaking the 100% rule. Scope missing from the WBS is discovered later as unscheduled work; extra scope in it is gold plating.
  • Decomposing too far. Beyond work-package level the effort of maintaining the structure exceeds the control it provides.
  • Not decomposing far enough. A package of 40 days cannot be estimated reliably, owned by one person, or tracked.
  • No owners. Unassigned packages are the ones that slip.
  • A WBS built alone. Teams routinely reveal missing packages in the first ten minutes of a joint session.
  • Rebuilding the WBS to match a slipped plan. The structure should reflect scope; if it has to change to reflect reality, that is usually a scope change and belongs in a change request.