Home›Blog›Work breakdown structure: what it is, and the six admissible splits
FundamentalsBeginner
Published September 6, 2026 · By Vincent KENNEL
Work breakdown structure: what it is, and the six admissible splits
Six bases for splitting a project's work are admissible, and no standard ranks them. So what decides? The answer is older than every standard on the shelf, and it changes what a work breakdown structure is for.
In brief
A work breakdown structure is the hierarchical decomposition of a project's scope into progressively smaller elements, down to the work package, the level at which work is assigned and against which cost and progress are reported. ISO 21511:2018 allows six bases for that split, product, deliverable, result, phase, discipline or location, and ranks none of them.
Most of the trouble with work breakdown structures does not come from building one badly. It comes from not building one at all. Eric Norman, Shelly Brotherton and Robert Fried, three contributors to the PMI practice standard on the subject, report in Work Breakdown Structures (1st edition, Wiley, 2008) that many project managers skip the step entirely and define the work by typing tasks, activities and milestones straight into the scheduling tool. And where a structure does exist, they often find it sitting in a file, unused, which in their judgement makes it worth nothing at all. On a contract project that shortcut has a price, and it is paid months later, at reporting time.
What a work breakdown structure is
ISO 21511:2018, the only ISO standard devoted to this object alone, defines it as the decomposition of the defined scope of a project or programme into progressively lower levels made up of elements of work. PRINCE2 7 (AXELOS, 2023) comes at it from the other end and describes a hierarchy of all the work to be done, sitting between the product breakdown structure and the work packages. The APM Glossary, in its state of 19 August 2026, keeps only the function: the structure defines the total work to be undertaken and provides a frame for the control systems.
Three formulations, and one shared feature that carries the rest of this article: each of them names a purpose. None of them describes a picture of the project.
The bottom of the tree is the work package, and its definition has barely moved in sixty years. The March 1963 glossary that carries the oldest formal definition available to us describes it as the unit of work required to complete a specific job, a report, a design, a piece of hardware, with overall responsibility assigned to a single organisation or individual. The NASA Work Breakdown Structure Handbook (NASA/SP-20250006071, 2025) says almost exactly the same thing.
One boundary is worth setting straight away. The organisational breakdown structure is a different object: it maps the organisation that does the work, not the work itself. It has an article of its own.
The three levels, and where the contract passes
What the structure is for is aggregation. Cost, progress and status climb from the work package towards the project, and the three definitions above already said as much.
Ask how many levels a work breakdown structure should have and the usual answer is three. That answer has a source, and it is narrower than it looks. MIL-STD-881F (2022) names levels 1, 2 and 3 for defence materiel items, and the DOE Work Breakdown Structure Guide (DOE/MA-0295, 1987) states that a project summary structure usually consists of three levels of product. Both are institutional conventions, written for a class of programmes by the bodies that buy them. Neither is a property of the artefact, and nothing in ISO 21511:2018 fixes a number.
What does hold on a contract is a different kind of three. MIL-STD-881F distinguishes the programme structure, held on the government side and unique per programme; the contract structure, where the contractor is deliberately left free to define and manage the elements as it sees fit; and the subcontract structure, whose elements are not to be duplicated in the contract structure above it. The DOE Work Breakdown Structure Handbook (2012) sets out the same three tiers outside defence.
The consequence is the most operational point in this article: the structure received from a customer is not the one built internally, and the boundary between them is exactly where the contract passes. This is not a recent discovery. As early as December 1963, the USAF PERT Volume III manual required a request for proposal to include a work breakdown structure developed as far as the programme was defined.
One further object belongs here, and it is routinely skipped. The dictionary describes and bounds each element. MIL-STD-881F has it prepared first by the government programme manager, then expanded by the contractor as the contract structure develops, which makes it an object held in two hands and therefore a record of how scope was shared. And it is the dictionary, not the structure alone, that bridges to the schedule: ISO 21511:2018 makes the two together the basis for developing the activity list of each element.
Above the work package sits a reporting level that Carl L. Pritchard calls the cost account in How to Build a Work Breakdown Structure (ESI International, 1998), and that most standards now call the control account. It is where the structure meets the organisation, and it belongs to another article.
Where it came from, and what it was built to solve
The oldest formal definition available to us dates from March 1963, in the glossary of Supplement No. 1 to the DoD and NASA Guide, PERT COST. It calls the structure "a family tree subdivision of a program", beginning with the end objectives and subdividing them into successively smaller end items. The same entry lists what it is for: defining the work to be accomplished, constructing a network plan, and summarising cost and schedule status for progressively higher levels of management.
The mechanism is the interesting part. USAF PERT Volume III, December 1963, gives every end-item subdivision a summary number and every work package a charge number, and it is against those numbers that estimates are made and actual costs accumulated. The structure was born as an accounting frame, not as a diagram to comment on. Everything in this article follows from that single fact.
Standardisation came five years later. The cover page of MIL-STD-881A (1975) records that it supersedes MIL-STD-881 of 1 November 1968, which makes that the date the US Department of Defense standardised the object, not the date anyone invented it. Sharon and Dori (2012) corroborate the year from outside the institution and add a qualification worth keeping: what was issued in 1968 was a product-oriented family tree.
The vocabulary has been remarkably stable since. The family tree image appears in March 1963, again in the Project Management Body of Knowledge published by PMI in 1987, again in MIL-STD-881F (2022), and again in the NASA handbook of 2025.
One thing cannot be said, and it is said often: the structure was not born in 1957 with PERT. The founding PERT paper, Malcolm, Roseboom, Clark and Fazar (1959), does not contain the term anywhere in its twenty-five pages, nor work package, nor end item.
The most honest sentence in the whole corpus is sixty-two years old. USAF PERT Volume I (1963) conceded that networks can readily be built without a work breakdown structure, and said only what such networks are likely to lose: completeness, and consistency with the objectives of the programme. It states what is given up, and stops there.
How the split gets decided
There is no single correct split, and the standard says so. ISO 21511:2018 admits six bases: product, deliverable, result, phase, discipline and location. It ranks none of them, and adds that the concept is flexible and should be adapted to the requirements of the project or programme.
Figure 1: two breakdowns of the same project
What the figure shows is established by two independent sources. Norman, Brotherton and Fried (2008) observe that two representations of the same project contain the same work packages at the lowest level, and that the difference lies entirely in how the higher-level elements are organised. Pritchard (1998) makes the same observation from the other side: work relating to similar deliverables can stretch across several subsets of the structure, and the practical cost is that a single component becomes much harder to track.
From there comes the criterion, and this part is a reading rather than a quotation. If the structure exists in order to aggregate, then it should be split according to what will have to be aggregated and reported. No standard states it in those terms. It follows from two things the sources do establish, the function and the origin, and it is offered as a reading rather than as a finding.
Two rules make a split checkable rather than a matter of taste. The GAO Schedule Assessment Guide (GAO-16-89G, 2015) requires every schedule activity to trace to an element and every element to carry at least one activity, and it allows only one structure per programme. ISO 21511:2018 requires each parent element to have either no children or at least two, which is how the standard enforces the 100 percent rule: a level of decomposition represents all of the work of the element above it. Norman, Brotherton and Fried give the neatest demonstration of the two-child requirement: a parent with a single child would be a duplicate of that child, so it would serve no purpose at all.
Finally, the orientation of the split is not a property of the artefact either. It has moved. The Project Management Body of Knowledge published by PMI in 1987 defined the structure, in its glossary, as "a task-oriented family tree of activities". The PMBOK Guide of 1996 made it deliverable-oriented instead, a shift that Pritchard called radical two years later. In the PMBOK Guide, 5th edition (2013), the adjective disappears from the glossary altogether, in a wording the 7th edition (2021) still carries. A practitioner had already drawn the conclusion in 1998: choosing between the two approaches is the project manager's job, and it is decided in the interest of the project.
One divergence is worth knowing before it bites. Splitting by phase is admitted by ISO 21511:2018 and tooled by Pritchard, but forbidden by MIL-STD-881F on the grounds that "The WBS is a life cycle structure". On a defence programme, a phase-based structure will be read as a mistake rather than as a legitimate alternative.
And a guard-rail, from that same 1998 book: a structure has become too detailed when it starts telling team members to move their left foot, then their right.
A work breakdown structure is not a schedule. It is a hierarchy of the work to be performed and of the subsets of that work, and Pritchard (1998) closes the point in five words: "It is not a schedule." Tasks, activities and milestones belong to the schedule, not to the structure. Building the schedule first is precisely the shortcut described at the top of this article.
The test to run before you split
Before opening any tool, write down what the project will have to report on: the deliverables whose cost will have to be defended, the milestones whose progress will have to be shown, the elements a customer will ask about by name. That list is the specification of the split. Build the structure so that each of those questions lands on a single element instead of being reassembled from four, and the reporting that follows becomes arithmetic rather than archaeology.
Stop guessing. See the real impact.
Frequently asked questions
Q.What is the difference between a work breakdown structure and a product breakdown structure?
The referentials do not agree. PRINCE2 7 derives the work structure from a product structure that comes first, while MIL-STD-881F treats the work structure as itself product-oriented. ISO 21511:2018 declines to settle it and notes that the two names are sometimes used for the same thing.
Q.Is a work breakdown structure mandatory?
It depends who is asking. PRINCE2 7 says a very simple project delivering a single work package does not need one. MIL-STD-881F makes it compulsory on defence acquisition programmes, the DOE requires it on major projects, and the GAO audits it.
Q.What is the WBS dictionary for?
It records what each element covers and where it stops, so that two people reading the same box mean the same work. ISO 21511:2018 lists thirteen headings for each element's entry, which is what makes the dictionary usable rather than decorative.
DoD - MIL-STD-881A - Work Breakdown Structures for Defense Materiel Items - Revision A, 1975
DoD - USAF PERT Volume III - PERT Cost System Description Manual - Advance Copy for AFSC Implementation, December 1963
DoD - USAF PERT Volume I - PERT-Time System Description Manual - Advance Copy for AFSC Implementation, September 1963
DoD - MIL-STD-881F - Work Breakdown Structures for Defense Materiel Items - Revision F, 2022
DOE - Work Breakdown Structure Handbook - Edition of 16 August 2012
DOE - Work Breakdown Structure Guide (DOE/MA-0295) - Edition of 6 February 1987
ESI International - Carl L. Pritchard - How to Build a Work Breakdown Structure: The Cornerstone of Project Management - 1998
GAO - GAO-16-89G - Schedule Assessment Guide - Best Practices for Project Schedules - 2015
IFAC - Amira Sharon, Dov Dori - A Model-Based Approach for Planning Work Breakdown Structures of Complex Systems Projects - 2012
INFORMS - D. G. Malcolm, J. H. Roseboom, C. E. Clark, W. Fazar - Application of a Technique for Research and Development Program Evaluation - vol. 7, no. 5, 1959
ISO - ISO 21511:2018 - Organigrammes des tâches en management de projet et de programme - 1st edition, 2018
John Wiley & Sons - Eric S. Norman, Shelly A. Brotherton, Robert T. Fried - Work Breakdown Structures - The Foundation for Project Management Excellence - 1st edition, 2008
NASA - NASA/SP-20250006071 - Work Breakdown Structure (WBS) Handbook - revision E, 2025
PERT Coordinating Group - Supplement No. 1 to DoD and NASA Guide, PERT COST - Output Reports - 1963
PMI - Project Management Body of Knowledge - 1987
PMI - A Guide to the Project Management Body of Knowledge (PMBOK Guide) - 1996 Edition - 1996
PMI - A Guide to the Project Management Body of Knowledge (PMBOK Guide) - 7th Edition - 2021
PMI - A Guide to the Project Management Body of Knowledge (PMBOK Guide) - 5th Edition - 2013
