Work Breakdown Structure: How to Build One With Examples

When the US Government Accountability Office (GAO) examined the plutonium disposition program of the National Nuclear Security Administration, part of the US Department of Energy, it found a breakdown of the work for each construction project but no formal one for the program as a whole. Without one, the agency could not be sure its life-cycle cost estimate captured all relevant costs.¹

A work breakdown structure (WBS) is the tool that was missing: a tree that divides everything a project must deliver into smaller pieces, level by level, until each piece is small enough to estimate, assign and track. GAO calls it the cornerstone of every program, because it defines in detail the work needed to meet the program’s objectives.¹ To build one:

1. Name the end product at the top.
2. Break it into deliverables, not departments or phases.
3. Check every level against the 100 percent rule.
4. Stop at work packages one person or team can own.
5. Write a WBS dictionary entry for each element.

For a customer conference, that means one box called “Customer conference”, five deliverables under it such as Venue and Catering, and small, ownable pieces such as “Menu and tasting” under Catering.

Listing the parts also changes how long you think the work will take. In five lab experiments published in 2004, people prompted to list a task’s parts gave longer time estimates than people who judged the task whole, and in two of the experiments less biased ones; the more complex the task, the larger the benefit.²

What a work breakdown structure is, and what it is not

A work breakdown structure describes what a project will produce, not when or how. NASA’s WBS handbook, last revised in 2025, calls it a product-oriented family tree of the hardware, software, services and other deliverables a project needs, and says that work left out of the WBS should not be considered part of the project.³ That boundary also makes scope creep easier to spot: a request that fits no element of the tree is new work, and deserves its own decision about time and money.

A WBS turns the agreed scope, one of the core ideas of project management, into something you can count and check.

Elements are named as nouns, not verbs. A 2006 PMI conference paper on PMI’s practice standard describes how PMI’s definition moved from a task-oriented family tree of activities in 1987 to a deliverable-oriented decomposition in 2004. Its reasoning: nouns are needed to define the whole scope, while verbs belong to the activities attached to the lowest level.⁴

Back at the conference, “Book the venue” is an activity; “Venue” is a deliverable, and under it sits everything the venue involves, from the contract to the room layout. A tree of nouns keeps asking what must exist at the end, which is easier to check for gaps than a to-do list. So when an element in your tree starts with a verb, ask what it produces and name that instead.

Myth

A work breakdown structure is a detailed to-do list with dates.

Fact

A WBS lists what will be delivered. Tasks and dates come later, when the lowest-level work packages are turned into a schedule.

The 100 percent rule: every level adds up to its parent

The 100 percent rule says a WBS contains all the work in the project’s scope, project management included, and nothing outside it, and that at every level the children add up to exactly their parent. The 2006 paper on PMI’s practice standard calls it one of the most important principles for building and checking a WBS, and credits it to Gregory Haugan’s 2002 book on the subject.⁴

GAO states the same arithmetic in its cost guide: the sum of a parent’s children must equal the parent, so each element is related to only one piece of work. Work left out, GAO warns, can lead to schedule delays and cost increases; the plutonium program case that opens this page is the guide’s own example of what goes wrong.¹

The rule catches two opposite mistakes. Work counted in two places inflates the budget and blurs who owns it: if name badges appear under both registration and venue, the conference pays for them twice, or two people each assume the other is ordering them. Work left out simply never happens: if nobody gives signage a place in the tree, nobody buys the signs.

A quick test: cover a parent box and ask whether its children, and only its children, would deliver it in full. If you hesitate, something is missing or sits in the wrong place.

How to build a work breakdown structure, step by step

Each step below uses the same worked example: a customer conference with an illustrative budget of $100,000.

1. Name the end product at the top

The top level is the entire project, a single element named for the finished result, such as “Customer conference” rather than “Plan the conference”. NASA’s handbook defines it this way and expects every element to have completion criteria that can be verified, agreed during early planning.³ So settle now what “done” means for the whole project.

2. Break it into deliverables

The second level holds the major deliverables. The 2006 PMI paper says every project needs a project management element at this level, so the work of planning, tracking and reporting has a place.⁴ For the conference, the second level is project management, venue, program and speakers, catering, and guest registration. Deliverables are the default; phases suit one kind of project, covered after these steps.

3. Check every level against the 100 percent rule

Once a level exists, test it. In the example, the five second-level elements add up to the $100,000 at the top, and the three work packages under catering add up to catering’s share.

• 11 Customer conference (the whole project): $100,000
• 21.1 Project management: $10,000
• 31.2 Venue: $30,000
• 41.3 Program and speakers: $20,000
• 51.4 Catering: $30,000
• 71.4.1 Menu and tasting: $5,000
• 81.4.2 Food and drink: $22,000
• 91.4.3 Serving staff: $3,000
• 61.5 Guest registration: $10,000

Where a cost could sit in two places, pick one. GAO’s guide warns against double counting and says each child should have only one parent. It also says meetings, travel and computer support belong inside the element they serve, not in a branch of their own.¹ For the conference, the venue’s kitchen fee goes under venue or under catering, never both.

4. Stop at work packages one person or team can own

The lowest level of a WBS is the work package, where activities are defined, scheduled and tracked.¹ NASA’s handbook describes a work package as the unit of work needed to complete a specific job, such as a test, a report or a design, and the point where work is planned and progress is measured. At some level on every branch, it adds, management assigns an organizational unit responsibility for technical, schedule and cost performance.³

