How to build a work breakdown structure (WBS), with an example

What a WBS is, and what it is not

The WBS is a map of everything the project must produce, organised as a tree. The top is the project. The next level holds the major deliverables or phases. The lowest level holds work packages: pieces of work with a clear output, a single owner, a cost estimate and a duration.

It is not a schedule. A WBS has no dates and no sequence; it answers "what", not "when". It is also not an organisation chart or a list of departments. Once the WBS is agreed, you break each work package into activities, link them with dependencies and get a schedule. The WBS also becomes the structure for your budget and for progress reporting, so time spent on it pays back throughout the project.

Four rules for a good work breakdown structure

1. The 100% rule. The children of any element must cover 100% of that element's scope, no more and no less. If it is not in the WBS, it is not in the project. Project management itself (meetings, reporting) is work too, so give it its own branch.
2. Deliverables, not activities. Name items with nouns ("Network installed", "Training material"), not verbs. Activities come later, under each work package.
3. No overlap. Each piece of work appears once. If two branches both include "testing", costs get counted twice and nobody is sure who owns it.
4. Stop at a manageable size. A common rule of thumb is that a work package takes between about 8 and 80 hours of effort, or fits within one reporting period. Stop splitting when further detail would not change how you estimate, assign or track the work.

How to build a WBS step by step

1. Start from the charter. Take the scope statement and the "out of scope" list from the project charter.
2. Choose the level 2 logic. Split by major deliverable (website, content, launch) or by phase (design, build, test). Deliverables usually give a cleaner tree; phases suit work that is strongly sequential. Do not mix both at the same level.
3. Decompose with the people who do the work. A one-hour workshop with sticky notes or a shared list beats a project manager guessing alone.
4. Number every element. Use outline numbers (1, 1.1, 1.1.1) so every item has a stable code you can use in the budget, schedule and reports.
5. Check the 100% rule at each level. For every parent, ask: if all the children were finished, would the parent be finished?
6. Write a WBS dictionary entry for each work package (see below), then estimate and assign owners.

WBS example: a company website relaunch

Here is a deliverable-based WBS for relaunching a company website in two languages. Level 2 has five branches, including project management.

• 1 Website relaunch
  • 1.1 Project management
    • 1.1.1 Charter and plan
    • 1.1.2 Status reports
    • 1.1.3 Closure and lessons learned
  • 1.2 Design
    • 1.2.1 Site map and page templates
    • 1.2.2 Visual design (left-to-right and right-to-left layouts)
    • 1.2.3 Design approval
  • 1.3 Content
    • 1.3.1 English page copy
    • 1.3.2 Arabic page copy
    • 1.3.3 Images and media
  • 1.4 Build
    • 1.4.1 Page templates built
    • 1.4.2 Contact and lead forms
    • 1.4.3 Redirects from old pages
    • 1.4.4 Testing and fixes
  • 1.5 Launch
    • 1.5.1 Go-live checklist
    • 1.5.2 Staff training
    • 1.5.3 Post-launch monitoring (two weeks)

That is 16 work packages. If the budget is $48,000 and you estimate each work package, the budget rolls up the same tree: for example 1.3 Content = 1.3.1 ($4,000) + 1.3.2 ($4,000) + 1.3.3 ($2,500) = $10,500. When the content branch overruns, you see it at the right level instead of in one total.

The WBS dictionary

A one-line name is rarely enough to avoid arguments later. The WBS dictionary adds a short entry for each work package:

Field	Example for 1.3.2 Arabic page copy
Description	Arabic copy for all 24 pages, written natively, not machine translated
Acceptance criteria	Reviewed by the marketing lead; matches approved English page structure
Owner	Arabic content writer
Estimate	$4,000; 15 working days
Depends on	1.2.1 Site map and page templates

From WBS to schedule and budget

Once the WBS is agreed, three things hang off it. First, the schedule: list the activities needed for each work package (for 1.4.3 Redirects: map old URLs, configure redirects, test them), estimate durations and link them with dependencies. Second, the budget: estimate each work package and let the totals roll up the tree, keeping contingency as a separate line. Third, responsibility: give every work package one owner, which is the starting point for a RACI matrix.

Where an estimate is uncertain, use three numbers (optimistic, most likely, pessimistic) instead of one. With PERT, the expected value is (O + 4M + P) / 6. For a work package estimated at 10, 15 and 26 days, that gives (10 + 60 + 26) / 6 = 16 days.

Common WBS mistakes

• Turning the WBS into a to-do list. Hundreds of tiny tasks make the tree unreadable. Keep activities in the schedule, under work packages.
• Forgetting the hidden work. Project management, testing, training, handover and post-launch support are often missing, then appear as overruns.
• Organising by department. "IT tasks" and "Marketing tasks" branches hide deliverables that need both.
• Uneven depth without reason. It is fine for one branch to go deeper if it is riskier, but not because one person enjoyed detail.
• Never updating it. An approved change request that adds scope should add or change a work package.

How to do this in Critova

In a Critova controls project, enter your work packages and activities in the editable activity grid, pick predecessors by name, and the critical path scheduler calculates dates, total float and free float with a forward and backward pass. If your WBS already lives in MS Project XML, Primavera XER or Excel, import it with a preview before anything is created. For the next step after the WBS, the critical path method guide explains how sequencing turns the tree into a schedule.