A work breakdown structure splits a project into deliverables small enough to estimate and assign. Its real function is finding the work nobody remembered until it was late.
A work breakdown structure — usually shortened to WBS — takes a whole project and splits it into progressively smaller pieces until each piece is something one person or team can estimate, own and finish. It is a decomposition of the deliverables, not a schedule and not a task list, and the difference matters: the WBS says what has to exist, and the plan built from it says when and by whom.
The value is not in the tidy diagram. It is that decomposing forces you to name every part of the result, and the parts nobody names are exactly the ones that surface in the last week — the data migration, the training, the sign-off nobody scheduled.
The rule that does most of the work is the hundred percent rule: everything below an item must add up to all of it. Applied honestly, it is what exposes the missing branch — you list the four things that make up a deliverable, look at them, and realise they do not actually amount to the whole thing.
The most common mistake is building the WBS out of verbs. Design the interface, build the interface, test the interface — that is a plan sequence, and it hides scope because activities can always be added later without anyone noticing the total grew. Nouns behave better: the interface, the migrated data, the trained users, the signed acceptance. Each is either done or not, and it is much harder to quietly forget one.
This is also what separates a work breakdown structure from a product breakdown structure, which lists only the physical or functional components of the thing being built. The WBS includes project work that produces no component at all — training, project management itself, the review meetings — which is precisely the work most often left out of estimates.
A WBS built and then filed is half wasted. Kept, it becomes the frame for everything else: estimates roll up through it, progress reports against it, the risk register points at branches of it, and change requests are expressed as additions to it. That last use is the strongest defence against scope creep — when a new request has to be placed somewhere in the structure, its cost becomes visible instead of being absorbed.
For small projects the whole thing is often twenty to forty leaves and fits on one page. The formality of numbered levels and dictionaries belongs to large programmes; the decomposition habit is worth having at any size.
Ettex Board is where the leaves become real: each lowest-level deliverable is a card with an owner and a due date, grouped by the branch it came from, so the structure survives into execution rather than living in a separate document that goes stale after week two.
It does not draw the tree. There is no hierarchical WBS view, no automatic numbering, no roll-up of estimates from children to parents, and no critical-path or Gantt calculation — cards are grouped in lists, which represents two levels comfortably and four badly. Decompose on paper or in a document, then bring the leaves in.
A hierarchical decomposition of a project into progressively smaller deliverables, until each is small enough to estimate and assign to one owner.
No. It says what has to exist; the schedule built from it says when and by whom.
Everything below an item must add up to exactly that item — no missing work and nothing extra. It is what exposes forgotten branches.
Nouns — deliverables rather than activities. Activity lists let scope grow unnoticed; deliverables are either complete or not.
Small enough to estimate within about a quarter and to show visible progress inside one reporting period.
A product breakdown lists only the components of the thing being built. A WBS also includes project work such as training, testing and management.
Decompose into deliverables rather than activities, apply the hundred percent rule at every level, stop when you can estimate confidently — and keep the structure afterwards, because it is what makes new requests cost something visible.
A SWOT ends with four lists. A TOWS matrix pairs them — strength with opportunity, weakness with threat — and each pair produces a candidate action. That pairing step is the part almost every workshop skips.
Most go-to-market documents are positioning statements with a launch date stapled on. The version that works names one buyer, one problem, one channel to test first, and the number that decides whether to keep going.
The balanced scorecard measures a business from four angles rather than one. Its enduring value is the argument it forces about what actually drives the financial result.