NASA’s handbook sets no fixed depth: each branch is broken down only as far as adequate management and control require, so branches can end at different levels.³

Both of GAO’s figures come from guidance written for large US federal programs. The same guide says work far in the future can stay coarse: in rolling wave planning, near-term work is split into detailed work packages, while distant work sits in larger planning packages that are broken down as the date approaches.¹ Turning packages into activities, dependencies and dates is the schedule’s job, the subject of a separate guide to Gantt charts, and the full project plan brings the WBS together with the budget and risks.

A stopping test drawn from these guides asks whether the piece has one owner, a budget you can defend and dates that mark a clear finish. If not, break it down again; if so, stop.

5. Write a WBS dictionary entry for each element

A WBS dictionary is the companion document that describes, in words, the work inside each element. NASA’s handbook says it helps ensure all work is identified and removes duplication and overlap; each entry gives the element’s title, code and content, and the dictionary is kept as a controlled document.³

The “Excludes” line does the most work. It settles in advance where a borderline cost belongs, which is the 100 percent rule applied in words.

Before you call your WBS finished

• The top level names the finished result, as a noun
• The second level is deliverables, with project management included
• Every parent equals the sum of its children
• No piece of work appears in two places
• Each work package has one owner, dates and a budget
• Each element has a dictionary entry with an Excludes line

Download PDF ↓

Get this checklist as a one-page PDF. We'll email you the download link.

Your emailAlso send me the weekly newsletter (launching soon)Email me the PDF

We use your address to send this link and, only if you tick the box, the newsletter. Privacy policy.

Deliverable-based or phase-based decomposition?

Organize by deliverable unless the work runs in dependent stages: US government guides call for deliverables, while PMI guidance also accepts life-cycle phases for sequential work. GAO calls a product-oriented WBS a best practice and says functions such as design engineering and quality assurance are not products and should not be elements. Its reason is diagnosis: if framing a house runs over budget, a tree built around products shows where, while a tree organized by the carpenters who do the framing would not.¹

NASA’s handbook shows a phase-oriented tree as a common error, noting that design is a function and a project phase is a time frame, not a product.³ The US defense standard, MIL-STD-881F of 2022, is just as firm: acquisition phases are not WBS elements, and the WBS documents the total scope of work whatever life-cycle phase it falls in.⁵

PMI’s guidance is more flexible. The 2006 paper says that when product development runs in sequential stages, with later work depending on the outcome of earlier work, it makes sense to organize the WBS around the life cycle rather than the physical parts of the product.⁴ The current third edition of PMI’s practice standard, published in 2019, applies the WBS to predictive, iterative, incremental and agile life cycles and explores several types of decomposition.⁶

For a website redesign, a deliverable-based tree has branches for the home page, the checkout and the content, while a phase-based one has design, build, test and launch. If the checkout runs late, the first tree shows it at once; the second shows only that “build” is behind. When unsure, start with deliverables, and switch to phases only when later work depends on how earlier work turns out.

Why listing the parts changes your estimate, and when it misleads

Listing a task’s parts before estimating it is linked to longer time estimates. Justin Kruger and Matt Evans proposed a reason in 2004, that people who judge a task whole do not naturally think through all of its parts, and tested it. Their experiments used everyday tasks, not a WBS, so they suggest a reason the method helps rather than prove it does.²

Asked how long your monthly report takes, you probably picture the writing. Gathering the figures, chasing one missing number and the final read-through stay out of the picture, and out of the estimate, until someone lists them.

The study

Moderate evidence

Five experiments on estimating a task whole or in parts

People prompted to break a task into its parts gave longer estimates of how long it would take than people who estimated it whole, and in the third and fourth experiments those estimates were less biased. The fifth experiment found that the more complex the task, the more unpacking helped.²

We could see only the abstract of the Kruger and Evans paper, so its sample sizes and effect sizes are not reported here. The result bears on the planning fallacyplanning fallacy: The tendency to underestimate how long your own tasks will take, even when you know similar tasks ran late before. Estimating from your track record on past tasks, rather than from the plan, tends to correct it.Full entry in the glossary, the habit of underestimating the time our own work needs, and fits the authors’ explanation that whole-task estimates leave parts of the work out.

Unpacking does not correct estimates automatically. In three studies at two European universities, Constantinos Hadjichristidis and colleagues found that listing unusual parts that are quick to do made estimates shorter, listing unusual long parts made them longer, and listing typical parts, in the one study that tested them, changed nothing. Unlike Kruger and Evans, the researchers supplied the lists themselves.⁷

For a WBS, completeness matters more than the number of boxes. Give the long, easily forgotten work, such as testing, rework, handover and project management itself, a place in the tree, and do not let a few quick items stand in for a whole branch.

What backs the method, and what is still untested

Support for the WBS comes from professional standards and long practice rather than experiments: our searches turned up no trial that compared projects run with and without one. Each row pairs a claim with the type of evidence behind that claim.

GAO’s and NASA’s guides were written for large US public programs. A small team can keep the principles that work at any size (the 100 percent rule, nouns for deliverables, one owner per package) and treat numeric rules, such as GAO’s minimum of three levels, as a guide rather than a requirement.

The bottom line

A work breakdown structure is a list of everything a project must produce, arranged so that each level adds up to the one above. Build it from deliverables, stop where someone can own and estimate a piece, and write down what each piece includes and excludes. Put the slow, dull work in the tree too, since listing parts helps estimates only when the list is complete.