In one line: Break the whole project into a hierarchy of deliverables and work packages, small enough to estimate, assign and track. It is the backbone that schedule, budget and risk all hang from.

Core idea

Before a project can be scheduled or costed, its scope has to be broken into manageable pieces. A work breakdown structure (WBS) decomposes the total scope into a tree: the project at the top, major deliverables or phases beneath it, and work packages at the bottom. A work package is a unit of work small enough to estimate, assign to one owner, and track to completion. A practical handbook used in the course [1] places the WBS early in a planning sequence: after the scoping agreement, the requirements and the task list, and before the schedule.

How it works

  • The 100% rule. The WBS includes all the work of the project, and nothing outside it. Each level’s children add up exactly to their parent.
  • Decompose by deliverable, rather than by department or time period, where possible. That keeps the focus on outcomes.
  • Go deep enough. The course asks for at least three levels, presented as an indented table with numbering such as 1, 1.1, 1.1.1. Stop when each work package can be estimated with confidence and owned by one person.
  • Avoid gaps and overlaps. A good task list and WBS together make sure every piece of work belongs somewhere, exactly once.
  • Use a WBS dictionary. A short description of each element’s scope, deliverable, owner and acceptance criteria.

The WBS then feeds the schedule (work packages become tasks with durations and dependencies), the budget (each is costed), RACI Charting (each gets an owner), and Earned Value Management (progress is measured against each).

In practice

For the challenge project, the assignment is a WBS of at least three levels in table form, a Gantt chart, and a list of milestones. Teams often discover that their first draft is organized by activity, such as “design” and “test”, rather than by deliverable, such as “amplifier module” and “test report”. The deliverable view makes it far easier to see when something is actually done.

Questions to ask yourself

  • Does my project’s WBS include 100% of the work, including integration, documentation and project management itself?
  • Is each work package small enough that one person can own it and estimate it?
  • Is our WBS organized around deliverables or around departments?

Connections

Sources

[1]
H. Kurstedt and P. Kurstedt, Project Management Handbook. Falls Church, VA, USA: Newport Group, LLC, 2005.