Work breakdown structure (WBS): how to build one and turn it into a schedule

When a plan forgets the redirects from the old documentation pages, or the training nobody thought of, the dates are wrong before the first task starts. The work breakdown structure (WBS) is where that missing work gets caught. It divides the project into what it has to deliver, before anyone talks about dates.

This guide covers the two tests that keep a WBS complete, how deep to go and why most small teams should keep phases out of level 2. Then it follows a help centre launch from a 14-package WBS to a 27-day schedule, including the links between deliverables.

What a work breakdown structure is#

A work breakdown structure is a hierarchy that divides a project into the deliverables it must produce, and each deliverable into smaller pieces of work that can be estimated and assigned. NASA’s WBS handbook calls it “a product-oriented family tree that identifies the hardware, software, services, and all other deliverables required to achieve an end project objective”^[1].

Level 1 is the project and level 2 holds the main deliverables. Each further level splits an element into parts, down to the work packages, each one “the unit of work required to complete a specific job”^[1]. On large programmes cost and schedule are controlled one level up, at the control account, which can hold several work packages^[1]. With three to ten people the two coincide, and the work package is where an owner is named.

The tree has no dates and no sequence. Those arrive in the schedule, which is built from the work packages at the bottom of each branch.

Two tests that keep a WBS complete#

The first test comes from one sentence in NASA’s handbook: “Work scope not contained in the project WBS should not be considered part of the project”^[1]. Asked of every element, it becomes a practical question. If all the children are finished, is the parent finished? An answer that starts with “yes, apart from” has found a missing element. Enabling work counts as scope too, and NASA’s development checklist names project management explicitly^[1].

The second test catches duplicates. Cost and schedule should roll up from the lowest elements “without allocation of a single element of work scope to two or more WBS elements”^[1]. In spreadsheet plans the usual sign is a line pasted under two headings, such as “User guide” under Build and again under Training, with two estimates and two percentages complete.

A WBS dictionary closes the gaps that short element names leave open, and NASA prepares one partly “to eliminate duplication and overlap of work assignments”^[1]. On a small project three or four lines per work package are enough. A typical entry from the example below:

1.1.5 Published articles. Scope: 23 approved articles loaded and cross-linked. Excluded: translations and video. Owner: technical writer. Done when every article has a public URL and is returned by the help centre search.

That last line matters later, because it ties the content branch to the platform branch.

Deliverables, phases or departments at level 2#

Level 2 can be built around what the project produces (Content, Platform, Integration, Launch), around time (Design, Build, Test, Release) or around who does the work. Only the first shows what exists when the project ends. Phases repeat what the Gantt chart already shows along its bars, and departments lose the work that falls between two of them.

NASA lists Design, Engineering and Phase A among elements that “are not products and typically should not be used” as WBS subdivisions, Phase A being “a time frame”^[1]. Its phase-based and function-based counter-examples carry the same caption, “This Approach is Not Recommended”^[1]. The same section names the pull behind department-shaped trees. People ask “Where am I in that WBS?” and want elements that mirror their own area of responsibility, an error the handbook says should be avoided^[1]. Responsibility belongs in a separate matrix that crosses the WBS with the organisation chart^[1], and on a three-person project that matrix is an Owner column.

Why small teams put phases at level 2, and when they are right#

Small teams often end up with Design, Build, Test and Release at level 2, especially when the tree and the schedule are built in the same grid on the same afternoon and the summary rows turn into time buckets. The cost shows up weeks later. Redirects from old pages belong to neither Design nor Build, so in a phase tree nobody estimates them.

Our recommendation: for a team of three to ten people, put deliverables at level 2 and show the phases as milestones in the schedule. The Gantt chart already shows time, so a phase level repeats it. A deliverable level answers “is the help centre complete?” at a glance, and it lets the weekly status be read deliverable by deliverable.

The exception is a contract approved and paid phase by phase, such as a fixed-price discovery followed by a separately funded build. Acceptance and invoicing need a total per phase, and the client’s sign-off gates the next phase. With phases at level 2 that total is a summary row instead of a manual sum.

How many levels, and how to number them#

NASA ties the number of levels to “the size and complexity of the total effort, the degree of technical uncertainty, organizational structures concerned, and management’s judgment of need”^[1], and branches do not all have to stop at the same depth. As a rule of thumb, three levels fit a team of three to ten people over two or three months, with work packages directly under the deliverables. The limit is the weekly status meeting: at a minute or two per work package, 15 to 20 of them fill half an hour. Go to a fourth level on one branch when a work package would need two owners, or when its pessimistic estimate is more than double the optimistic one. The same decision one level lower, inside the schedule, is covered in when to split a task into subtasks.

