This work breakdown structure template turns a defined scope into a deliverable hierarchy you can review for missing and overlapping work. The example includes a four-output inventory, a corrected WBS, and a work-package dictionary entry.
Start from the scope you have agreed
The original fictional project is a gallery information kit. Its supplied scope inventory contains four outputs:
| Scope ID | Output and boundary |
|---|---|
| G1 | Visitor guide: the guide's text and layout. |
| G2 | Exhibit labels: label text and layout for the supplied exhibits. |
| G3 | Docent brief: the host's introduction and visitor-question notes. |
| G4 | Production handoff: the agreed source files and a version index for the kit. |
Exhibition installation, ticketing, website publication, and new exhibit research are excluded from this teaching project. The exhibit list, actual content, approval authority, and file specifications must be supplied for a real kit. No actual gallery, approved materials, or finished files are represented.
PMI's paper on WBS basics describes a deliverable hierarchy, coverage of the parent scope, nonoverlapping branches, and the distinction from a project schedule. Use those principles to review how the work is divided. This example does not claim compliance with a current mandatory project-management standard.
Build the hierarchy around outputs
Here is the corrected structure for the supplied inventory:
1 Gallery information kit
1.1 Visitor information
1.1.1 Visitor guide [G1]
1.1.2 Exhibit labels [G2]
1.2 Host and production handoff
1.2.1 Docent brief [G3]
1.2.2 Production handoff [G4]
The branch names group related outputs. Their children describe what the project will produce. Draft guide, review labels, and send files are activities you may schedule later; Visitor guide, Exhibit labels, and Production handoff name the outputs those activities serve.
Keep IDs stable as the structure develops. If the team moves a work package, record the changed parent and check its scope boundary. The hierarchy should explain what belongs together without making a reader infer the structure from indentation alone.
Find a duplicate and a missing output
Choose Draft structure in the example. The draft puts G2 under both 1.1.2 Exhibit labels and 1.2.1 Label package. It has no leaf for G3. Compare inventory shows the repeated G2 mapping and the missing G3 mapping beside the four-item inventory.
Then choose Corrected structure. The 1.2.1 leaf becomes Docent brief, mapped to G3. The handoff package still needs the label source files, but it does not create another set of label content. That distinction belongs in its dictionary entry.
The corrected mapping accounts for G1–G4 once each under this example's convention. It does not prove that the original four-item inventory contains every output a real gallery project needs. Review the inventory itself with the scope owner, including any management, review, or other work the actual project must contain.
At each parent, ask whether the children together describe the agreed parent scope and whether sibling boundaries overlap. A count can find repeated IDs; it cannot decide whether two differently named packages quietly include the same work.
Write the boundary in a work-package dictionary
Select 1.2.2 Production handoff to read this worked dictionary entry:
| Dictionary field | Worked entry |
|---|---|
| WBS ID and name | 1.2.2 · Production handoff |
| Scope reference | G4 |
| Output | A collected set of agreed kit source files and an index identifying each file and version. |
| Includes | Assemble the agreed guide, label, and docent-brief source versions; prepare the version index. |
| Excludes | Creating or revising their content, producing a second label set, printing, and website publication. |
| Review condition | The reviewer can match each indexed file/version to the agreed handoff specification. Actual reviewer and specification must be confirmed. |
| Inputs | The agreed source versions from G1, G2, and G3, plus the handoff specification. |
This entry explains why the handoff refers to the labels without duplicating G2. References and inputs can cross branches; the defined output should retain a clear boundary.
Choose a level of detail that lets the team understand and manage each package. Splitting every noun into smaller boxes can make the structure harder to review. If a package still hides several unrelated outputs or an unclear acceptance boundary, decompose or clarify it before assigning detailed activities.
Copy a prompt for the hierarchy and scope review
Create one complete HTML work-breakdown-structure review page.
Project scope and explicit exclusions: [PASTE]
Agreed deliverable inventory with stable scope IDs: [PASTE]
Proposed hierarchy with WBS IDs and parent/child relationships: [PASTE]
Work-package boundaries, inputs and review conditions: [PASTE]
Unresolved scope decisions and actual scope owner: [PASTE]
Organize deliverables as a hierarchy. Use output names, explain
parent/child coverage and inspect sibling overlap. Do not turn it
into a schedule, task-completion tracker or responsibility matrix.
Use supplied scope only; do not invent approved work or finished files.
Include this separate original fictional gallery-information kit:
G1 Visitor guide: guide text/layout.
G2 Exhibit labels: label text/layout for supplied exhibits.
G3 Docent brief: host introduction and visitor-question notes.
G4 Production handoff: agreed source files plus kit version index.
Exclude installation, ticketing, website publication, new exhibit research.
No actual exhibit content, approved files or full real-project scope
is supplied. Mapping all four IDs does not prove real completeness.
Root 1 Gallery information kit.
Branch 1.1 Visitor information: leaf 1.1.1 Visitor guide G1;
leaf 1.1.2 Exhibit labels G2.
Branch 1.2 Host and production handoff:
Draft leaf 1.2.1 Label package G2; leaf 1.2.2 Production handoff G4.
Corrected leaf 1.2.1 Docent brief G3; leaf 1.2.2 stays G4.
Draft duplicates G2 and omits G3. Corrected maps G1–G4 once each.
Show both states; do not silently erase the draft discrepancy.
Dictionary 1.2.2 Production handoff/G4:
Output: agreed source files and index identifying file/version.
Includes assembling agreed G1/G2/G3 source versions and index.
Excludes content creation/revision, second label set, printing, publishing.
Review: match each indexed file/version to handoff specification;
actual reviewer/specification remain to confirm.
Inputs: agreed G1/G2/G3 versions and handoff specification.
Provide Draft structure, Corrected structure, Compare inventory and
1.2.2 dictionary selection. Inventory comparison names missing
and duplicate scope IDs in the supplied mapping, not a universal
completeness score. Keep branch/leaf labels explicit as text.
Add a blank hierarchy/dictionary scaffold and local scope notes;
preserve typing across views and confirm reset. No automatic scope
approval, project completion or schedule generation. At least 16px
text, native labeled controls, visible focus, stacked hierarchy/records
at 360px without overflow. Inline CSS/JavaScript, no external assets,
network or storage. State notes are temporary. Return full HTML.
Read the output against the supplied inventory and exclusions. Check that the dictionary keeps G4's collection of source files separate from G2's creation of label content. Then ask the scope owner whether the inventory itself needs additions or a different boundary.
Settle the work-package boundary before scheduling it
An HTML WBS can show the hierarchy and selected dictionary entry together. Put it in your NOS workspace when the people defining the work need to discuss where the label output ends and its handoff begins.
If “Label package” is being used for the collected production files, clarify the static dictionary description in visual editing mode. Save the wording so colleagues can reopen the existing link and read the boundary. Update the maintained hierarchy and scope records through the project's actual change process; text editing does not approve added scope or change programmed inventory mappings.
Use the agreed work packages as the basis for the next planning step. Add activities, estimates, dependencies, and dates in the schedule after the team can explain what each package includes.