Work breakdown structure (WBS)

From CEOpedia
Work breakdown structure (WBS)
See also


Work breakdown structure (WBS) - is a deliverable-oriented, hierarchical decomposition of the total scope of work that a project team has to carry out in order to meet the project objectives and produce the required deliverables. That is, in substance, how the Project Management Institute defines it in the PMBOK Guide and in its separate practice standard devoted to the subject[1]. NASA puts it more visually: "A WBS is a product-oriented family tree that identifies the hardware, software, services, and all other deliverables required to achieve an end project objective"[2].

The idea is old and almost embarrassingly simple. Take the whole project, split it into a handful of major pieces, split each of those again, and keep going until every piece is small enough to estimate, schedule, assign to someone and check off when it's done. The lowest pieces are called work packages. Everything else in project management (the schedule, the budget, the responsibility chart, progress reporting) hangs on that tree. Get the tree wrong and the rest wobbles.

History

The WBS grew out of American defence and space programmes. PERT, introduced for the Polaris missile programme in the late 1950s, already grouped tasks by product, even though nobody called it a work breakdown structure yet. In June 1962 the Department of Defense, NASA and the aerospace industry published the DOD and NASA Guide: PERT/COST Systems Design, which described the approach and is usually cited as the first formal treatment of the WBS. For the rest of the decade contractors used wildly different structures: some followed their own functional departments, some contract phases, some whatever they liked.

The Pentagon standardised things in 1968 with MIL-STD-881, Work Breakdown Structures for Defense Materiel Items. It has been revised many times since. The official ASSIST database lists revision A in April 1975, B in March 1993, C in October 2011, D in April 2018, E in October 2020 and the current revision F, dated 13 May 2022[3]. Revision F contains standard templates for aircraft, ships, missiles, space systems, software and other commodity types, so two programmes of the same kind report cost data in the same shape.

Outside government the concept spread through construction, engineering and IT. PMI later issued a dedicated Practice Standard for Work Breakdown Structures; its third edition (2019) extends the method to iterative, incremental and agile life cycles[1].

Principles of a good WBS

A handful of rules separate a usable WBS from a decorated to-do list.

The 100% rule

The WBS includes all of the work defined by the project scope, including project management itself, and nothing outside it. At every level, the children of an element add up to 100% of the parent: no more, no less. Norman, Brotherton and Fried treat this as the single most important WBS principle[4]. NASA says the same thing from the other side: "Work scope not contained in the project WBS should not be considered part of the project"[2]. That sentence is gold in a dispute with a client about scope changes.

Mutually exclusive elements

No piece of work appears twice. If "user testing" sits both under Design and under Testing, it will be estimated twice, budgeted twice and, quite possibly, done by nobody, because each team assumes the other has it.

Outcomes, not actions

Elements are named with nouns: Wireframes, Foundation, Training materials. Verbs belong to the activity list that's derived from the WBS later. Planning by deliverables keeps the structure stable when the method of doing the work changes.

Work packages and the 8/80 heuristic

Decomposition stops at the work package: a unit that can be estimated with reasonable confidence, has a clear completion criterion and a single owner. How small? There's no law. A popular rule of thumb, the 8/80 rule, says a work package should take between 8 and 80 hours of effort, or roughly no more than one reporting period. Treat it as a sanity check, not a standard. On a nuclear plant an 80-hour package is trivial; on a three-week marketing campaign it is a quarter of the project.

WBS dictionary

Each element gets a short written description in a companion document, the WBS dictionary: what's included, what isn't, acceptance criteria, responsible person, estimated cost, assumptions. NASA treats the WBS and its dictionary together as mandatory parts of a project's management baseline[5]. Without the dictionary, 1.4.3 Forms means three different things to three different people.

Control accounts

Large projects add one more layer of management. A control account is the point where scope, budget, schedule and a responsible manager meet, and where actual cost is compared with earned value. A control account usually sits one or two levels above the work packages and contains several of them. NASA's handbook lists control account levels among the decisions to be made when the WBS is developed[5].

Types of WBS

Nothing forces one particular shape. Globerson showed back in 1994 that the same project can be broken down in quite different ways, and that the choice changes how people understand and run the job[6]. In practice three patterns dominate:

  • Deliverable-based (product-oriented) WBS - level 2 is made of the main products or components: hull, propulsion, electronics; or for a website: content, design, software. Preferred by PMI, NASA and the DoD.
  • Phase-based WBS - level 2 follows the project life cycle: initiation, design, build, test, closure. Intuitive for teams used to waterfall, and handy for reporting by stage. The risk is that the same product gets chopped across five branches and nobody owns it end to end.
  • Hybrid - phases at level 2, deliverables underneath (or the reverse). Common in construction and IT.

