Work Breakdown Structure (WBS): Examples & Guide [2026]

Large projects are hard to plan until the work is broken down. The work breakdown structure splits the total scope into pieces small enough to estimate, assign, and complete. It's one of the most fundamental artifacts in project management, and getting it right makes scheduling, budgeting, and scope control dramatically easier. This guide explains the work breakdown structure in full — what it is, how it's structured, the 100% rule, types, a worked example, how to create one, and how it appears on the PMP and CAPM exams.

What is a work breakdown structure (WBS)?

A work breakdown structure (WBS) is a hierarchical, deliverable-oriented decomposition of the total scope of work a project team must carry out to accomplish its objectives and create the required deliverables. In plainer terms, it takes everything a project needs to produce and breaks it down, level by level, into progressively smaller and more manageable pieces.

The key word is deliverable. A WBS is organized around what the project will deliver — the products, services, and results — not the activities the team will perform to create them. It defines and organizes the project's entire scope in one place, which is why it is one of the three components of the scope baseline and serves as the foundation for almost everything that follows: estimating costs, building the schedule, assigning responsibility, and tracking progress. Without a WBS, scope is recorded informally across several documents. With one, the full scope is defined in a single structure the team can review and approve. "WBS" stands for Work Breakdown Structure.

What a WBS looks like: structure and levels

A WBS is arranged as a hierarchy, usually drawn as a tree that starts with the whole project at the top and branches downward into finer detail. Each level decomposes the level above it into smaller components, with a numbering system (a "code of accounts") identifying where each element sits.

The levels follow a consistent logic. Level 1 is the project as a whole. Level 2 breaks it into the major deliverables (or sometimes phases) — the big chunks of what the project produces. Each of those is decomposed further, and the lowest level of any branch is a work package. Every element gets a WBS number (1.0, 1.1, 1.1.1, and so on) that shows its place in the hierarchy, making it easy to reference a specific piece of work precisely. The result is a structure you can read top-down (from the whole project to its smallest parts) or bottom-up (rolling work packages up into deliverables), which is what makes it so useful for both planning and tracking.

Ready to take the next step in project management?

200,000+ Professionals Taught by Our Instructors

PMP® Certification Training

PMP Training →

CAPM® Certification Training

CAPM Training →

Learn Project Management

PM Course →

The 100% rule

The single most important principle governing a WBS is the 100% rule: the WBS must capture 100% of the work defined by the project scope — all of the work, and only the work. Nothing that's in scope should be missing, and nothing that's out of scope should be included.

The rule works at every level of the hierarchy. The sum of the child elements below any parent must equal 100% of that parent — the work packages under a deliverable together make up all of that deliverable, no more and no less. This has two consequences. First, it's a completeness check: if the pieces don't add up to the whole, something has been forgotten. Second, and just as importantly, it defines the project's boundary — if it isn't in the WBS, it isn't in the project. That is how the WBS controls scope creep and gold plating: new work must be added to the WBS, and to the scope, schedule, and budget, before it can be done. The 100% rule is what makes the WBS an authoritative definition of scope rather than an incomplete outline.

Work packages and the WBS dictionary

The work package is the lowest level of a WBS — the point at which you stop decomposing. A good work package is small enough to reliably estimate its cost and duration and to assign to a single owner, but not so small that the WBS contains unnecessary detail. A common rule of thumb is the 8/80 rule: a work package should represent roughly between 8 and 80 hours of effort. Above the work packages, elements can be grouped into control accounts, management points where scope, budget, and schedule are integrated and measured — the anchor for techniques like earned value.

A WBS is often paired with a WBS dictionary, a companion document that describes each WBS element in detail: what work it includes, the responsible owner, cost and duration estimates, acceptance criteria, and dependencies. The WBS itself shows the structure of the scope; the WBS dictionary supplies the detail behind each box. Together they leave no ambiguity about what each piece of the project actually involves, which is why the two are treated as partners — the diagram gives you the map, and the dictionary gives you the legend.

Types of work breakdown structure

WBSs are usually distinguished in two ways: by how they organize the work, and by how they're presented. Both are worth knowing, because the right choice depends on the project.

The most important distinction is deliverable-based versus phase-based. A deliverable-based WBS organizes everything around what is produced, which keeps the focus on outcomes and aligns cleanly with the 100% rule; it's the default recommendation. A phase-based WBS organizes the top level around when work happens (the phases), which can suit projects that think naturally in stages. The tree-versus-outline choice, by contrast, is purely about presentation — the same WBS can be drawn as a diagram or written as an indented list, whichever communicates better for the audience.

A work breakdown structure example

Consider a simple project: building a house. At Level 1 sits the whole project, "Build House" (1.0). At Level 2, it decomposes into its major deliverables — for instance Foundation (1.1), Structure (1.2), and Interior (1.3). Each of these is then broken down further into work packages:

• 1.1 Foundation → 1.1.1 Excavation, 1.1.2 Concrete pour, 1.1.3 Waterproofing
• 1.2 Structure → 1.2.1 Framing, 1.2.2 Roofing, 1.2.3 Exterior walls
• 1.3 Interior → 1.3.1 Plumbing, 1.3.2 Electrical, 1.3.3 Finishes

