The work breakdown structure is a hierarchical decomposition of the total scope of a project into the deliverables that make it up. Each level is a finer division of the level above it, and the bottom level is small enough to estimate, assign and control.
The word carrying most of the weight is deliverable. A structure built from verbs is a different artefact with different properties, and that substitution is the most common way the technique goes wrong.
Every box is a noun, the code carries the position in the hierarchy, and the marked boxes are where estimating and control actually happen. Project management is a branch of its own because it is real work that has to be estimated and funded like any other.
Deliverables, not activities
Decomposing by deliverable produces nouns, meaning things that will exist when the project finishes. Decomposing by activity produces verbs, meaning things people will do. Both look like a tree, which is why the distinction is so easy to lose.
It matters because a list of activities cannot be checked for completeness. If the branch under a website reads design, build and test, nothing in the structure reveals that the search function was forgotten. If it reads catalogue pages, checkout and search, an absence shows up as a missing box.
It matters again for stability. Deliverables survive changes of method, so deciding to build the checkout a different way does not force the tree to be redrawn, whereas a structure made of activities has to be rebuilt every time the approach changes.
The activities are still needed. They are derived from the bottom level during schedule planning, which is a later step with an output of its own.
The hundred per cent rule
The structure captures all of the work, and only the work, required to deliver the project. Every level rolls up into the level above, so the children of a node account for the whole of the parent and for nothing outside it.
Two failures follow from breaking it. Work that appears nowhere will not be estimated, scheduled, resourced or tracked, which is how project management effort and integration work end up unplanned and unfunded. Work that appears in two branches gets counted twice in the estimate and then argued over, because each owner assumes the other is doing it.
Project management effort deserves naming for exactly that reason. It is real work, it consumes real time, and it belongs in the structure rather than being absorbed silently by whoever has capacity.
The rule says nothing about depth. Children have to account for their parent, and a branch that is well understood may reach a package at level two while a branch full of unknowns runs to level five. Forcing every branch to the same depth invents boxes in the settled areas and starves the uncertain ones.
Work packages and the dictionary
The work package is the lowest level of the structure, being the point at which cost and duration can be estimated with confidence and a single owner can be named. No rule fixes how many levels deep that sits, and different branches reach it at different depths depending on how much is known about them.
How far to decompose is a judgement about control. Too coarse and a package conceals its own progress, so it reports eighty per cent complete for a month. Too fine and the tracking effort exceeds the value of the information, which produces a structure nobody maintains past the second week.
The dictionary carries what the boxes cannot. A single entry for one package in the tree above shows how much sits behind a label.
| Dictionary field | Entry for package 1.2.2 |
|---|---|
| Code and name | 1.2.2 Payment integration |
| Description of work | Connect the checkout to the payment provider, covering authorisation, capture, refund and the reconciliation feed |
| Responsible owner | Payments team lead, named individually |
| Assumptions | The provider sandbox is available from week two, and the existing merchant account is reused |
| Constraints | Card data stays outside the estate, so no cardholder record is stored by this project |
| Acceptance criteria | A live transaction authorises, captures, refunds and reconciles against the daily settlement file |
| Resources and estimate | Two engineers, eighteen days of effort, provider fees excluded |
| Schedule milestone | Sandbox transaction by the end of March, live transaction by the end of April |
Read that against the box marked 1.2.2 and the difference is obvious. Without the dictionary the label reads as one thing to the engineer, another to the finance stakeholder and a third to the auditor, and each of them is estimating against their own reading.
The three things it gets mistaken for
The first is an organisation chart. Grouping is by deliverable rather than by department, and a structure with one branch per team has quietly encoded a reporting line where a product should be, which is why it stops matching reality at the next reorganisation.
The second is a schedule. The structure carries no sequence, no dependency and no date, because all of that belongs to the schedule that is built from it afterwards.
The third is a task list for individuals. The lowest level is a package of work with an owner, and any further decomposition into personal tasks happens outside the structure and is managed by whoever owns the package.
What it holds up
Almost everything downstream. Bottom up estimates are produced by estimating packages and rolling them upward. Activities are defined by decomposing packages, which is where the schedule begins. Control accounts and the performance measurement baseline attach to nodes in the structure, and that is what makes earned value arithmetic possible at all.
Risk identification benefits too, since walking the structure branch by branch surfaces risks that a discussion about the project as a whole would skim past. Responsibility assignment maps roles onto the same nodes, so the question of who owns a deliverable has one answer rather than several.