Organisations sometimes confuse the WBS with structures that look similar but answer a different question:

  • the organisational breakdown structure (OBS) shows who does the work;
  • the risk breakdown structure groups what could go wrong;
  • a cost breakdown structure or chart of accounts shows where the money is booked.

Coding scheme

Every element gets a unique code that shows its place in the tree. The usual form is decimal outline numbering: 1 for the whole project, 1.2 for the second level-2 element, 1.2.3 for the third child of 1.2, and so on. The code is not decoration. It becomes the thread that links the schedule, the cost ledger, timesheets, purchase orders and risk register, so the same piece of work can be traced across every system. NASA's financial system, for example, captures costs down to a maximum of seven WBS levels, with level 1 being the whole project and level 2 the major product elements[5].

Codes should be stable. Renumbering half the tree in month four breaks every report that used the old numbers.

Relation to other project documents

The WBS is the bridge between "what we promised" and "how we'll manage it".

  • Scope baseline - in PMI terminology the approved scope statement, WBS and WBS dictionary together form the scope baseline[1]. Changes go through change control, not through quiet edits to the tree.
  • Schedule - work packages are broken into activities, sequenced in an activity network diagram and analysed with the critical path method to produce the project schedule and, once approved, the baseline schedule.
  • Cost estimating - the GAO cost guide places defining the WBS among the first steps of a credible cost estimate, because it guarantees that no cost element is missed or counted twice[7]. Early on, upper levels may carry only a rough order of magnitude figure; bottom-up estimates of work packages replace it later and roll up into the project budget.
  • Responsibility - crossing the WBS with the OBS gives a responsibility matrix (RACI chart): each work package gets exactly one accountable owner.
  • Earned value - each work package has a budget and a planned date, which gives planned value; completed packages earn their budget, and timesheets coded to the WBS supply actual cost[8].

Example of a work breakdown structure

A hypothetical example. A small accounting firm wants a new website: about 25 pages, an online booking form, a modern design. An agency plans the job with a deliverable-based WBS and a blended rate of €50 per hour.

Code WBS element Effort (h) Cost (€)
1 Company website 579 28,950
1.1 Project management 60 3,000
1.1.1 Project plan and kickoff 24 1,200
1.1.2 Status meetings and reporting 36 1,800
1.2 Content 127 6,350
1.2.1 Requirements workshop 30 1,500
1.2.2 Sitemap and content inventory 22 1,100
1.2.3 Copywriting (25 pages) 75 3,750
1.3 Design 150 7,500
1.3.1 Wireframes 48 2,400
1.3.2 Visual design (home page and 4 templates) 72 3,600
1.3.3 Photo shoot and image selection 30 1,500
1.4 Software 172 8,600
1.4.1 Theme build 56 2,800
1.4.2 CMS configuration and plugins 40 2,000
1.4.3 Forms and booking integration 32 1,600
1.4.4 Content migration 44 2,200
1.5 Launch 70 3,500
1.5.1 Browser, mobile and accessibility testing 38 1,900
1.5.2 Go-live and redirects 18 900
1.5.3 Staff training 14 700

Check the roll-up. 3,000 + 6,350 + 7,500 + 8,600 + 3,500 = €28,950. Each level-2 total equals the sum of its children, which is the 100% rule in arithmetic form. Software is the biggest branch (29.7% of the budget), design comes next (25.9%), content third (21.9%), launch at 12.1% and project management at 10.4%.

What about the 8/80 heuristic? The first draft had a single package, Theme and CMS, at 96 hours. Too big to track weekly. The planner split it into 1.4.1 (56 h) and 1.4.2 (40 h). Same 96 hours, two owners, two clear finish lines. Now every package falls between 14 and 75 hours.

Using the WBS for earned value

At the end of week 6 the plan says packages 1.1.1, 1.2.1-1.2.3 and 1.3.1-1.3.3 should be finished, and 1.1.2 half done. Using a simple 50/50 rule for work in progress:

  • Planned value: 1,200 + 1,500 + 1,100 + 3,750 + 2,400 + 3,600 + 1,500 + 0.5 × 1,800 = €15,950
  • In reality the photo shoot hasn't started and visual design is only half done, so earned value = 1,200 + 1,500 + 1,100 + 3,750 + 2,400 + 0.5 × 3,600 + 0.5 × 1,800 = €12,650
  • Timesheets coded to the WBS show actual cost of €14,000.

\[ SV = EV - PV = 12\,650 - 15\,950 = -3\,300 \]

\[ CV = EV - AC = 12\,650 - 14\,000 = -1\,350 \]

