The History of the Work Breakdown Structure

By Victor Hoang · Updated Oct 24, 2026

Picture 1960 and Cold War scale. The US government was buying missiles, aircraft and spacecraft. Each contractor reported cost and schedule in its own format. A manager in Washington could not add the numbers up. The numbers described different things.

The work breakdown structure (WBS) took its modern form between 1957 and 1962 inside the US Navy's PERT program and the Department of Defense (DoD) and NASA PERT/COST guide. The DoD turned it into a standard on 1 November 1968 as MIL-STD-881. The throughline is a plain one. Managers who could not see what a program contained could not price it, schedule it or hold anyone to it. So they drew it as a tree.

Those contractors numbered in the hundreds. This article follows how a tree of deliverables fixed that, who built it, and what it still does for a project today. For the working method, see the guide to the work breakdown structure. For the wider field, see the history of project management.

Timeline at a Glance

Dates separate the earlier practices from the named method.

The Divided Work (antiquity-1956)

Builders and bookkeepers split jobs long before anyone drew a tree

Pyramid builders worked in named crews with assigned quantities, as our piece on ancient megaprojects shows. They divided a huge job among groups. They did not draw a hierarchy of deliverables and call it a plan, so this is a precursor of the WBS and not the method itself. The named method needed several ingredients that arrived much later.

The first ingredient is the division of a job into operations. In The Wealth of Nations (1776), Adam Smith describes a pin factory where the making of a pin is divided into about eighteen distinct operations, and where ten men together made upwards of forty-eight thousand pins a day. Smith was writing about specialization, not planning. But the idea that a job is a list of parts, each with an owner, sits underneath every breakdown structure.

The second ingredient is cost classification. In their 1909 treatise on cost keeping, Gillette and Dana tell contractors to build the foreman's daily report around the items on which the unit contract prices are based, to divide each into its operations, and then to divide each operation by class of workman. Excavation, for example, splits into loosening, loading, transporting and dumping. The book is dedicated to Frederick Taylor. The history of the WBS from Mosaic Project Services treats cost engineering as the direct antecedent of the WBS, and points to US government accounting and construction reports of the 1930s as close relatives. The paper's conclusion is cautious: nobody can know what the PERT designers had seen, but the WBS looks like an evolution of earlier US government practice and not a break from it.

The new problem was that all of this lived inside one contractor's books. Nothing let a buyer compare a missile program run by one company with a related program run by another. Cost trees were local, and so were the names of the branches.

What this means for teams today: if your plan is a list of tasks with no parent structure, you are at the 1909 stage. You can price the pieces, but nobody can say what the pieces add up to.

The Polaris Tree (1957-1961)

A Navy missile program breaks the system into components

Picture the Navy's Special Projects Office in 1958, coordinating a submarine-launched missile with thousands of suppliers. PERT, the network method built for Polaris, was published in Operations Research in 1959 by Malcolm, Roseboom, Clark and Fazar. Mosaic's history notes that PERT organized its activities into product-oriented categories from the start, with a figure in the 1959 paper showing a breakdown into systems, subsystems and components. Its stated purpose was to give senior management a summary view backed by detailed analysis. The team did not use the phrase "work breakdown structure" in that paper. For the network side of the story, see the history of PERT.

A second thread ran through the Air Force. Mosaic's history reports that Lt Gen Hans Driessnack, then at the Air Force Institute of Technology, read H. B. Maynard's Industrial Engineering Handbook (1956) in 1959. He took from it the idea of a cost index tied to a performance plan, and he later extended it, in the PERT/COST work, to break a product into controllable elements. Driessnack's own account, in an Air Force oral history published in 1987, describes the aim: a standard breakdown "for an airplane" with an airframe, propulsion, ground equipment, training and data, which became the line items of the contract.

The term itself shows up in print by the end of this period. Mosaic's history says its precise origin is unclear but that it appears to have been in common use by 1961, when a General Electric article by Warren Munson, "A Controlled Experiment in PERTing Costs," printed a sample WBS for a Fleet Ballistic Missile training facility. It takes that detail from Gregory Haugan's 2008 book on the subject, so treat the 1961 date as the earliest documented use rather than a coinage.

The point of this era was not a diagram. It was a decision to organize cost around the product, not the department. That choice made one list serve the budget, the contract and the schedule, and it created the next problem: someone had to write the list down for everyone.

What this means for teams today: build the tree around what you deliver, not around who does the work. Departments change. The deliverables stay put.

The Guide Years (1962-1968)

A joint DoD and NASA guide gives the structure its rules

In 1962 the formalizing came in a rush, and Mosaic's history lists the documents in order. The Air Force Systems Command PERT handbook came out in January. The DoD and NASA PERT/COST System Design guide followed in June, describing the system and the use of a WBS. NASA's PERT and Companion Cost System Handbook arrived in October, stressing that the WBS was a top-down structure. It says the description of the WBS in those papers has stayed essentially the same to the present day.

The documents give a clear picture of what the WBS was for. The March 1963 Supplement No. 1 defines a summary item as an item in the work breakdown structure and a work package as the unit of work needed to complete a job such as a report, a design, a piece of hardware or a service. It says the cost reports are prepared at several levels of the structure, and that a cost category can be tracked without distorting the WBS itself. The September 1963 USAF PERT-TIME manual adds the schedule side. Its text says a top-down approach is used to guide planning, and warns that networks built without a WBS may be incomplete or inconsistent with program objectives. It also calls the WBS a vertical framework for networks, with a sequence of milestones as the horizontal one.

