Lesson 2 — Work Breakdown Structure¶
At a glance
- Module: 05 — Scope & Requirements Management
- Level: Intermediate
- Estimated time: 40 minutes
- Example project: the LMS and the inventory management system
Learning objectives¶
By the end of this lesson you should be able to:
- Decompose project scope into a work breakdown structure organised by deliverable.
- Apply the 100% rule and identify gaps or overlaps in a decomposition.
- Define work packages at a level that can be estimated, owned, and tracked.
- Explain how a WBS differs from a task list and from an organisational chart.
Prerequisites¶
Introduction¶
A work breakdown structure (WBS) is a hierarchy that decomposes project scope into smaller, manageable pieces. It is the bridge between "what the project will deliver" and "what the work is".
The value is not the diagram. It is the act of decomposition: you cannot estimate, sequence, or assign work you have not identified, and a WBS is how you find out what you have not thought about. A scope statement can be read in two minutes and hide a year of work.
1. Decompose by deliverable, not by activity¶
The most common mistake is building a WBS from verbs: design, code, test, deploy. That is a process list, not a structure, and it hides scope — you cannot tell from it what has been forgotten.
A WBS organises by noun: the deliverables and their parts.
| Decomposed by activity (weak) | Decomposed by deliverable (better) |
|---|---|
| 1. Design | 1. Submission capability |
| 2. Build | 1.1 Submission form |
| 3. Test | 1.2 File storage |
| 4. Deploy | 2. Grading capability |
| 2.1 Grading view | |
| 2.2 Grade export |
The deliverable-based version can be walked with a stakeholder, and a missing deliverable is visible. The activity-based version looks tidy and proves nothing.
2. The 100% rule¶
The 100% rule states that the WBS must contain everything in scope and nothing outside it.
- Gaps are deliverables nobody listed. They appear later as "we forgot".
- Overlaps are deliverables appearing in two branches. They produce duplicated estimates and arguments about ownership.
Both are found by testing the structure against the scope statement, item by item, in both directions: every scope item appears somewhere, and every WBS branch traces back to scope.
3. Work packages¶
A work package is the lowest level of a WBS. Stop decomposing when the package:
- can be estimated with reasonable confidence,
- can be owned by one person or a small pair,
- can be completed in a short period, and
- produces something you can point at when it is done.
Decomposing further adds cost without adding control. A WBS that goes to individual edits is a task list wearing a hierarchy.
Each work package should have a short description — sometimes called a WBS dictionary entry — naming what it produces, who owns it, and what "done" means.
LMS (illustrative)
For the LMS, "Build submission form" is a usable work package: one developer, a few days, and a visible result. "Implement LMS" is not a package — it is the whole project. "Add validation to the file upload field" is below package level: the cost of tracking it exceeds the information gained.
4. What a WBS is not¶
- Not a schedule. A WBS has no dates or sequence. Sequence comes from dependencies (Module 06).
- Not an organisational chart. A WBS is about deliverables; an org chart is about reporting.
- Not a task list. Tasks change constantly; deliverables change rarely. That stability is why the WBS is a useful baseline and a task list is not.
Key terms¶
| Term | Meaning |
|---|---|
| Work breakdown structure (WBS) | A hierarchical decomposition of scope into work packages |
| Deliverable | An output the project produces |
| Work package | The lowest level of a WBS: estimable, ownable, trackable |
| 100% rule | The WBS contains everything in scope and nothing outside it |
| WBS dictionary | A description of each work package: output, owner, done criteria |
| Decomposition | Breaking scope into progressively smaller pieces |
Worked example¶
Task: build a WBS for the first release of the illustrative LMS submission capability, and check it against the 100% rule. Durations are invented for illustration.
Step 1 — Start from the scope statement. The release includes: submission of assignment files by students, storage of those files, and grading by teaching staff. Group work, plagiarism checking, and notifications are explicitly excluded.
Step 2 — Decompose once, by deliverable. Branch 1: Submission capability. Branch 2: Grading capability. Nothing else yet.
Step 3 — Decompose each branch until a work package is reached.
| ID | Work package | Owner | Est. |
|---|---|---|---|
| 1.1.1 | Submission form and validation | Developer A | 4 d |
| 1.2.1 | File storage and access rules | Developer A | 3 d |
| 2.1.1 | Grading view and feedback entry | Developer B | 3 d |
| 2.2.1 | Grade export for the exams office | Developer B | 2 d |
Step 4 — Apply the 100% rule forwards. Walk the scope statement. Submission: form and storage are covered. Grading: view and export are covered. Nothing in scope is missing. Two work packages under each branch is a little thin, but the release is small — that is a legitimate outcome.
Step 5 — Apply the rule backwards. Walk the WBS. Does every package trace to the scope statement? Yes. Does any package describe excluded work? No — notifications are absent, correctly.
Step 6 — Check the exclusions are visible. Write the excluded items into the scope statement rather than leaving them implied. The exams office will ask about notifications, and the answer should already exist.
Common misconceptions¶
“A WBS is a to-do list”
A task list changes weekly. A WBS decomposes scope into deliverables and is stable enough to baseline. If yours changes every sprint, it is a task list.
“More levels mean more control”
Detail beyond work-package level costs tracking effort and buys nothing. Stop at the level you will actually manage.
“The WBS covers only the technical work”
It covers everything needed to complete the scope — including documentation, migration, and acceptance testing. Omitting them means they are discovered as unbudgeted work.
Practical activity¶
Build and test a WBS for one release of an example project.
- Write a scope statement of no more than five lines, with at least two exclusions.
- Decompose by deliverable to work-package level, numbered hierarchically.
- Produce a work-package table with an owner and an estimate for each.
- Test the 100% rule in both directions and record any gap or overlap you found.
- Draw the structure as a Mermaid flowchart.
What "good" looks like: at least one gap you found by testing rather than by luck, and a decomposition by deliverable rather than by development activity. Use the Work Breakdown Structure template.
Self-assessment¶
- Why does decomposing by deliverable hide less scope than decomposing by activity?
- What four tests tell you that a work package is small enough?
-
You test your WBS and find that "data migration" appears in two branches. Why does that matter?
-
Apply it — admission portal WBS. A draft second level reads: analysis, design, coding, testing, deployment. The sponsor says it looks complete because those are all the things the team will do.
Hint: A strong answer names the decomposition rule that is being broken and tests the replacement in both directions.
Show answers
- Because deliverables can be checked against the scope statement, and a missing deliverable is visible as an absence. Activity-based structures (design, build, test) contain every process by construction, so they always look complete even when a deliverable has been forgotten.
- It can be estimated with confidence, can be owned by one person or pair, can be completed in a short period, and produces something you can point at when done. If any test fails, either decompose further or merge it upward.
- Because it will be estimated twice, so the budget and schedule are overstated; and because two owners will exist for one output, so accountability is ambiguous and the work may be done twice or assumed to be someone else's. Overlaps are as damaging as gaps, and harder to spot.
- The draft decomposes by activity, which describes the process rather than the scope, and it hides the deliverables — a phase list cannot show a sponsor what is finished. Decompose by deliverable instead: application form and validation rules; document upload and verification; fee payment integration; applicant status tracking; admissions back-office review; reporting and exports; migration of last year's applicant data; accessibility and audit evidence. Then apply the 100% rule in both directions: is anything in scope missing (notifications, audit logging, the policy-driven eligibility rules)? and is anything present that is out of scope (is deployment a deliverable, or does it belong to the operational handover)? Stop decomposing when a work package can be estimated, owned by one person, completed in a short interval, and verified.
Summary¶
- A WBS decomposes scope into deliverables and their parts; decomposition by noun hides less than decomposition by verb.
- The 100% rule tests both directions: nothing in scope is missing, and nothing outside scope is present.
- Work packages are the stopping point: estimable, ownable, short, and verifiable.
- A WBS is not a schedule, an org chart, or a task list; its stability is what makes it a baseline.
Further learning¶
- Module 06 — Schedule Management turns work packages into a schedule.
- Work Breakdown Structure template.
- A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Project Management Institute — scope management and the work breakdown structure.
Next¶
Continue to Module 06 — Schedule Management.