The schedule performance index is 12,650 / 15,950 ≈ 0.79 and the cost performance index 12,650 / 14,000 ≈ 0.90. Behind schedule, over budget. And because everything is coded, the manager can see exactly where: branch 1.3, Design. None of that works without a WBS. More on the arithmetic in earned value calculation.

How to create a WBS

  1. Start from the project charter, the scope statement and the requirements. Know what "done" looks like before splitting anything.
  2. Write the project name as level 1.
  3. Choose the level-2 logic: deliverables, phases or a mix. Add project management as its own branch, otherwise it disappears from the budget.
  4. Decompose each element into its components. Ask "what does this consist of?", not "what do we do first?".
  5. Stop at the work package when the piece can be estimated, scheduled, assigned to one owner and verified. Check against the 8/80 heuristic or your reporting period.
  6. Apply the 100% rule at every level and look for overlaps.
  7. Assign codes and write the WBS dictionary.
  8. Review with the people who will do the work. A WBS drawn up by the project manager alone tends to miss whatever the specialists know and the manager doesn't.
  9. Baseline it and put it under change control.

Software helps (MS Project, spreadsheet outlines, mind-mapping tools), but a whiteboard and sticky notes still work surprisingly well for the first draft.

Advantages of the WBS

  • Makes the full scope visible, so forgotten work surfaces during planning rather than in month five.
  • Gives a common reference for client, team, finance and subcontractors. One code, one meaning.
  • Bottom-up estimates are more accurate than a single top-down guess, and the roll-up shows where money goes.
  • Each package has an owner, so accountability is clear.
  • Forms the basis for scheduling, risk identification (risks can be attached to specific elements), procurement and cost management.
  • Allows progress measurement by deliverable and earned value reporting.
  • Provides a defence against scope creep: if it isn't in the WBS, it's a change request.
  • Reusable. Templates from past projects speed up planning of similar ones, which is exactly why MIL-STD-881 exists.

Limitations and common mistakes

  • Turning the WBS into an activity list - verbs everywhere, hundreds of tiny tasks, and the structure becomes a schedule in disguise. It then has to be rewritten every time the method changes.
  • Mirroring the org chart - branches named after departments ("Marketing", "IT", "Legal") hide cross-department deliverables and invite turf wars.
  • Too deep or too shallow - excessive decomposition creates reporting overhead with no added control; too little leaves packages so big nobody can estimate them.
  • Breaking the 100% rule - missing project management, testing, training, documentation or handover.
  • No WBS dictionary - ambiguous element names cause double counting or gaps.
  • Freezing it too early - in research or agile projects the lower levels can't be known up front. Rolling-wave planning (detail only the near-term work) is the usual compromise; PMI's third edition of the practice standard addresses agile cases specifically[1].
  • Treating it as paperwork - a WBS drawn once for the kickoff deck and never linked to costs or timesheets delivers none of the control benefits.

Related approaches

The product breakdown structure used in PRINCE2 lists products only, without the work. In agile teams a hierarchy of epics, features and user stories does a similar job, though without the strict 100% discipline. The OBS, RBS and resource breakdown structures are companions rather than substitutes. Within the planning cycle described in the project planning process, the WBS sits right after scope definition and before scheduling and budgeting, and every milestone should map to the completion of one or more WBS elements.

References

Footnotes

  1. ↑ Project Management Institute, Practice Standard for Work Breakdown Structures, 3rd edition, 2019
  2. ↑ NASA, NASA Work Breakdown Structure (WBS) Handbook, NASA/SP-2016-3404/REV1, 2018, section 2.1, p.2
  3. ↑ U.S. Department of Defense, MIL-STD-881F, Work Breakdown Structures for Defense Materiel Items, 2022, revision history in the ASSIST database
  4. ↑ Norman E.S., Brotherton S.A., Fried R.T., Work Breakdown Structures: The Foundation for Project Management Excellence, John Wiley & Sons, 2008
  5. ↑ NASA, NASA Work Breakdown Structure (WBS) Handbook, NASA/SP-2016-3404/REV1, 2018, sections 2.2 and 3
  6. ↑ Globerson S., Impact of various work-breakdown structures on project conceptualization, International Journal of Project Management, 1994, pp. 165-171
  7. ↑ U.S. Government Accountability Office, Cost Estimating and Assessment Guide, GAO-20-195G, 2020
  8. ↑ Kerzner H., Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 13th edition, John Wiley & Sons, 2022
Work breakdown structure (WBS) — recommended articles
Work package — Project scope — Control account — Baseline schedule — Matrix of responsibility — Risk breakdown structure — Earned value analysis — Project schedule
Retrieved from CEOpedia