Driessnack's oral history gives a human scene from this period. He recalls a meeting of the DOD PERT Cost Group around 1964-65 where an Army major presented a main battle tank program, built with West Germany and written in two languages. The tank was broken into components down to the part, and, in Driessnack's words, you controlled it, and reported it, all against a single WBS. He also says the Air Force pushed this "universal breakdown structure" to tie funding requests, cost estimates and cost performance to the same structure. In his account that work became a military standard published by the Pentagon's research and engineering office. That standard is MIL-STD-881, issued 1 November 1968.

The new problem was uniformity. A standard tree for aircraft would not fit a ship or a satellite. The answer, in later editions, was a common top-level template plus appendices for each type of equipment.

What this means for teams today: a structure is only useful if every report uses it. Pick one breakdown and make the budget, the schedule and the status report all hang from it.

The Standards Age (1968-2000s)

The Pentagon revises, NASA adopts, civilian bodies follow

MIL-STD-881 did not stand still. Mosaic's history and the standards register show a long run of editions: 881A in April 1975, 881B in March 1993, and 881C on 3 October 2011, which superseded both 881B and a handbook edition from 2005. The register lists D in April 2018 and E in October 2020 as later versions. The standard has stayed a defense document, but its logic reached well beyond defense.

NASA wrote its own rules. Its WBS Handbook of January 2010 describes a WBS as a "product-oriented family tree" that identifies the hardware, software, services and other deliverables needed to reach a project objective. Its review checklist asks whether WBS elements are predominantly product-oriented, not functional or organizational, and whether the structure covers 100 percent of the scope. It states that work not in the project WBS should not be considered part of the project. The agency issued a revised handbook in November 2021.

Civilian standards came next. Mosaic's history lists the PMI Practice Standard for Work Breakdown Structures in 2001, after the WBS had been a core part of the PMBOK Guide for years, and ISO 21511 on WBS for projects and programmes in 2018. Mosaic's white paper on the method states the 100 percent rule as: the children of a parent must describe the same amount of work as the parent, in more detail. It also notes that the standard's usual shape has four to six levels, ending in work packages.

Two arguments run through this era. One is whether the tree is of products or of work. PRINCE2 uses a product breakdown structure, and Mosaic says the practical difference is small as long as the structure includes project management and similar work, not only the physical product. The other is cost. Putting costs on the same tree let earned value work, a thread covered in the history of earned value management. It also let a tree built for a rocket be copied, badly, onto a website redesign.

What this means for teams today: check your tree against the 100 percent test. If a deliverable can be missing, or can sit under two parents, the tree is a list.

The Backlog Descendant (2001-present)

Agile teams keep the decomposition and drop the freeze

This era overlaps the last one: the PMI standard and the NASA handbook were both published while agile methods were growing up. The turning point is the 2001 Agile Manifesto, which pushed teams away from detailed plans fixed up front. A WBS is a complete plan at one moment in time. Agile work needed a version that could change weekly.

The 2020 Scrum Guide calls the product backlog an "emergent, ordered list" of what is needed to improve the product, and defines refinement as breaking down and further defining items into smaller, more precise ones. That is decomposition again, done a little at a time. Our own reading, not published research, is that the agile backlog is a descendant of the WBS: epics, features and stories are branches of a tree that the team grows only as far as the next few weeks need. For the mechanics, see the guides to epics, features and stories and the product backlog. Other people have drawn that link and others reject it, so treat it as an interpretation.

What the backlog gives up is the completeness test. A WBS answers "is all the work here?" A backlog answers "what should we do next?" Teams that run large agile programs often need both questions answered, which is why the hybrid methods in our evolution of project management methodologies keep a scope tree on top and a backlog below.

What this means for teams today: use the tree to see the whole job and the backlog to run it. Keep the top two levels stable, and let the lower levels change as you learn.

Key People

Key Facts

• The DoD and NASA PERT/COST guide was published in June 1962 and described the WBS approach.
• MIL-STD-881 was issued on 1 November 1968, according to Mosaic's history of the WBS.
• MIL-STD-881A is dated 25 April 1975; MIL-STD-881C is dated 3 October 2011.
• NASA's WBS Handbook dates to January 2010 and describes the WBS as a product-oriented family tree.
• Smith's pin factory used about eighteen operations and made upwards of 48,000 pins a day with ten men.
• The Scrum Guide defines refinement as breaking Product Backlog items into smaller, more precise items.

The Pattern Behind the History

This is our synthesis, not published research. Five points repeat in the history of the WBS:

• Scale forces structure. Each leap in the size of the job, from pin factories to missile programs, produced a more formal breakdown.
• The product comes before the department. Cost trees were built around deliverables so that budgets, contracts and schedules could share one list.
• Government buyers write the standard. The method spread because a customer demanded a common format, then the format outlived the customer's first need.
• Completeness is the lasting idea. Every era restates the same test: all the work is in the tree, and nothing is in it twice.
• Every era loosens the plan. Fixed trees gave way to ones refined step by step, which is where the agile backlog fits.

What It Teaches Teams Today

• Start from deliverables. Ask what the project will hand over before asking who will do what.
• Test for completeness. At each level the parts should equal the parent: nothing missing and nothing duplicated. Work that never made it into the tree is also work nobody weighed for risk, a thread picked up in the history of project risk management.
• Hang everything from one tree. Budget, schedule and status are easier to trust when they share a structure. The same thread runs through the history of the Gantt chart and the history of the critical path method.
• Refine as you learn. Keep the upper levels fixed and let the lower ones change. That is the working compromise between the 1962 tree and the 2020 backlog.
• Know the lineage. For the full sweep of the field, see the project management timeline.