Work breakdown structure

Why it matters

"Build the website" is impossible to estimate, schedule or assign. "Design the sign-up form", "Write the confirmation email" and "Test the form on three phones" are not. A work breakdown structure (WBS) is how you get from the first to the second. It is the backbone of planning: the schedule, the budget, the risk list and the status report all hang off it. If work is not in the WBS, nobody has planned to do it.

The core idea

A WBS is a hierarchy of deliverables. The top level is the whole project. Each level below splits its parent into smaller pieces, until you reach work packages: chunks of work small enough to estimate with reasonable confidence and assign to one owner.

Three rules make a WBS useful:

1. Deliverable-oriented. Organise by the things you produce (nouns), not by departments or phases. "Sign-up form" rather than "development". Activities (verbs) come later, inside work packages.
2. The 100% rule. Each level must contain 100% of the work of its parent, no more and no less. If testing, training or project management itself is missing, the WBS is incomplete, and those hours will appear as overruns.
3. Mutually exclusive. No piece of work appears twice. If "test the form" sits under both "Sign-up form" and "Testing", it will be counted twice in the budget.

How small is small enough? A common rule of thumb is the 8/80 rule: a work package should take between about 8 and 80 hours of effort. Another is that it fits within one reporting period, so you can say "done" or "not done" at each status check.

A worked example

The food bank sign-up website, broken down to three levels:

1 Volunteer sign-up website
  1.1 Project management
      1.1.1 Planning documents (scope, schedule, risks)
      1.1.2 Weekly status reports
      1.1.3 Closure and lessons learned
  1.2 Requirements and design
      1.2.1 Requirements notes (coordinator, 5 volunteers)
      1.2.2 Wireframes for 4 pages
      1.2.3 Visual design and style guide
  1.3 Public site
      1.3.1 Home and contact pages
      1.3.2 Shift calendar
      1.3.3 Sign-up form with validation
      1.3.4 Confirmation email
  1.4 Coordinator admin
      1.4.1 Add and edit shifts
      1.4.2 CSV export of sign-ups
  1.5 Testing and launch
      1.5.1 Test plan and test runs on 3 phones
      1.5.2 Accessibility check
      1.5.3 Go-live on the existing host
  1.6 Training and handover
      1.6.1 Coordinator guide (2 pages)
      1.6.2 60-minute training session
      1.6.3 Handover notes for the IT volunteer

Notice that project management, testing, training and handover each have their own branch. These are exactly the items beginners leave out.

The numbering (1.3.3) gives every package a unique ID you can use in the schedule, budget and status reports.

The WBS dictionary

For each work package, a short WBS dictionary entry removes ambiguity:

1.3.3 Sign-up form with validation
  Description: form for name, email, phone, shift; shows errors inline.
  Owner:       Priya
  Acceptance:  passes the test plan cases 4-11; works on 3 phones.
  Estimate:    24 hours
  Depends on:  1.2.2 wireframes, 1.3.2 shift calendar

How to build one

1. Start from the scope statement's deliverables; they become level 2.
2. Break each down by asking "what has to exist for this to be done?"
3. Stop when a piece meets the 8/80 rule or can be estimated and owned.
4. Check the 100% rule: read the scope statement again and confirm every deliverable and acceptance criterion is covered, and nothing extra (from the exclusions) has crept in.
5. Review it with the people who will do the work. They know the hidden tasks.

Sticky notes on a wall work very well for a first draft; a spreadsheet, outline document or free mind-mapping tool works for the final version.

WBS and agile

Agile teams use a similar structure: epics break down into user stories, which break down into tasks. The difference is that the lower levels are refined just in time rather than all at the start.

Common mistakes

• Organising by department ("design team", "dev team") instead of deliverables.
• Missing project management, testing, training or handover.
• Going too deep: packages of 30 minutes create a tracking burden.
• Listing work that is out of scope.

Quick recap

• A WBS breaks the project into deliverables, then into work packages you can estimate and assign.
• Follow the 100% rule and keep pieces mutually exclusive.
• Size work packages at roughly 8 to 80 hours; give each an ID, owner and dictionary entry.

Try it

Open the Do tab and build a three-level WBS for your project on sticky notes or in a spreadsheet.