work breakdown structure
Also called: WBS, work breakdown
A tree that splits a project's result into deliverables and then into pieces of work small enough to estimate and give to one owner. It is built from what must be handed over, not from a list of activities.
A work breakdown structure (WBS) is a tree that splits a project's result into deliverables, things someone can check and accept, and then into pieces of work small enough for one person to own and estimate. It is built top-down from what must be handed over, not by merging everyone's task lists, which produces a long list with holes and duplicates.
The tree follows the 100% rule: it contains all the work of the project, and each piece appears exactly once. "All" includes the work people forget: project management itself (plan, status, risks) and launch communications. "Once" means the same practice tasks are not listed both inside a lesson and under a separate practice branch, where one effort gets counted twice or each author assumes the other writes it.
Stop splitting at pieces of roughly up to two weeks of effort that one person owns. Below that, the owner keeps the task list on their own board; the project lead tracks the pieces, not every call and message. The upper levels are nouns (deliverables); verbs live on the owners' boards.
Then flatten the tree into a list: one line per piece with the deliverable, one owner, an effort range in person-days and what it needs first. That list feeds the rest of planning: acceptance criteria per line, must/should/could cuts against capacity, and the schedule. What is not in the tree is not in the project; the brief's out list says so explicitly.
Example
The WBS of Klasna's physics launch, first two levels (late October 2026):
- Curriculum: five units (mechanics; molecular physics and heat; electricity and magnetism; waves and optics; atomic and nuclear physics), then the final review.
- Practice: practice sets for units 1–3 and 4–5 (diagrams, a mock exam and video solutions were proposed too).
- Tutor pool: sourcing and screening (Roman), demo lessons and vetting (Vira), onboarding (Roman): three owners, three lines.
- Diagnostic test: question bank (Vira), the test on the platform (Danylo).
- Web: landing page, waiting list, booking by subject.
- Launch: launch email, January ads.
- Project management: plan, weekly status, risks.
Flattened, the tree gives 25 lines. A few of them:
All 25 lines add up to 197 likely person-days against the 150 the team can give before 29 January. The list makes the gap visible in October, and the next step is cutting by priority: the 17 real musts take 131 likely days (range 94 to 193), leaving 19 days of room.
Common mistakes
- Merging task lists instead of starting from deliverables. You get sixty lines with holes and duplicates.
- Forgetting whole branches. Project management and launch communications are work with real effort; leave them out and those days come from nowhere.
- The same work in two places. It gets counted twice, or each owner thinks the other one does it.
- Going down to hour-long tasks. Stop at pieces one person owns and can estimate in days; the owner keeps the rest.
- Two owners on one line. Split it; a line with two owners has none.
Learn it in the course
- Break the work down from deliverables · Deliverables first, tasks second: a tree that covers all the work of the physics launch and nothing twice, flattened into a list with owners and effort ranges.