Work breakdown structure for a project, step by step

A work breakdown structure, usually shortened to WBS, is the list of everything a project has to deliver, broken into pieces small enough to plan. It is the step that comes before a schedule: you cannot estimate, order or assign work you have not named yet. If your plans keep surprising you with forgotten tasks, a better work breakdown structure is usually the fix.

This guide shows how to build one in about an hour, using a concrete example, and how to carry it straight into a Gantt chart.

What a work breakdown structure is

A WBS is a hierarchy. At the top is the project goal. Below it are the main phases or deliverables. Below each of those are smaller pieces, and so on, until each piece is a task one person can finish and you can check is done.

Two things to notice:

• It describes what, not when. A WBS has no dates and no order. Sequence and durations come later.
• It is about deliverables and work, not people. You decide who does what after the structure exists.

A common rule of thumb is the 100% rule: the pieces under any item should add up to the whole of that item, with nothing missing and nothing extra. If "Launch" is made of three tasks, finishing those three tasks should mean the launch is done.

Why bother before opening a Gantt chart

It is tempting to start dropping bars on a timeline. The trouble is that a timeline rewards what is easy to place, not what is complete. A WBS forces you to look at the whole project first.

• You find forgotten work early. Legal review, data migration and "someone has to buy the domain" appear on paper before they appear as delays.
• Estimates get easier. A task called "Build website" cannot be estimated honestly. "Build the contact form" can. The estimating guide goes deeper on this.
• Scope stays visible. When someone asks for "one more thing", you can see where it would sit and what it pushes.

An example: relaunching a small website

Take a simple project: relaunching a five-page company website in two months. Start from the goal and ask, "What are the big chunks of work?"

Website relaunch
1. Discovery
   1.1 Interview stakeholders
   1.2 Audit current content
   1.3 Agree scope and sitemap
2. Design
   2.1 Wireframes
   2.2 Visual design
   2.3 Design sign-off
3. Build
   3.1 Set up hosting and domain
   3.2 Build page templates
   3.3 Write and load content
   3.4 Contact form and analytics
4. Launch
   4.1 Test on phone and desktop
   4.2 Fix issues
   4.3 Go live
   4.4 Redirect old URLs

Four phases, thirteen tasks. Nothing here has a date yet, and that is fine.

How to build one, step by step

1. Write the goal in one sentence

"Relaunch the company website with a new design and updated content by the end of the year." If you cannot write it, the project is not defined enough to break down.

2. List the main phases or deliverables

Aim for three to seven. You can organise them by phase (discovery, design, build, launch) or by deliverable (website, content, tracking). Pick whichever your team naturally talks in and stay consistent.

3. Break each one down until the pieces are plannable

Keep asking, "What would I need to do to finish this?" Stop when a piece meets these checks:

• one person could own it;
• you can describe what "done" looks like in a sentence;
• you can guess its duration within a reasonable range, say between half a day and two weeks.

Do not go deeper than that. A task called "Choose button colour" in a two-month plan only adds noise. Two or three levels are enough for most projects, as covered in the post on subtasks and task groups.

4. Check the 100% rule

Read each group from the bottom up. If every task under "Design" were finished, would design be finished? If not, something is missing. If a task could fit under two groups, it is probably two tasks.

5. Name tasks as actions

"Wireframes" is fine, "Draft wireframes for five pages" is better. Start with a verb where you can, so each line reads as work to do.

6. Ask someone else to review it

The person who will do the work almost always spots a gap in minutes: the approval round nobody counted, or the dependency on another team.

From WBS to a Gantt chart

Once the structure is right, the schedule is mostly mechanical, and this is where a Gantt chart earns its place.

1. Phases become task groups. Each top-level item turns into a group, and the pieces underneath become its subtasks.
2. Add a duration to each task. Use your best estimate, and note any ranges you are unsure about.
3. Link dependencies. The wireframes come before the visual design, the visual design before the page templates. This is where the order and the critical path appear.
4. Add milestones. "Design signed off" and "Site live" are good candidates, as explained in what a milestone is.

For the full walk-through of that second half, see how to create a project schedule.

In ProGantt Flow you can build this directly: create the groups, nest the tasks under them and link the dependencies on the timeline. If you already have your WBS written as text, you can also ask an MCP-connected assistant such as Claude to create the whole structure with groups, subtasks and dependencies in one go. The connector docs include example prompts. Review what it drafts: the assistant can turn your outline into tasks quickly, but it cannot know which work you forgot.

Common mistakes

• Mixing levels. "Design" and "Fix typo in footer" sitting side by side is a sign the structure is uneven.
• Going too deep. If you spend more time maintaining the WBS than doing the work, collapse the lowest level.
• Describing activities that never end. "Project management" or "Communication" as one task hides effort. Either list the specific meetings and reports or leave it out of the structure.
• Treating it as frozen. A WBS is a working document. When scope changes, update it first, then the dates. The weekly routine for keeping a plan current works well for this.

A quick checklist

Before you move on to dates, check that your work breakdown structure:

• starts from a one-sentence goal;
• has three to seven top-level phases or deliverables;
• ends in tasks one person can own and finish;
• passes the 100% rule at every level;
• has been read by at least one other person.

If it does, you have a solid base. Estimating, ordering and assigning are now much smaller problems, because you are no longer guessing what the project contains.