# How to Create a Work Breakdown Structure Mind Map

Canonical: https://sakura5.app/blog/how-to-create-a-work-breakdown-structure-mind-map/  
Published: 2026-10-12  
Author: the Sakura5 team · 8 min read  
Updated: 2026-10-12  
Publisher: Sakura5 (https://sakura5.app) · support@sakura5.app

> **TL;DR:** How to create a work breakdown structure mind map: decompose a project into deliverables and work packages, apply the 100% rule, then number it for planning.

![How to Create a Work Breakdown Structure Mind Map](https://sakura5.app/img/blog/inline/how-to-create-a-work-breakdown-structure-mind-map-1.jpg)

To create a work breakdown structure mind map, put the project’s final deliverable in the center, branch out into the four to seven major deliverables that make it up, and keep splitting each branch into smaller pieces until every outer node is a work package one person or team can estimate, own and finish. Then number the nodes (1, 1.1, 1.1.1) and check that each level adds up to exactly the level above it — nothing missing, nothing extra.

A work breakdown structure, or WBS, is the backbone of a project plan. Schedules, budgets and task assignments all hang off it, so if the breakdown has a hole, every document built on top inherits that hole. Drawing it as a mind map instead of an indented spreadsheet makes the holes easier to spot, because an empty or lopsided branch is visible at a glance.

Below you’ll find why most first-draft WBS charts go wrong, a step-by-step method, a full worked example for an office move, what to do with the awkward cases, and a short FAQ.

## Why a WBS drawn as a list goes wrong

The usual first attempt at a WBS is a to-do list with indentation. Someone types the tasks they can already think of and nests a few under others. The result looks structured, but it has three quiet problems.

First, it’s organized around *activities* instead of *deliverables*. “Call vendors” and “have meetings” end up as branches, when the WBS should describe the things the project produces — a signed lease, a wired network, a moved team. Activities belong in the schedule later; the WBS describes scope.

Second, it breaks the 100% rule. The standard principle, described in the [overview of work breakdown structures on Wikipedia](https://en.wikipedia.org/wiki/Work_breakdown_structure) and in most project management texts, is that the children of any node must add up to 100% of that node’s work. A list makes it easy to leave out the dull pieces — testing, handover, documentation — because nothing on the page asks for them.

Third, the depth is uneven. One branch drills down five levels because the author knows that area well; another stops at a single vague node because nobody has thought about it yet. On a long list, that imbalance hides. On a radial map, a stubby branch next to a bushy one is the first thing you see.

## How to create a work breakdown structure mind map, step by step

### 1. State the final deliverable in the center

Write the center node as the finished result, not the project’s nickname. “Team working from the new office by 1 March” is a deliverable; “Office project” is a label. A sharp statement here keeps every branch honest.

![How to create a work breakdown structure mind map, step by step — how to create a work breakdown structure mind map](https://sakura5.app/img/blog/inline/how-to-create-a-work-breakdown-structure-mind-map-2.jpg)

*Write the center node as the finished result, not the project’s nickname.*

### 2. Add the major deliverables as first-level branches

Aim for four to seven first-level branches. You can split by phase (design, build, launch) or by component (hardware, software, training), but pick one approach and stick with it at this level — mixing them is how work gets counted twice. Always include a project management branch for the coordination work itself: status reporting, budget tracking, sign-offs. It’s real work and the 100% rule says it has to live somewhere.

If you’re staring at a blank canvas, a generated first draft helps. In [Mindmap AI](https://sakura5.app/mindmapai/) you can type the project — “move a 40-person office” — and the AI proposes a full map of branches and sub-branches in seconds. Treat it as a draft to argue with, not an answer: rename branches into deliverable nouns, merge overlaps, delete what doesn’t apply.

### 3. Decompose each branch until you reach work packages

Keep splitting each branch into smaller deliverables. Stop when a node is a **work package**: small enough that one owner can estimate its effort and cost with reasonable confidence, and clear enough that everyone would agree when it’s done. A common rule of thumb is that a work package should take somewhere between a day and two weeks of effort; treat that as a sanity check, not a law. Most projects end up three or four levels deep. When a branch feels thin, select the node and use the AI expand action to suggest sub-items you may have missed, then keep only the ones that are genuinely in scope.

### 4. Apply the 100% check at every level

Go branch by branch and ask two questions of each parent: if all its children were finished, would the parent be finished? And is any child doing work that belongs to a different parent? The first question catches gaps; the second catches double counting. This is the step people skip.

### 5. Number the nodes and move to outline view

Add codes to the node labels: 1, 1.1, 1.1.1 and so on. The numbering is what lets a schedule, a budget line or a ticket refer back to an exact piece of scope. Then switch to outline view, where the same map becomes an indented, collapsible list — the format most project tools and kickoff documents expect. With Pro you can export that outline as a PDF or HTML document, or as JSON if you want to import it somewhere else.

## A worked example: moving a 40-person office

Say Priya runs operations for a design agency of 40 people. The lease ends on 28 February, and the new office is two floors larger, across town. She has twelve weeks.

![A worked example: moving a 40-person office — how to create a work breakdown structure mind map](https://sakura5.app/img/blog/inline/how-to-create-a-work-breakdown-structure-mind-map-3.jpg)

*Say Priya runs operations for a design agency of 40 people.*

Center node: “All 40 staff working from the new office on 1 March, with no lost working days.” She sets out six first-level branches:

1. **1 New space ready** — lease signed, layout approved, fit-out complete, furniture installed.
2. **2 IT and network** — internet line live, Wi-Fi survey and access points, meeting-room screens, printer setup.
3. **3 Physical move** — moving company booked, packing crates delivered, move-day plan, old-office clear-out.
4. **4 People and communication** — desk plan, staff briefing, access cards, new-address FAQ.
5. **5 Admin and legal** — address changes with bank, clients and suppliers, insurance update, old-lease handover.
6. **6 Project management** — budget tracker, weekly status note, final sign-off.

Her first draft looks fine until she looks at the shape. Branch 2 has eleven nodes, because she’s spent years dealing with IT. Branch 5 has one node that just says “paperwork.” That stub is a warning. She breaks it down: 5.1 address change notifications (bank, payroll provider, website, Google Business listing, client contracts), 5.2 insurance policy update, 5.3 old-lease exit (final inspection, deposit return, keys handed back). The old-lease exit alone hides a risk — the landlord’s inspection has to happen after the clear-out but before 28 February — that would have been invisible inside “paperwork.”

The 100% check catches two more things. Nothing in branch 3 covers disposing of the furniture that isn’t moving, so she adds 3.5 surplus furniture removal. And “test the Wi-Fi” appears under both branch 1 and branch 2, so she deletes the copy under branch 1.

The final map has six branches, 31 work packages, and three levels at most. Each work package gets an owner’s initials in its label. In outline view it becomes a two-page numbered list she pastes into the kickoff doc, and the codes (3.2, 5.3) become the IDs she uses in the schedule and the budget sheet. The whole breakdown takes about an hour.

## Edge cases and judgment calls

**The project is too big for one map.** Give each first-level branch its own map once it passes about 40 nodes, and keep a top-level map that shows only levels 0 to 2. The codes keep the maps connected: branch 2 on the master map is the center of the “2 IT and network” map.

**You don’t know enough to decompose a branch yet.** That’s normal for later phases. Leave the branch at a higher level and mark it to be broken down once the earlier work answers your questions — project managers call this rolling-wave planning. An honest stub beats an invented breakdown.

**Your team wants tasks, not deliverables.** Build the WBS from deliverables first, then list the tasks under each work package when you schedule. If you’re planning in a looser, more exploratory way, our guide to [mind mapping for project planning](https://sakura5.app/blog/mind-mapping-for-project-planning/) covers risks, resources and the jump to a task list. And if a whole group is building the breakdown together, see [how to organise ideas for a group project](https://sakura5.app/blog/how-to-organise-ideas-for-a-group-project/) for running the session without it stalling.

When you need to hand the finished breakdown to someone who doesn’t use your tools, [Mindmap AI](https://sakura5.app/mindmapai/) keeps the map and the numbered outline in sync, so you can share whichever view fits the audience.

## FAQ

**Can a mind map be used as a work breakdown structure?**

Yes. A WBS is a hierarchy, and a mind map is a hierarchy drawn radially, with the final deliverable in the center and sub-deliverables branching outward. The radial layout makes gaps and lopsided branches easier to see. Once the breakdown is complete, convert it to a numbered outline for schedules and budgets.

**How many levels should a work breakdown structure have?**

Most projects need three or four levels below the final deliverable. Stop decomposing a branch when its outer nodes are work packages: pieces one owner can estimate, schedule and finish, often between a day and two weeks of effort. Going deeper than that turns the WBS into a task list, which belongs in the schedule.

**What is the 100% rule in a WBS?**

The 100% rule says the children of any node must add up to exactly all of that node’s work — no gaps and no overlaps. Check it level by level: if every child were done, would the parent be done, and is any child duplicating work from another branch? It is the main quality test for a work breakdown structure.

**Should a WBS list tasks or deliverables?**

Deliverables. A work breakdown structure describes the scope of what the project produces, using nouns like “network installed” rather than verbs like “call the ISP.” Tasks and activities come later, when you schedule each work package. Keeping the two separate stops the WBS from becoming an incomplete to-do list.

About the app: [MindMap AI: Mind Map Maker](https://sakura5.app/mindmapai/) · App Store: https://sakura5.app/go/mindmapai?from=/blog/how-to-create-a-work-breakdown-structure-mind-map/