Skip to content

Lab 07 — Creating a Work Breakdown Structure

At a glance

Learning objectives

By the end of this lab you should be able to:

  1. Decompose scope into a three-level WBS using a consistent basis of decomposition.
  2. Apply the 100% rule and identify gaps and overlaps.
  3. Write a work package small enough to estimate, assign, and verify.
  4. Recognise the difference between a deliverable-oriented WBS and a task list.

Scenario

A regional distribution company is replacing its inventory and supply chain system. The current arrangement is a spreadsheet per warehouse, updated by hand at the end of each shift, plus a nightly telephone reconciliation between three warehouses. Stock discrepancies are discovered at month-end, and the company cannot answer "where is order 4471?" without telephoning someone.

The replacement will:

  • Hold stock levels per item, per location, for four warehouses.
  • Record goods received against purchase orders and goods dispatched against customer orders.
  • Show a real-time view of stock by location, with a history of movements.
  • Calculate reorder points and generate a suggested replenishment list.
  • Export a nightly summary to the company's accounting system.
  • Support barcode scanning at goods-in and goods-out (handheld devices to be supplied by the company).
  • Give warehouse supervisors a mobile view for stock counts.

The scope statement's exclusions: no supplier portal, no customer-facing tracking page, no route optimisation, no integration with the courier companies' systems, and no changes to the accounting system itself.

Delivery facts: three developers, one tester, one part-time business analyst, sixteen weeks. The handheld devices have not yet been purchased. The accounting system's export format is an undocumented fixed-width file that a retiring staff member maintains.

Your role

You are the project manager. Your plan cannot be estimated or scheduled until the scope has been decomposed, and your team has already asked "what does 'the system' actually consist of?"

Project information and assumptions

The scenario is part of the example-project library — read the full description there if you want the wider context.

  • Decompose to three levels at least, and to a fourth level where a work package is still too large to estimate.
  • Work packages should be estimable in the range of roughly 2 to 10 person-days. Say so if one of yours falls outside that range and why.
  • The barcode devices are supplied by the company; treat their arrival as an external dependency.
  • The accounting export file is fixed-width and undocumented; treat its format as a discovered requirement, not a given.
  • Assume you cannot change the accounting system.

Tasks

Task 1 — Choose the basis of decomposition

Decide whether your second level is organised by product component, by project phase, by business function, or by geographic location, and write one paragraph justifying the choice for this project. State one disadvantage of the alternative you rejected.

Then commit to one basis and use it consistently — mixing bases at the same level is the most common WBS defect.

Task 2 — Build the three-level WBS

Produce the WBS as a numbered hierarchy and as a Mermaid diagram. Level 1 is the system; level 2 is your chosen basis; level 3 is the work packages or their parents.

Use decimal numbering (1.0, 1.1, 1.1.1). Give every element a noun-phrase name describing a deliverable, not a verb-phrase describing an activity.

Task 3 — Apply the 100% rule

Check your WBS against the scope statement:

Check Question
Completeness Is every in-scope item represented somewhere?
No extras Is anything present that the scope statement does not authorise?
No overlap Does any element appear twice under different parents?
Parent completeness Does each parent's children add up to exactly the parent's scope?

Record what you found. A WBS that survives a genuine 100% check on the first attempt is unusual — the findings are the valuable part of this task.

Task 4 — Write work packages

For six of your leaf elements, write a work package specification:

Field Content
WBS number and name From your hierarchy
Description What is produced
Acceptance criteria How completion is verified
Estimated effort In person-days, with a basis
Owner role Who is accountable (a role, not a name)
Dependencies What must exist before it starts

Task 5 — Handle the two awkward items

Two items in the scope resist decomposition:

  1. The accounting export — an undocumented fixed-width format maintained by a retiring staff member.
  2. The barcode devices — not yet purchased, and their arrival is outside your control.

For each, write a short paragraph explaining how you will represent it in the WBS, what the associated risk is, and what the work package's acceptance criteria can honestly promise before the unknown is resolved.

Task 6 — Test your WBS for the wrong level

Take one work package you wrote and decompose it one level deeper. Then say whether the extra detail improves your control or merely creates reporting overhead — and justify answers both ways using the 2-to-10 person-day guideline.

Deliverable

  1. One paragraph on the basis of decomposition, with the rejected alternative's disadvantage.
  2. The numbered WBS and a Mermaid diagram of it.
  3. The 100% rule check, including anything it revealed.
  4. Six work package specifications.
  5. The two awkward items handled explicitly.
  6. The one-level-deeper test with your conclusion.

Hints and guidance

  • Deliverables, not tasks. "Stock level service" is a deliverable; "write the stock service" is an activity. Activities come later, in scheduling.
  • The 100% rule is a test, not a formality. If your check finds nothing at all, you probably checked the labels rather than the scope.
  • External dependencies still belong in the WBS. The barcode integration work is yours even though the devices are not.
  • A work package must be verifiable. If you cannot write an acceptance criterion for it, it is not a work package yet.

Self-check criteria

Check How to verify it
One basis of decomposition used at level 2 Every level-2 element is of the same kind
Names are noun phrases Reading the list, no element begins with a verb
100% rule genuinely applied At least one gap, overlap, or unlisted item was found
Six work packages complete All six fields present for each, with effort stated in person-days
Work packages are right-sized Effort estimates fall in the 2–10 person-day range, or the exception is justified
Awkward items are not hidden Both have acceptance criteria that admit what is unknown

Reflection

  1. What did the 100% rule check reveal that you had not noticed while building the WBS?
  2. Where in your WBS did you catch yourself writing an activity instead of a deliverable?
  3. The retiring staff member is not in your WBS but is a real dependency. Where does that belong, and why?
  4. If the barcode devices arrive late, which work packages are affected, and could you have structured the WBS to reduce that exposure?
Model discussion points
  1. Typical findings: a missing "data migration" element from the warehouse spreadsheets, an overlap between "reports" at two levels, or an unlisted element for training and handover.
  2. Usually in the lower levels of a functional area, where the natural description is a sequence of actions.
  3. It belongs in the risk register and as an assumption on the export work package, not as a WBS element — the WBS contains work, not people. But the work package must state that its acceptance criteria cannot be finalised until the format is documented.
  4. The affected packages are typically goods-in, goods-out, and the stock count view. Reducing the exposure means structuring the WBS so the barcode integration is a separable work package behind a manual-entry interface, so that manual operation remains a fallback.

Extension challenge

Rebuild your level 2 on a different basis (for example by phase instead of by component) and compare the two versions against four criteria: estimability, alignment with how work will be assigned, suitability for tracking progress, and how much rework a change to the mobile view would cause. Then state which version you would actually use, and why the answer is not the same for every project.