Project delivery
Work breakdown structure
A decimal coded hierarchy of deliverables with a level column so a flat sheet holds a tree, plus the description and acceptance criteria that make it a dictionary rather than a list of names.
What it is
A work breakdown structure is a hierarchy of deliverables covering the whole of an agreed scope. The hundred per cent rule is what gives it force. The children of any row add up to exactly that row, everything in scope appears somewhere, and anything not in the structure is not in the project.
Building one in a spreadsheet takes a decimal code and a level column, because a sheet is flat and a breakdown is a tree. Sort by code and the structure reads correctly, indent column A by level and the outline becomes visible.
The most common error is building it from activities. Configure the matching rules is an activity and produces a task list that duplicates the schedule. Matching rules configured and tested is a deliverable, and the test is whether the description column can be written without a verb.
When to use it
- The scope is agreed in principle and nobody has written down what that actually includes.
- Estimates keep coming in short because work nobody counted keeps appearing.
- Two teams are building overlapping things because the boundary was never drawn.
- You need something a sponsor can review that is not a schedule.
The columns
- Code
- Level
- Deliverable
- Work package
- Description of the finished thing
- Owner
- Estimate (days)
- Acceptance
- Depends on
The template
| Code | Level | Deliverable | Work package | Description of the finished thing | Owner | Estimate (days) | Acceptance | Depends on |
|---|---|---|---|---|---|---|---|---|
| 1 | 1 | Settlement rebuild | No | The whole project | Project manager | 620 | Charter objectives met | |
| 1.1 | 2 | Reconciliation engine | No | The component that matches instructions | Solution lead | 240 | ||
| 1.1.1 | 3 | Matching rules | Yes | Rule set covering all three regions, configured and unit tested | J. Okafor | 60 | All 42 documented rules pass their tests | 1.2.1 |
| 1.1.2 | 3 | Exception queue | Yes | Queue with filtering, assignment and audit trail, deployed to test | J. Okafor | 90 | Supervisor can find, assign and resolve a break end to end | 1.1.1 |
| 1.1.3 | 3 | Regional configuration | Yes | Three region packs loaded and verified against sample data | M. Reyes | 90 | Each region reconciles a day of live volume in the test environment | 1.1.1 |
| 1.2 | 2 | Data migration | No | Historical instructions moved and verified | M. Reyes | 130 | ||
| 1.2.1 | 3 | Source analysis | Yes | Documented field mapping for all three source systems | M. Reyes | 30 | Mapping reviewed and signed by each regional lead | |
| 1.2.2 | 3 | Trial migration | Yes | Full volume trial run in a copy environment with a reconciliation report | J. Okafor | 40 | Under 0.1 per cent unexplained variance on the full set | 1.2.1 |
| 1.2.3 | 3 | Production migration | Yes | Twenty four months of instructions in the live store, verified | J. Okafor | 60 | Row counts and control totals match source | 1.2.2, 1.1.3 |
| 1.3 | 2 | Compliance evidence | No | The pack the regulator will ask for | Regulatory affairs | 60 | ||
| 1.3.1 | 3 | Control mapping | Yes | Each control mapped to the design element that satisfies it | Regulatory affairs | 20 | Signed by regulatory affairs | 1.1.1 |
| 1.3.2 | 3 | Evidence pack | Yes | Review records assembled as the work proceeds | Regulatory affairs | 40 | Complete for every release made | 1.3.1 |
| 1.4 | 2 | Transition to operations | No | Everything needed for operations to run it | Change lead | 110 | ||
| 1.4.1 | 3 | Runbooks | Yes | Written procedures for the twelve routine operations tasks | Change lead | 40 | Operations run a full day from the runbook unaided | 1.1.2 |
| 1.4.2 | 3 | Training delivery | Yes | All 34 users trained and assessed | Change lead | 30 | Every user completes the assessment | 1.4.1 |
| 1.4.3 | 3 | Decommissioning | Yes | Two regional tools switched off and archived | Change lead | 40 | Access revoked, data archived, licences cancelled | 1.2.3, 1.4.2 |
| 1.5 | 2 | Project management | No | Managing the work | Project manager | 80 |
A spreadsheet is flat and a breakdown is a hierarchy, so the Code and Level columns carry the shape. Sort by Code and the structure reads correctly. Indent column A by level when you set the sheet up, and the outline becomes visible.
Deliverables, not activities
Every row names something that will exist when the work is finished. Matching rules configured and tested is a deliverable. Configure the matching rules is an activity, and a structure built from activities becomes a task list that duplicates the schedule.
The test is whether you can write the Description of the finished thing column. If the answer is a verb, the row is an activity and needs restating as the thing it produces.
The hundred per cent rule
The children of any row add up to exactly that row, no more and no less. Everything in scope appears somewhere, and anything not in the structure is not in the project.
Read it both ways. Missing work means the estimate is short and somebody will do it anyway, uncounted. Extra work means scope that nobody authorised has arrived, which is how a structure quietly becomes a wish list.
Row 1.5 is the row people forget. Project management is real effort and it belongs in the structure, otherwise it is either uncounted or smeared invisibly across the delivery packages.
Work packages are where it stops
The Work package column marks the lowest level, and those rows are the ones that get estimated, assigned and tracked. Everything above is a summary that rolls up.
Decompose until a package can be estimated with confidence, assigned to one owner, and tracked as done or not done. A useful check is that a package should be small enough that being wrong about it costs less than the effort of breaking it down further, which for most projects lands somewhere between one and four weeks of work.
The dictionary is the Description and Acceptance columns
A code and a name is not enough. Two people will read Exception queue differently, and the disagreement surfaces when somebody says it is finished.
The description says what will exist. The acceptance column says how anybody will know it is complete, written so it can be checked rather than argued about. Those two columns are what a work breakdown dictionary holds, and putting them on the same row keeps them with the thing they describe.
What it is not
It is not a schedule. There are no dates and no sequence beyond the dependency column, and turning it into one is how a structure stops being a scope agreement.
It is not an organisation chart. Grouping by team produces a structure that changes when the organisation does, and leaves the work described in terms of who does it rather than what it is.
It is not a backlog. A structure covers an agreed scope and obeys the hundred per cent rule. A backlog is deliberately incomplete at the bottom and changes without a change request. Hybrid projects often carry both, with one work package delivered from a backlog underneath it, and that works as long as everybody knows which artefact is the commitment.
Questions people ask
- Is this the same as a backlog?
- No. A structure covers an agreed scope and obeys the hundred per cent rule. A backlog is deliberately incomplete at the bottom and changes without a change request. Hybrid projects often carry both, with one work package delivered from a backlog underneath it.
- How far down should it go?
- Until a package can be estimated with confidence, assigned to one owner and tracked as done or not done. Being wrong about a package should cost less than the effort of decomposing it further, which usually lands between one and four weeks of work.
- Where does project management effort go?
- In the structure, as its own branch. It is real effort, and leaving it out means it is either uncounted or smeared invisibly across delivery packages.