WBS Dictionary: Components, Example & Template [2026]
A. Togay Koralturk, Best-Selling PMP Author
Last updated on October 02, 2026
11 min read
A work breakdown structure tells you what the pieces of a project are; it doesn't tell you what each piece actually involves. That's the job of the WBS dictionary — the companion document that fills in the detail behind every box on the chart, so "1.2.1 Framing" becomes a clear statement of the work, its owner, its deliverables, and how you'll know it's done. Projects that skip it commonly end up in disputes over what a work package included. This guide explains the WBS dictionary in full — what it is, what it includes, a worked example, how it differs from the WBS, how to create one, and how it appears on the PMP and CAPM exams.
What is a WBS dictionary?
A WBS dictionary is the companion document to a work breakdown structure that provides detailed information about each element of the WBS — especially the work packages at its lowest level. Where the WBS shows the structure of the project's scope as a hierarchy of deliverables, the WBS dictionary supplies the detail behind each of those elements: what the work actually is, who owns it, what it produces, and how it will be judged complete.
The two are designed to work as a pair. The WBS is a diagram or list — compact and scannable, but by nature it only names each component. Together with the project scope statement and the WBS itself, the WBS dictionary forms the scope baseline — the approved definition of scope the project is planned and controlled against. Use it as a reference document: you consult the entry for a specific work package whenever a question about that work comes up.
The purpose of a WBS dictionary
The purpose of a WBS dictionary is to remove ambiguity about what each element of the project involves, so that everyone shares the same detailed understanding of the work. A WBS on its own can be interpreted differently by different people; the dictionary states the exact meaning of each component, so the team works from one definition.
That detail is used throughout the project. It makes estimating more reliable, because a well-described work package with defined deliverables is far easier to cost and schedule than a one-line label. It enables clear ownership and accountability, since each element names a responsible person. It supports scope control: with acceptance criteria written down, there's an objective standard for whether work is complete, and with the boundaries of each package defined, work that isn't in the dictionary is visibly not in scope — a direct defense against scope creep. And it improves communication, giving stakeholders and team members a single authoritative source for what any piece of the project actually means.
Ready to take the next step in project management?
200,000+ Professionals Taught by Our Instructors
What's included in a WBS dictionary? Components
A WBS dictionary is organized by WBS element, with an entry for each one (most importantly, each work package). While the exact fields vary by organization, a thorough entry captures the following:
| Component | What it captures |
|---|---|
| WBS ID / code | The element's unique identifier in the WBS hierarchy (e.g., 1.2.1). |
| Work package name | The short title of the element, matching the WBS. |
| Description of work | A clear statement of the work involved: the entry's most important field. |
| Responsible owner | The person or organization accountable for the element. |
| Deliverables | The specific outputs the work package produces. |
| Acceptance criteria | The conditions the work must meet to be accepted as complete. |
| Cost estimate | The budgeted cost for the element. |
| Schedule / milestones | Key dates, duration, or milestones for the work. |
| Required resources | The people, materials, and equipment needed. |
| Dependencies | Predecessor and successor relationships with other work. |
| Assumptions & constraints | The conditions assumed, and the limits the work operates within. |
| Quality requirements | Standards or specifications the work must satisfy. |
Not every entry needs every field, and some organizations add others (technical references, contract or agreement information, approvals). But the essential core is consistent: what the work is, who owns it, what it delivers, and how "done" is judged. Those four fields are what make a WBS element plannable, executable, and verifiable.
WBS dictionary example
An example makes the components concrete. Take a single work package from a house-building project — 1.1.1 Excavation, sitting under the Foundation deliverable — and its WBS dictionary entry might read:
| Field | Entry |
|---|---|
| WBS ID | 1.1.1 |
| Work package | Excavation |
| Description | Clear the site and excavate the foundation area to the depth and dimensions in the approved drawings, including removal and disposal of spoil. |
| Owner | Site works subcontractor (supervised by the construction lead) |
| Deliverables | Excavated foundation trench, ready for formwork and inspection |
| Acceptance criteria | Depth and dimensions within ±25 mm of drawings; base level and compaction signed off by the site engineer |
| Cost estimate | $18,000 |
| Schedule | 3 days; must finish before 1.1.2 Concrete pour begins |
| Resources | Excavator, operator, two laborers, spoil-removal truck |
| Dependencies | Predecessor: site survey and permits; successor: 1.1.2 Concrete pour |
| Assumptions | No rock or contaminated soil; ground conditions as per the geotechnical report |
Notice how much this adds over the single WBS label "Excavation." Anyone reading it knows exactly what the work covers, who's responsible, what it produces, the standard it must meet, and what it connects to. Every work package in the project would have an entry like this, and that collection of entries is the WBS dictionary. The same pattern applies to any project — a software work package's entry would swap in code deliverables, test-based acceptance criteria, and developer owners, but the structure is identical.
WBS vs. WBS dictionary
The WBS and the WBS dictionary are constantly mentioned together and sometimes confused, but they do different jobs. The comparison at a glance — the WBS is the structure, a hierarchical breakdown of the project's deliverables into work packages, usually shown as a tree or an indented list. The WBS dictionary is the detail — a narrative description of each of those elements, capturing everything the diagram can't.
| Work breakdown structure | WBS dictionary | |
|---|---|---|
| What it is | A hierarchy of deliverables and work packages | A detailed entry for each WBS element |
| Form | A diagram or indented list | A document or table of descriptions |
| Answers | What are the pieces of the project? | What does each piece actually involve? |
| Analogy | The map | The legend |
A WBS without a dictionary leaves each element undescribed, and a dictionary without a WBS has no hierarchy to organize its entries.
How to create a WBS dictionary
Creating a WBS dictionary is a systematic pass through the WBS, adding detail to each element. A reliable process:
- Start from the completed WBS. The dictionary describes the elements the WBS defines, so the WBS comes first.
- Take each work package in turn. Work through the lowest-level elements (and higher-level deliverables where useful), one entry at a time.
- Describe the work clearly. Write a specific statement of what the work involves — enough that someone unfamiliar could understand its scope.
- Assign an owner and define the deliverables. Name who's accountable and what the package produces.
- Add acceptance criteria and estimates. Specify how completion will be judged, and record cost, schedule, resources, dependencies, and assumptions.
- Validate and maintain it. Review entries with the team who will do the work, and keep it current as the scope evolves.
The most common mistake is treating it as a box-ticking formality with vague, copy-pasted descriptions. Each entry must be specific enough to state what the work involves, what it produces, and how completion is judged.
Who creates it and when
The project manager creates the WBS dictionary together with the project team — specifically the people who will do or manage the work, since they best understand what each element involves. It's a collaborative effort rather than something written in isolation, because accurate descriptions, estimates, and acceptance criteria depend on the knowledge of subject-matter experts.
It's produced during scope definition, as part of the same effort that creates the WBS (the PMBOK® Guide's Develop Scope Structure process), and after the project scope statement is defined. In practical terms, the team builds the WBS to lay out the structure, then fills in the dictionary to detail each element, and the two are baselined together. From that point, the WBS dictionary becomes a controlled component of the scope baseline: it's referenced throughout execution whenever the specifics of a work package are in question, and any changes to it flow through the project's change-control process rather than being edited informally.
The WBS Dictionary on the PMP® and CAPM® Exams
On the PMP exam and the CAPM, the WBS dictionary shows up as part of scope management, and the facts to lock in are straightforward: it's the detailed companion to the WBS, it describes each WBS element (especially work packages), and together with the scope statement and the WBS it forms the scope baseline. It's an output of creating the WBS, and it's a controlled document subject to change control.
Exam questions often test the distinction between the WBS (the structure) and the WBS dictionary (the detail) — a WBS dictionary is not the diagram, and it's not the scope statement either. You may also be asked what the dictionary contains (descriptions, owners, acceptance criteria, estimates) or which artifact a project manager should turn to when a work package's specifics are unclear. Our PMP Complete Study Guide, the most complete on the market, covers the scope baseline and its components exactly as the exam frames them. If you're learning project management from the ground up, our Complete Project Management Course teaches scope definition step by step.
PMP Practice Question: WBS Dictionary
On a fixed-price construction contract, the subcontractor responsible for work package 1.1.2 Concrete submits an invoice for additional payment covering "below-grade damp-proofing," arguing that the WBS shows 1.1.2 only as "Concrete" and that waterproofing work is therefore outside their package. The project manager pulls the baselined WBS dictionary entry for 1.1.2: its description of work reads "concrete pour including below-grade damp-proofing per specification S-204," and its acceptance criteria require an engineer-signed moisture test. The sponsor, wanting to keep the subcontractor cooperative, suggests simply paying the claim from the contingency reserve.
What should the project manager do?
a) Pay the claim from the contingency reserve as the sponsor suggests, since interpretation disputes on fixed-price work are exactly the kind of risk the reserve exists to absorb.
b) Decline the additional payment, showing that the baselined WBS dictionary entry — the authoritative detail of the work package — already includes the damp-proofing work within 1.1.2's scope.
c) Accept that the WBS itself does not show waterproofing as an element and process the claim, since the hierarchy is the approved scope baseline and a dictionary cannot add work the WBS does not display.
d) Submit a change request to add a waterproofing work package to the WBS, so the extra work is formally brought into scope and the subcontractor's billing can be regularized.
Correct answer: B.
Rationale: The WBS names each element; the WBS dictionary defines what each element includes — and both are components of the scope baseline, equally binding. The baselined entry for 1.1.2 explicitly includes the damp-proofing in its description and acceptance criteria, so the work is already inside the package and already priced; the claim fails on the project's own controlled documents. Choice c) is the central trap: it treats the diagram as the whole baseline, but a WBS element is never self-describing — the dictionary exists precisely because a one-word label like "Concrete" cannot carry the scope detail, and its baselined entries carry the same authority as the chart. Choice a) spends reserve money on work that is already paid for within the package price, and buying cooperation is not a risk response. Choice d) runs change control to "add" work that the baseline already contains, which would double-scope and double-pay the same work. Only b) reads the scope baseline as the integrated set it is: structure in the WBS, authoritative detail in the dictionary. 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
Frequently asked questions
What is a WBS dictionary?
A WBS dictionary is the companion document to a work breakdown structure that provides detailed information about each WBS element, especially the work packages. Where the WBS shows the structure of the project's scope as a hierarchy, the dictionary describes what each element actually involves — the work, its owner, deliverables, acceptance criteria, and estimates. Together with the scope statement and the WBS, it forms the scope baseline.
What is included in a WBS dictionary?
For each work package, a WBS dictionary typically includes the WBS ID or code, the work package name, a description of the work, the responsible owner, the deliverables, acceptance criteria, cost and schedule estimates, required resources, dependencies, and any assumptions and constraints. Some organizations add technical references, agreements, or approvals. The essential core is what the work is, who owns it, what it delivers, and how completion is judged.
Can you give a WBS dictionary example?
For a work package "1.1.1 Excavation" on a construction project, the dictionary entry might describe the work as clearing and excavating the foundation area to approved drawings, name the site-works subcontractor as owner, list the excavated trench as the deliverable, set acceptance criteria (depth within tolerance, signed off by the engineer), and record the cost, duration, resources, and dependencies. Every work package in the project has a similar detailed entry.
What is the difference between a WBS and a WBS dictionary?
A WBS is the hierarchical breakdown of a project's deliverables into work packages, usually shown as a tree or indented list — it shows what the pieces are. A WBS dictionary is the detailed narrative describing each of those elements — what each piece actually involves, its owner, deliverables, and acceptance criteria. The WBS is the map; the dictionary is the legend. Both, with the scope statement, make up the scope baseline.
How do you create a WBS dictionary?
Start from the completed WBS, then work through each element — especially the work packages — writing an entry for each. For every one, describe the work clearly, assign an owner, define the deliverables and acceptance criteria, and add cost, schedule, resource, dependency, and assumption details. Validate the entries with the team who will do the work, and maintain the dictionary as a controlled document, updating it through change control as scope changes.
Who creates the WBS dictionary?
The project manager creates the WBS dictionary together with the project team, particularly the people who will do or manage the work and understand what each element involves. It's produced during scope definition, as part of the same effort that creates the WBS and after the scope statement is defined, and it's baselined alongside the WBS as part of the scope baseline.
Is the WBS dictionary on the PMP exam?
Yes. The WBS dictionary is part of scope management on the PMP exam. You are expected to know that it is the detailed companion to the WBS, that it describes each WBS element and work package, and that together with the scope statement and the WBS it forms the scope baseline. A common test point is distinguishing the WBS (structure) from the WBS dictionary (detail).
Is the WBS dictionary on the CAPM exam?
Yes. The CAPM covers the WBS dictionary as part of scope management, usually a little more directly than the PMP — often testing what it is, what it contains, or how it differs from the WBS. Because the CAPM is scenario-based, you should also be ready to recognize when a project needs a WBS dictionary to resolve ambiguity about its work packages.
Work Breakdown Structure (WBS): Examples & Guide [2026]
A work breakdown structure (WBS) decomposes a project's scope into deliverables and work packages. The 100% rule, types, an example, and PMP exam tips.