Notice that every entry is a deliverable or component — a thing the project produces — not an activity like "pour the concrete" or "call the electrician." Those activities come later, when the schedule is built by decomposing each work package into tasks. The same pattern applies to any project: a website might break into Design, Front-End, Back-End, and Content deliverables; a software release into Requirements, Development, Testing, and Deployment.

How to create a WBS

Creating a WBS is a structured, usually collaborative exercise, best done with the team and drawing on the project's scope statement. A reliable process:

1. Start from the scope. Use the project scope statement and its defined deliverables as the source of truth for what's in scope.
2. Identify the major deliverables. Establish the Level 2 elements — the big deliverables (or phases) the project must produce.
3. Decompose each deliverable. Break each major deliverable down into sub-deliverables and, ultimately, work packages, going only as deep as you need for reliable estimating and assignment.
4. Apply the 100% rule and check sizing. Confirm the children of each element sum to the whole, and that work packages are appropriately sized (the 8/80 guideline).
5. Assign WBS codes. Give every element its hierarchical number so each piece can be referenced precisely.
6. Build the WBS dictionary. Document each element's details — work, owner, estimates, and acceptance criteria.

Stop decomposing when a component is small enough to estimate and assign to one owner. Decomposing further adds detail you will not use.

Benefits of a WBS

A well-built WBS pays off across the whole project, which is why it's considered foundational:

• Clear, agreed scope. It puts the entire scope in one visible structure, so everyone shares the same understanding of what the project will and won't deliver.
• Better estimates. Small work packages are far easier to estimate accurately for cost and duration than a whole project at once, improving both cost estimation and scheduling.
• A basis for planning and control. The WBS underpins the schedule, the budget, resource assignment, and earned value measurement — all of which build on its work packages.
• Clearer communication and accountability. Each work package has an owner and a precise identifier, so responsibility and progress are unambiguous.

WBS on the PMP® and CAPM® Exams

The work breakdown structure is one of the most heavily tested topics in project management, and it's central to scope management on both the PMP exam and the CAPM. The facts to lock in: the WBS is deliverable-oriented (not activity-oriented), it's created through decomposition, its lowest level is the work package, it's governed by the 100% rule, and together with the scope statement and WBS dictionary it forms the scope baseline.

Situational and knowledge questions frequently test the deliverable-versus-activity distinction — a WBS built from tasks is a classic wrong answer — as well as the 100% rule and the definition of a work package. You may also be asked what the WBS is an input to (estimating, the schedule, the budget) or how it helps control scope. Our PMP Complete Study Guide, the most complete on the market, covers scope management and the WBS exactly as the exam frames them. If you're learning project management from the ground up, our Complete Project Management Course teaches the WBS and scope planning step by step.

PMP Practice Question: WBS

During execution of an ERP implementation, two findings land on the project manager's desk in the same week. First, the sponsor asks the team to build a data-migration utility, arguing it is "clearly implied" by the Deployment deliverable; the utility appears nowhere in the WBS, though the team agrees it would genuinely help the rollout. Second, a quality review of the WBS finds that the work packages under deliverable 2.3 Training cover the course materials but omit the learning-platform configuration that 2.3's scope statement describes.

How should the project manager handle the two findings?

a) Build the utility, since the sponsor's reading of the Deployment deliverable is reasonable, and add the missing platform work under 2.3 as the team encounters it during execution.

b) Add the utility to the WBS directly under Deployment to honor the sponsor's request, and log 2.3's gap in the risk register in case the missing work causes problems later.

c) Treat the utility as potential new scope through change control, adding it to the WBS and baselines only if approved, and correct 2.3's decomposition now so its work packages again account for all of its scope.

d) Decline the utility permanently as out of scope under the 100% rule, and correct 2.3's decomposition now so its work packages again account for all of its scope.

Correct answer: C.

Rationale: The two findings are the two halves of the 100% rule — the WBS contains only the work in scope, and all of it. The utility is not in the WBS, so under the rule it is not in the project no matter how useful or "implied" it seems; the route for adding it is a change request, and only an approval updates the WBS, scope, schedule, and budget. The 2.3 gap is the opposite failure: work that is in the defined scope is missing from the decomposition, so the children of 2.3 no longer sum to 100% of their parent; that is a correction to a defective WBS, not a scope change, and it should be fixed now. Choice a) does unauthorized work on the sponsor's interpretation and leaves a known decomposition error to be discovered piecemeal. Choice b) edits the baseline on authority instead of through change control, and a risk-register note is no substitute for completing a decomposition known to be wrong. Choice d) is the subtle trap: it applies the 100% rule as a permanent wall, but the rule governs what is in the WBS today — it does not forbid new scope, it forbids new scope without the change process. Only c) applies both halves of the rule with the right mechanism for each. To drill this kind of scope-definition judgment, work through our PMP practice exams or, at the entry level, our CAPM practice exams.

Ready to take the next step in project management?

200,000+ Professionals Taught by Our Instructors

PMP® Certification Training

PMP Training →

CAPM® Certification Training

CAPM Training →

Learn Project Management

PM Course →

Frequently asked questions