"Let's redo the website" is not a project you can plan. It is a wish. Before it becomes a schedule, a budget and accountability, it has to be broken into pieces — pieces small enough that someone can estimate them and finish them. That is exactly what a work breakdown structure (WBS) does.
What is a work breakdown structure?
A WBS is a hierarchical decomposition of all the work in a project: top down, large to small. At the top sits the project itself, below it the main deliverables or phases, then their components, and finally work packages — units small enough to assign to one person, estimate in hours and attach a cost to.
One detail matters more than any other: a WBS describes deliverables, not activities. Not "development", but "working registration form". That difference sounds cosmetic, yet it changes everything — a deliverable can be reviewed and accepted, an activity can only be performed.
Why bother with a WBS?
- Nothing falls through the cracks. Once every deliverable is written down, it becomes obvious that someone also has to migrate the data from the old system.
- Estimates get more accurate. A big chunk is always estimated optimistically. Ten small chunks are estimated far more realistically.
- Accountability becomes concrete. Every work package has an owner — not "the dev team", but a named person.
- Schedule and budget get a foundation. Without a WBS, a Gantt chart and a budget are opinions. With one, they are arithmetic.
How to build a WBS
- Fix the end result. What has to exist at the end for anyone to be able to say "done"?
- Split it into 3–7 main parts. By phase, by deliverable or by domain — pick one logic, not all three at once.
- Keep decomposing until you reach a work package that can be handed to someone and whose completion can be judged objectively.
- Check the coverage. Do the children add up to exactly the parent — no more, no less?
- Give every work package an owner, an estimate and a definition of done. Only then is the WBS a tool rather than a drawing.
Example: three levels
| Level 1 | Level 2 | Level 3 (work package) |
|---|---|---|
| New website | Content | Service page copy written and approved |
| New website | Content | Photography shot and edited |
| New website | Build | Design implemented, mobile view tested |
| New website | Launch | Data migrated, redirects in place |
Two rules that keep a WBS honest
The 100% rule. The children of any node must add up to exactly the content of that node. If something is missing from the WBS, it is not in scope — and if it gets done later, that is a scope change, not "a small extra".
The 8/80 rule. A good work package is roughly 8–80 hours of work. Smaller turns the plan into micromanagement; larger hides risk. If one package takes two months, you will not know a month in whether it is on track.
From WBS to schedule and budget
A WBS contains no dates and no sequence — it is the list of what has to be done. Only the next step adds when and how much:
| Step | What is added | Result |
|---|---|---|
| WBS | Deliverables and work packages | Scope is fixed |
| Schedule | Durations, dependencies, milestones | Gantt chart |
| Budget | Labour, purchases, other costs | Cost budget |
| Risks | Probability, impact, mitigation | Risk register |
This is why the WBS is the first substantive step in planning. Done well, the rest almost follows by itself. Skipped, you build the schedule and the budget on guesses.
Common mistakes
- An org chart pretending to be a WBS. A WBS is structured by results, not by departments.
- A tree that is too deep. Five or six levels usually means someone started listing tasks instead of decomposing deliverables.
- Forgetting project management itself. Meetings, reporting and quality control are work too — they need their own package and their own hours.
- Building the WBS once and never touching it. A scope change always means a WBS change; otherwise it never reaches the schedule or the budget.
How Projektiassistent helps
Staring at a blank page is where most WBS attempts stall. Projektiassistent drafts the first structure from your project description — phases, deliverables and work packages with initial estimates — so you refine rather than start from zero. From there the same structure flows into the schedule, the budget and the risk register without copying data between spreadsheets. See project plan generator.
Summary
A work breakdown structure is the cheapest way to reduce project risk: it makes all the work visible before anyone has worked an hour. Break the project down by deliverables, keep work packages in the 8–80 hour range, check the 100% rule and give every package an owner.
If you want that structure in minutes and flowing straight into a schedule and a budget, start here: projekt2.projektiassistent.ee.