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.

Leadership for Project Managers Course

Lead with clarity, confidence, and real impact. This Leadership for Project Managers course turns day-to-day challenges—unclear priorities, tough stakeholders, and cross-functional friction—into opportunities to guide teams and deliver outcomes that matter.

You’ll learn practical leadership skills tailored to project realities: setting direction without overcontrol, creating alignment across functions, and building commitment even when authority is limited. We go beyond theory with tools you can use immediately—one-sentence visioning, stakeholder influence maps, decision framing, and feedback scripts that actually land.

Expect hands-on frameworks, real-world examples, and guided practice to prepare for tough moments—executive readouts, resistance from stakeholders, and high-stakes negotiations. Downloadable templates and checklists keep everything actionable when the pace gets intense.

Ready to influence without waiting for a bigger title? Join a community of ambitious PMs, sharpen your edge, and deliver with purpose—project after project.



Lead with clarity, influence, and outcomes.

HK School of Management brings you a practical, no-fluff Leadership for Project Managers course—built for real projects, tight deadlines, and cross-functional teams. Learn to set direction, align stakeholders, and drive commitment without relying on title. For the price of a lunch, get proven playbooks, and downloadable templates. Backed by a 30-day money-back guarantee—zero risk, high impact.

Learn More