A work breakdown structure, or WBS, decomposes a project into progressively smaller pieces of deliverable work, so that each piece can be estimated, assigned, scheduled and reported against.
Deliverables, not activities
The common mistake is to build a WBS out of activities — "design", "review", "coordinate" — rather than deliverables. Activities have no definition of done, so a task list built from them can be eighty per cent complete for a month. A deliverable either exists or it does not.
The hundred per cent rule
A WBS should account for all of the work and none of the work twice. If the children of a node do not add up to the parent, something is unowned; if they overlap, two people will each assume the other is doing it. Most schedule surprises trace back to one of those two.
How far to break it down
A useful rule is to stop when a package is small enough to estimate with confidence and to assign to one owner. Breaking further produces administration rather than control — a plan with a thousand tasks is not more accurate, it is more expensive to maintain, and a plan nobody maintains is worse than a coarse one that is current.
What it enables
- Estimates that can be rolled up rather than guessed at the top.
- Clear ownership per package.
- Progress measured against completion of definite things.
- Change control, because a change is visible as work added or removed.
