What a WBS is: deliverable-oriented, decomposing scope to exactly 100% — no more, no less
A Work Breakdown Structure (WBS) is 'a deliverable-oriented hierarchical decomposition of the work to be executed by the project team' — all the work needed to accomplish the objectives and produce the required deliverables, broken down level by level, with each lower level defined in more detail.
It is the core artifact of scope management: only after the WBS spells out 'what things must be produced' can you talk about scheduling, estimating costs, assigning work, and managing risk. The WBS originated in US Department of Defense project practice (later standardized as MIL-STD-881) and was generalized by PMI's Practice Standard for Work Breakdown Structures.
The 100% rule means that the child elements at every WBS level must completely cover the parent—no more and no less. If work is omitted, scope creep follows: a wedding plan may include venue, catering, and photography but omit a rain backup, forcing an expensive last-minute fix. Adding out-of-scope work is gold plating: a living-room renovation quietly expands to balcony storage, upsetting both budget and schedule. First ask what must be delivered, then assign ownership and acceptance criteria. Break down deliverables, not actions.
You can self-test this in the on-site project management quiz.
How to decompose: break down outcomes, not actions — stop at work packages you can estimate and control (8/80)
The best way to honor the 100% rule is to define every WBS element as an outcome/deliverable (a noun), not an action/activity (a verb). In WBS terms, 'work' means the work product/deliverable that effort produces, not the effort itself.
Example: write 'login module, acceptance passed' (an outcome), not 'develop the login feature' (an action). Why: outcomes are bounded and verifiable, so decomposing by outcome keeps the 100% rule locked in; decomposing by action sprawls and gets tangled up with scheduling. Remember: the WBS answers 'what must be delivered (what)' — activity sequencing and timing (how/when) belong to scheduling later (e.g., CPM).
How deep is deep enough? Stop at the work package — the lowest-level element of the WBS. PMI's definition: a work package is 'the lowest-level WBS component for which cost and duration can be estimated and managed.' Decompose until each work package can be reliably estimated for duration and cost, assigned to a single owner, and monitored — any finer is micromanagement that only adds overhead.
A common industry heuristic is the '8/80 rule': a work package should take roughly 8 to 80 hours (about one day to two weeks). Too big (over 80 hours) can't be estimated reliably and hides risk; too small (under 8 hours) costs more to manage than it's worth. For far-off work you can't see clearly yet, decompose coarsely now and refine as it approaches (rolling wave planning).
A WBS is not a task list, a Gantt chart, or an org chart: add the dictionary and build it in five steps
Three common confusions, settled at once:
- ① 'WBS = to-do task list' — wrong. A WBS is a scope decomposition by deliverables (outcomes), not an ordered list of actions.
- ② 'WBS = Gantt chart / schedule' — wrong. A WBS contains no dates or sequencing; it is the input to scheduling: first the WBS pins down scope, then activities are derived from work packages, dependencies are sequenced, and CPM computes the critical path.
- ③ 'WBS = org chart' — wrong. A WBS decomposes 'work/deliverables,' not 'departments/people' (the latter is the OBS, the Organizational Breakdown Structure).
In one line: the WBS governs 'what to produce,' the schedule governs 'when and in what order,' and the org chart governs 'who does it' — don't mix the three.
Alongside the WBS comes the WBS dictionary: for each WBS element it records the scope statement, deliverables, owner, acceptance criteria, and linked schedule/cost, so nobody argues about 'what exactly this piece includes.' The WBS's core value is serving as the scope baseline — it turns a vague 'do the project' into an exhaustive, non-overlapping list of deliverables; one practical maxim: 'If the work is not in the WBS, it is not part of the project' — it blocks scope creep smuggled in on the fly, and it forces you to list everything that must be done before work starts, preventing omissions.
The five steps to build a WBS: ① starting from the final deliverable/objective, list the major deliverables (level 2); ② split each major deliverable into sub-deliverables (outcomes, nouns — not actions); ③ keep decomposing until every piece is a work package you can estimate, assign, and control (reference: 8/80 hours); ④ verify the 100% rule level by level — children sum to the parent, with nothing out of scope; ⑤ assign WBS codes and write each element into the WBS dictionary (scope/owner/acceptance criteria). Once done, this WBS is the single starting point for scheduling (CPM), estimating, risk, and responsibility assignment.
自测 · 学完检查一下
想真正动手做题、记进度、攒连胜？到互动课里练。
What is a Work Breakdown Structure (WBS)?
答案：A deliverable-oriented hierarchical decomposition of project work — all the work needed to produce the required deliverables, broken down level by level, with lower levels defined in more detail
A WBS is defined as 'a deliverable-oriented hierarchical decomposition of the work': all the work the project team must do to accomplish the objectives and produce the required deliverables, broken down level by level, defined in more detail the lower you go. It is the core artifact of scope management — only after the WBS spells out 'what must be produced' can you schedule, estimate, assign, and manage risk. It is not a schedule network diagram (that belongs to scheduling), not an org chart (that's the OBS), and not a to-do list. The WBS originated in US DoD project practice (later MIL-STD-881) and was generalized by PMI's Practice Standard for WBS. (Sources: PMI, Practice Standard for Work Breakdown Structures; PMBOK Guide — Create WBS; Wikipedia — Work Breakdown Structure)
Which statement about the WBS '100% rule' is correct?
答案：The WBS must capture all the work in the project scope (including project management work itself) and must not include any work outside the scope; the rule holds at every level — children sum to exactly 100% of their parent
The 100% rule is the most important WBS principle: the WBS must capture all the work defined by the project scope — every deliverable (external, internal, interim), including project management work itself — and must not include any work outside the scope. And it holds at every level: a parent's children must sum to exactly 100% of the parent, no more, no less — under 100% means work nobody owns (a gap); over 100% means doing work that was never required (gold-plating / scope creep). It governs scope, not staffing allocation and not schedule coverage. (Sources: Gregory Haugan / workbreakdownstructure.com, 'The 100% Rule'; Wikipedia — WBS (the 100% rule applies at every level); PMBOK Guide)
True or False: When verifying a WBS, it's acceptable as long as a parent's children add up to 'no more than' 100% of the parent — a bit less is fine and just means conservative decomposition.
答案：False
False. The 100% rule requires children to sum to exactly 100% of the parent — no more and no less: under 100% means some work has no owner, leaving a scope gap (an omission); over 100% means doing work the scope never asked for (gold-plating / scope creep). That is exactly why building a WBS includes the dedicated step 'verify the 100% rule level by level': at every level, confirm the children sum to the parent and nothing out of scope has crept in. (Sources: workbreakdownstructure.com, 'The 100% Rule'; PMI, Practice Standard for WBS — construction steps and quality checks)
When building the WBS for an e-commerce project, which element is written the way a WBS element should be?
答案：Payment module, acceptance passed
Every WBS element should be defined as an outcome/deliverable (a noun), not an action/activity (a verb) — in WBS terms, 'work' means the work product/deliverable that effort produces, not the effort itself. 'Payment module, acceptance passed' is a bounded, verifiable outcome; 'develop…', 'hold…', and 'optimize…' are all actions — decomposing by action sprawls and gets tangled up with scheduling. Writing every element as an outcome is precisely the best way to honor the 100% rule: the WBS answers 'what must be delivered (what)'; activity sequencing and timing (how/when) belong to scheduling later (e.g., CPM). (Sources: PMI, Practice Standard for WBS (deliverable-oriented, not action); Wikipedia — WBS)
Down to which level should a WBS be decomposed?
答案：Down to work packages — 'the lowest-level WBS component for which cost and duration can be estimated and managed': stop once each can be reliably estimated, assigned to one owner, and monitored
The work package is the lowest-level element of the WBS; PMI defines it as 'the lowest-level WBS component for which cost and duration can be estimated and managed.' The stopping criterion is 'estimable and controllable': each work package can be reliably estimated for duration and cost, assigned to a single owner, and monitored — any finer is micromanagement that only adds overhead, and there is no fixed rule about the number of levels. The work package is the interface between scope and execution: upward it rolls up into larger deliverables; downward it maps to concrete activities and schedule. (Sources: PMBOK Guide — work package definition (lowest level at which cost and duration can be estimated and managed); Wikipedia — WBS)
True or False: Under the 8/80 heuristic, a work package should take roughly 8 to 80 hours (about one day to two weeks); for far-off work that is still unclear, you may decompose coarsely now and refine it as it approaches (rolling wave planning).
答案：True
True. Decomposition is not 'the finer the better': stop once each work package can be reliably estimated, assigned, and monitored. The common 8/80 rule says a work package should land at roughly 8 to 80 hours (about one day to two weeks) — too big (over 80 hours) can't be estimated reliably and hides risk; too small (under 8 hours) costs more to manage than it's worth. For far-off work you can't see clearly yet, decompose coarsely first and refine as it draws near — that is rolling wave planning. (Sources: PMBOK Guide — Decomposition / 8-80 heuristic / Rolling Wave Planning; Wikipedia — WBS)
A new project manager sends the team a Gantt chart with time bars and dependencies drawn in, saying 'this is our WBS.' Which correction is right?
答案：Wrong — a WBS is a scope decomposition by deliverables and contains no dates or sequencing; it is the input to scheduling: first the WBS pins down scope, then activities are derived from work packages, dependencies are sequenced, and CPM computes the critical path
WBS ≠ Gantt chart / schedule: a WBS contains no dates or sequencing — it answers 'what to produce (what),' while the schedule answers 'when and in what order (when).' The right order is: the WBS pins down scope first, then activities are derived from work packages, dependencies are sequenced, and CPM computes the critical path — the WBS is the input to scheduling, not the schedule itself. Nor is it an org chart (that's the OBS, governing 'who does it') or a to-do list (a WBS decomposes outcomes, not an ordered list of actions). (Sources: Wikipedia — WBS; PMBOK Guide — the WBS is the scope baseline and the basis for schedule and cost, not a schedule)
True or False: A WBS is essentially the project's org chart — map the company's departments and people onto the project, one branch per department.
答案：False
False. What a WBS decomposes is 'work/deliverables,' not 'departments/people' — a chart drawn by departments and reporting lines is an org chart, and its project-management counterpart is the OBS (Organizational Breakdown Structure). The one-line division of labor: the WBS governs 'what to produce,' the schedule governs 'when and in what order,' and the org chart governs 'who does it' — don't mix the three. (Sources: Wikipedia — WBS (a WBS is not an org chart; that is the OBS); PMBOK Guide)
True or False: 'If the work is not in the WBS, it is not part of the project' — this maxim both blocks scope creep smuggled in on the fly and forces the team to list all required work before starting, preventing omissions.
答案：True
True. The WBS's core value is serving as the scope baseline: it turns a vague 'do the project' into an exhaustive, non-overlapping list of deliverables — the common foundation for scheduling, estimating, risk identification, and responsibility assignment. 'Not in the WBS = not in the project' therefore cuts both ways: when someone tries to slip extra work in, first ask 'is it in the WBS?' — blocking scope creep; conversely, it forces you to list everything that must be done into the WBS before work starts, preventing omissions. The companion WBS dictionary records each element's scope statement, deliverables, owner, acceptance criteria, and linked schedule/cost, so nobody disagrees about 'what exactly this piece includes.' (Sources: PMBOK Guide — WBS Dictionary / Scope Baseline; Wikipedia — WBS)
Building a WBS from scratch — which sequence of steps is correct?
答案：List the major deliverables → split them into sub-deliverables (outcomes, nouns) → decompose to work packages you can estimate, assign, and control (reference: 8/80) → verify the 100% rule level by level → assign codes and write the WBS dictionary
The standard five steps: ① starting from the project's final deliverable/objective, list the major deliverables (level 2); ② split each major deliverable into sub-deliverables (outcomes, nouns — not actions); ③ keep decomposing until every piece is a work package you can estimate, assign, and control (reference: 8/80 hours); ④ verify the 100% rule level by level — children sum to the parent, with nothing out of scope; ⑤ assign WBS codes and write each element into the WBS dictionary (scope/owner/acceptance criteria). The direction runs from scope to execution: define 'what' first, and scheduling (CPM), estimating, risk, and responsibility assignment all start from this WBS — not the other way around, scheduling first and copying the schedule into a WBS. (Sources: PMI, Practice Standard for WBS (construction steps and quality checks); PMBOK Guide)