Decimal codes show the level of an element and the element it belongs to. Code 1.2.3 sits on level 3 under 1.2. Once the plan is shared, status reports and tickets quote those codes, so a new element goes at the end of its branch, as 1.3.3 after 1.3.2, even if it would read better in the middle.

A worked example: launching a help centre#

A software company is replacing a PDF manual and a set of old documentation pages with a public help centre. The team is a technical writer, a front-end developer and the support lead, who also runs the project. The first release is in English only.

The first draft of the WBS had 10 work packages. Reading each branch with the first test added four. Nobody had approved the drafts, the bookmarked old pages would break at go-live, the product would keep pointing to the PDF, and support would keep answering tickets from the old manual.

Go-live is not in the tree because it has no scope of its own; it only marks the moment the work before it is finished. It goes in the schedule as a milestone, like “Content approved”.

Each work package becomes one task named with a verb, which meets NASA’s rule that the lowest level of each element “should have at least one task or activity”^[1]. Durations are in working days and every link is finish-to-start (the guide to task dependencies and lag covers the other three types). The two milestones sit at the end of their branches, so a tool that numbers every row keeps the work package codes of the WBS.

Publishing waits for search because the dictionary says an article is done only when search returns it. Without that link, search and analytics would show 13 days of float and could slip past publishing without anyone noticing.

Project management (1.5.1) is a level-of-effort task: it runs from day 1 to day 27 at a few hours a week and drives nothing, so it stays out of the critical path reading. The redirects use the slugs agreed in the inventory and wait for search only because the same developer does both. The in-app links wait for the published URLs because they ship in a product release, and a broken one needs another release.

The project takes 27 working days. The critical path runs through inventory, drafting, screenshots, review, publishing, in-app links, acceptance test and announcement, 2 + 11 + 3 + 3 + 2 + 3 + 2 + 1 = 27 days, and it crosses four of the five branches. A status report by deliverable would show Platform nearly done on day 9, with three of its four packages finished, while the package that decides the date, the acceptance test, cannot start before day 25. Set-up, theme and search have 10 days of float, the redirects 13, training 5.

Drafting carries the most risk: twenty-three articles in 11 days is just over two a day for one writer, and every day it slips moves go-live. It deserves a three-point estimate (estimating task durations); the critical path guide explains the passes behind the float values.

The workload check finds a gap: the developer has nothing scheduled from day 12 to day 21. Agree the slugs when the inventory is done, take the in-app links off publishing (predecessors 1.1.1 and 1.3.2) and run them on days 12–14. Publishing then links straight to the acceptance test, which starts on day 22. Go-live moves to the end of day 23 and the announcement to day 24. This is fast-tracking (how to recover a delayed project), and it extends the bet on the inventory slugs to links shipped in the product, where a renamed slug needs a release to fix.

Common mistakes#

• Reusing the last project’s WBS unchanged. NASA warns against carrying over “any mistakes or undesirable features of the earlier WBS”^[1]. Start from it if it helps, then run the first test again against this project’s scope.
• Elements called “Meetings” or “Rework”. Neither is something the project produces, and rework is on NASA’s list of non-product terms^[1]. Meeting time goes under project management, rework inside the package it fixes.
• Go-live as a work package. It has no scope to estimate.

When a full WBS is not worth it#

Below about 15 tasks with a single owner, as a rule of thumb, a flat task list with a “done when” line on each row does the job of a tree and a dictionary. Run the first test on the list anyway.

Breaking every branch down to work packages on day one goes wrong for work that is months away, because it invents a precision that the next quarter will overturn. NASA’s alternative is the planning package, which “defines far-term work at a summary level”^[1] and is split into work packages as the work gets closer. In a schedule that is one row with a rough duration and a note giving the date by which it must be broken down.

How to do it in Planitude#

Build the tree in the Gantt chart, with no limit on levels. Tab makes a row a subtask of the one above, Shift+Tab moves it back out. Planitude calls summary rows phases; name them after deliverables and the work packages become their subtasks.

To start from a spreadsheet, import the Excel or CSV file. Planitude rebuilds summary rows from a WBS column, a level column or indentation, reads predecessors written as WBS codes and shows a preview first. A template or a plan proposed by the AI assistant are the other starting points.

The WBS column is read-only. New rows take a code from their position, milestones included. Codes from an imported file (.mpp included), a template or a duplicated project are stored instead and stay put when rows move, so add new rows at the end of their branch. For codes like 1.2.3, put everything under one summary row named after the project. There is no WBS dictionary; scope and the “done when” line go in the task notes.

Frequently asked questions#