Work breakdown structure for beginners: how to split a project into tasks
A work breakdown structure turns a vague project into tasks you can schedule. Here's how to build one, how small tasks should be, and the usual mistakes.
“Launch the new website” isn’t a task. It’s a project, and nobody can schedule it, assign it or say whether it’s on track. The first job in any plan is to break it into pieces small enough to manage. A work breakdown structure, or WBS, is the result.
What it is
A WBS is a hierarchy. The project sits at the top, broken into major deliverables, and each of those is broken into smaller ones, down to tasks someone can actually do.
For the website, the top level might be Content, Design, Build and Launch. Under Build you might have Set up hosting, Build page templates, Connect the contact form and Test on mobile. The top-level items are summary tasks, and their dates come from the tasks beneath them.
Break down by deliverable, not by time
The common mistake is to list things in the order they’ll happen: week one, week two, week three. That’s a timeline, and it falls apart the moment the order changes.
Break down by what gets produced instead. Ask “what are the parts of this thing?” at each level. The sequence comes later, when you add dependencies between tasks.
How small should tasks be
A useful rule of thumb is that a task should take somewhere between a day and a couple of weeks, depending on the project. Smaller than a day and you’re managing minutes. Bigger than a couple of weeks and you can’t tell whether it’s on track until it’s over.
Another check is ownership. If you can’t name one person responsible for a task, it’s probably two tasks.
A third check is whether you can tell when it’s done. “Work on the logo” never finishes. “Deliver three logo options” does.
Mistakes to avoid
- Missing work. The 100% rule helps: the tasks under a summary item should add up to everything needed for it, and nothing outside it. If a piece of work isn’t in the WBS, it won’t be in the schedule either.
- Going too deep. Breaking a two-day task into twelve ten-minute tasks makes the plan harder to read and update without making it more accurate.
- Mixing levels. “Build” sitting next to “Fix typo on contact page” at the same level suggests the structure is off.
- Skipping the boring tasks. Reviews, approvals, testing and handover take real time and are the ones usually forgotten.
From structure to schedule
The WBS only tells you what the work is. Dates come when you give each task a duration and link tasks with dependencies. At that point the critical path shows up.
GanttPM keeps the hierarchy as you build, with summary tasks rolling up from their children, and it brings the WBS in intact when you import a Microsoft Project file. If you’re starting from a blank page, download GanttPM and write the top level first. Then split each item until every piece has one owner and a clear end.