HKSM

Break project scope into a hierarchical structure of deliverables and work packages so the team can estimate, assign, and control the work. The result becomes part of the scope baseline together with the scope statement and the WBS dictionary.

Purpose & When to Use

Create WBS organizes the total project scope into a clear hierarchy of deliverables and work packages. It ensures nothing in scope is missed or duplicated, and it sets the foundation for estimating, scheduling, budgeting, and controlling scope. Use it after requirements are gathered and the scope is defined, and before activity definition and detailed estimating. In adaptive or hybrid work, a lightweight, deliverable-based WBS can be used at release or feature level while the backlog remains the day-to-day planning tool.

Mini Flow (How It’s Done)

• Review inputs: scope management approach, approved scope description, requirements, assumptions, and constraints.
• Choose a decomposition structure: typically deliverable-oriented; phases may be used for organization, but the breakdown should focus on outcomes.
• Decompose top-level deliverables into smaller components until work packages are sized for reliable estimating, assignment, and control.
• Apply the 100% rule: the sum of child elements fully equals the parent, with no overlaps or gaps.
• Create the WBS dictionary for each work package: description, boundaries, acceptance criteria, owner, assumptions, constraints, dependencies, and preliminary estimates or placeholders for planning packages.
• Assign unique codes (code of accounts) for tracking and integration with schedule, cost, and reporting systems.
• Validate completeness with the team and key stakeholders; adjust until the structure is clear and consistent.
• Seek approval and establish the scope baseline: scope statement, WBS, and WBS dictionary; manage any changes through formal change control.
• Use rolling wave planning where details are unknown: keep higher-level planning packages now and decompose them later when information is available.

Quality & Acceptance Checklist

• The WBS is deliverable-oriented and shows a logical hierarchy from project to work packages.
• The 100% rule is satisfied at every level, with no missing or overlapping scope.
• Work packages are sized so they can be estimated, assigned to an owner, and monitored.
• Naming is clear and uses noun/outcome language rather than activity verbs.
• Each element has a unique code of accounts identifier.
• The WBS dictionary entries are complete: description, boundaries, acceptance criteria, assumptions, constraints, dependencies, and responsible owner.
• Project management deliverables (e.g., plans, reviews) are included if they are part of the project scope.
• Stakeholders have reviewed and approved the WBS and dictionary, and the scope baseline is stored under version control.

Common Mistakes & Exam Traps

• Confusing the WBS with a schedule or an organization chart; the WBS shows deliverables, not sequences or reporting lines.
• Listing activities or tasks instead of outcomes; the WBS should be deliverable-based.
• Over- or under-decomposing; stop when work can be reliably estimated, assigned, and controlled.
• Leaving out the WBS dictionary; without it, acceptance criteria and boundaries are unclear.
• Ignoring the 100% rule, leading to scope gaps or overlap and double counting.
• Failing to include legitimate project management deliverables, causing underestimation.
• Skipping stakeholder validation and approval; once baselined, scope changes must go through change control.
• In agile or hybrid settings, breaking down into sprint tasks; keep the WBS at feature/epic or deliverable level, not daily tasks.
• Assuming vendor-provided structures fit automatically; tailor the WBS to your project’s scope and control needs.

PMP Example Question

Your team is unsure how far to break down deliverables while creating the WBS. What is the best guidance?

1. Decompose until each activity is less than one day of effort.
2. Keep breaking down until the schedule network can be drawn.
3. Decompose to a level where the work can be estimated, assigned to an owner, and controlled.
4. Always stop at exactly two levels below the project level.

Correct Answer: C — Decompose to a level where the work can be estimated, assigned, and controlled.

Explanation: The goal is a manageable work package size for planning and control, not an arbitrary number of levels or fixed effort threshold.