Explain Work Breakdown Structure (WBS) - Google Project Mgmt
Google Project Management Interview Question and Answers - Explain Work Breakdown Structure (WBS)
A Work Breakdown Structure (WBS) is a deliverable-oriented hierarchical decomposition of the total scope of a project. It breaks the project into smaller, more manageable components (levels), ending in work packages that can be planned, estimated, assigned, tracked and controlled. Think of it as “what we will deliver” decomposed to a level suitable for management and control.
Why the WBS matters?
Clarity of scope: Makes what’s in, and what’s out, explicit.
Traceability: Every requirement or deliverable maps to a WBS element, enabling end-to-end traceability (requirements → work package → schedule → cost → acceptance).
Improved estimating & accountability: Work packages are sized for reliable estimates and assigned owners.
Basis for planning & control: WBS feeds the schedule, cost baseline, resource plan and risk register.
Better governance: Control accounts and WBS numbering enable stage-gate oversight and variance analysis.
Core Components
Level: Each tier in the hierarchy (Level 1 = project, Level 2 = major deliverables or phases, etc.).
Control Account: A management control point at a selected level (often above work packages) where scope, schedule and cost are integrated and measured.
Work Package: The lowest WBS element used for planning and control, it’s small enough to estimate and assign.
WBS Dictionary: Companion document describing each WBS element (description, deliverables, acceptance criteria, resources, estimates, dependencies).
100% Rule: The WBS must include 100% of the project scope, everything required for project completion, including project management.
Mutually Exclusive Elements: WBS elements at the same level should not overlap in scope.
Principles to Follow
Make it deliverable-oriented (not activity-oriented). Focus on outputs (deliverables) rather than the tasks used to create them.
Apply the 100% Rule. Ensure the sum of child elements equals the parent’s scope.
Keep elements mutually exclusive. Avoid overlapping scope that causes double-counting and finger-pointing.
Decompose until you have actionable work packages. Work packages should be sized for reliable estimating and control (commonly aligned to control-account structure).
Use consistent numbering / coding. This makes traceability into schedules, cost accounts, and documents trivial.
Create a WBS dictionary. Don’t rely on the tree alone, the dictionary contains acceptance criteria, owners, and estimates.
Tailor depth to project size & governance needs. Larger projects need more levels (and formal control accounts); small projects can be shallow.
Involve SMEs & stakeholders in decomposition. You’ll get better scope coverage and buy-in.
Granularity
Work packages should be manageable and measurable. Common heuristics people use:
Time-based guideline: work package duration typically between 1 to 4 weeks for scheduling/control (some teams use the 8/80 rule, i.e., size work packages to be >8 hours and <80 hours, treat this as a heuristic, not a hard rule).
Control-account alignment: the work package should roll up into a control account where performance is measured.
If a work package is too small you create unnecessary overhead; too large and your estimates and tracking become unreliable.