How to Write a WBS Dictionary: Definition, Deliverables, Acceptance Criteria

The WBS tree lists the work; the WBS dictionary is each box's contract. A box that carries only a name gets read differently by everyone. The same box called "payment module design" reads as screen design to the designer, API design to the developer, and both to the PM — and all three start executing convinced they are right. The dictionary is the document that closes that gap at planning time. This guide covers how to write the three fields that make up the practical minimum — definition, deliverables, acceptance criteria — through bad and good examples, then which boxes to write them for, why most dictionaries die, and how far AI drafting can be trusted.

Why the Tree Alone Isn't Enough

A WBS tree is strong at dividing work exhaustively, but each box's name is short. A name points at the work; it doesn't draw a boundary. Whether "data migration" includes validation, or "screen design" includes visual mockups, the name alone cannot say.

Start executing with blurry boundaries and two things happen: work that both sides thought belonged to the other goes missing, and work that both sides thought was theirs gets done twice. Either way, the discovery usually arrives just before acceptance — the most expensive possible moment. Building the tree itself, exhaustively, is covered in How to Create a WBS: 5 Steps; this guide is about drawing a boundary around each box that tree produced.

The Three Things a Dictionary Holds

The WBS dictionary in the PMBok tradition is a roomy document — it can carry owners, durations, and cost estimates. But the minimum set that actually causes accidents when missing is three fields.

First, the definition — what this box includes and what it does not (the boundary of scope). Second, the deliverables — what tangible things exist when this box is done (a list of nouns). Third, the acceptance criteria — who checks what to call it finished (a sentence someone can adjudicate). The three answer, respectively: what is this work, what comes out of it, and when is it over. If these three are empty, filling in the rest means little — you'd be assigning an owner and a duration to work nobody has agreed on.

Definition — the Sentence That Draws a Boundary

Start with the bad example: "Design the payment module." That's the box's name stretched into a sentence; it draws no boundary at all.

A good definition separates included from excluded. "Includes: payment-flow screen design (cart through payment complete), PG-integration API spec. Excludes: PG vendor contract negotiation, settlement batch design (done in 1.4.2)." A definition becomes a contract the moment you write the exclusions. Everyone writes the inclusion list; disputes always break out just outside the boundary — the sentence "wait, I thought that was included" appears exactly where no exclusion was written. When an excluded item is performed in another box, write that box's code next to it, so the work can't quietly belong to nobody.

Deliverables — Answer with Nouns

Bad example: "design in progress." That is not a deliverable; it is a status. A status can't be held in your hands, and what can't be held can't be inspected.

Good example: "Screen design document v1.0 (12 screens), PG-integration API spec, one volume." Deliverables should be nouns, and countable ones where possible. The moment a deliverable becomes a countable noun, a side effect follows: progress becomes countable too. "9 of 12 screens done = 75%" is a sentence only possible in a box whose deliverables were defined as nouns. The progress of a "design in progress" box is forever the owner's mood.

Acceptance Criteria — a Sentence an Inspector Can Adjudicate

Bad example: "development complete." Nothing says what must be in what state, or who decides. Boxes like this are the ones that sit at "80% done" for eight straight weeks.

Good example: "All 12 screens passed design review; PO approval on record." Good acceptance criteria have two properties: a condition that can be judged yes-or-no, and a named judge. With a number (all 12 screens), a passing condition (design review), and an approver (PO) in place, the done-or-not argument has nowhere to stand. Acceptance criteria protect the worker as much as they constrain them — once the criteria are met, further asks are a scope change, not finishing touches.

Which Boxes to Write It For

Mandating a dictionary for every node is the fastest way to kill it as a formality. The priority has two layers.

Write it for work packages — the lowest-level boxes — first. That is where actual work and acceptance happen; parent boxes are the sum of their children and usually have nothing separate to say. Then, among work packages, start with the boxes where a split interpretation is expensive — boxes on the boundary with a subcontractor, hand-off points between teams, boxes with customer acceptance attached. Within a single team, many boxes are fine on name alone. Boxes with another organization on the far side of the boundary are not.

Why Most Dictionaries Die

On many projects the dictionary is a Word file written once around kickoff and never opened again. It's not a diligence problem; it's a location problem. When the planning document lives in a folder apart from the execution data, there is no reason to open it during execution — and a document that isn't opened isn't updated, and a document that isn't updated loses trust.

A living dictionary is attached to the node. Open the task and the definition and acceptance criteria are right there; when "is this box done?" comes up in the weekly check, the criteria adjudicate on the spot. If reports and acceptance documents are extracted from this data, the dictionary maintains itself — the principle that deliverables should be extracted, not authored, is covered in The PM Too Busy Reporting to Manage.

Using AI for Drafts

The three fields have fixed shapes — a definition is include/exclude, deliverables are a noun list, acceptance criteria are an adjudicable sentence. Fixed-shape writing is where AI drafting works well: give it the box name and project context and a usable draft comes back. For a real record of Claude building a six-month ERP project's WBS and drafting per-work-package dictionary entries along the way, see We Let Claude Build an Entire SI Project's WBS.

Drafts are the machine's; confirmation is human. Two spots in particular only a human can settle: the exclusion list (what you decided not to do is an organizational decision, not an inference) and the judge in the acceptance criteria (who approves is a question of authority). When an AI draft arrives, review those two spots first.

What to Read Next

The dictionary doesn't stand alone; it sits in the middle of a journey. The step before it is the WBS guide — dividing the work exhaustively. The step after it is measuring and reporting the progress of boxes so defined — only where deliverables are nouns and acceptance criteria are adjudicable sentences do progress figures and acceptance run without argument. In wbsgantt every WBS node carries a 1:1 dictionary — definition, deliverables and acceptance criteria plus assumptions, constraints, estimates and references, with a completeness indicator, and with MCP connected you can take AI drafts and confirm them. There is no approval workflow, so the record of confirmation lives inside the acceptance criteria sentence itself — name the approver there.