5.5 Create WBS

5.5 Create WBS
Inputs Tools & Techniques Outputs

Replace this with term.

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.

AI Systems with Claude, for Scrum Masters and Project Managers

Most AI pilots in project management do not fail on the model. They fail because somebody pointed the thing at a decision instead of at a task. This course is built around that distinction, and around the work that follows once you get it right.

Seven sections, taught against one running project from the first lecture to the last. You watch a system get built, then you build the same one against your own sprint. Nothing here is a demo that works only on the example.

You finish with five working systems and you keep them. The sprint report machine turns your board export and standup notes into the report you currently write by hand. The retro intelligence system tells you what the team keeps saying, not just what it said this time. The stakeholder comms engine drafts the update in the register the audience expects. The backlog health monitor flags the quiet decay nobody has time to check for. The risk and dependency tracker follows the chains that actually bite.

Seventy-six working files ship with it, across four sections, so every system is built against real sprint data rather than material invented for a slide. Four sprints of retrospectives, board exports, standup notes, backlog and risk data.

Explore the Course


Advance your Lean Six Sigma expertise!

HK School of Management helps you take Lean Six Sigma to the next level without the overwhelm. Master advanced statistical tools, Excel-based analysis, and real-world improvement techniques to solve complex problems with confidence. Practical skills, tools, and guidance you can apply right away. Covered by Udemy's 30-day refund policy.

Learn More