WBS

A Work Breakdown Structure (WBS) is a product-oriented hierarchical decomposition of everything a contract requires. Each element is a discrete piece of scope that a team can describe, schedule, estimate, and later report against. On defense programs the structure normally derives from MIL-STD-881, the DoW standard for work breakdown structures for defense materiel items.

Product-oriented, not task-oriented

This is the distinction people most often get wrong. A WBS decomposes the thing the contract delivers and the effort that produces it. It is not the org chart, and it is not a to-do list. "Airframe" is a WBS element. "Engineering department" is not.

The practical test has two parts. A WBS dictionary entry should describe every element as scope. Every hour and every dollar on the program should land in exactly one element.

What does MIL-STD-881 define?

MIL-STD-881 provides appendices of standard WBS templates by system type. The types include aircraft, ships, space systems, ordnance, and information systems. The standard also defines a set of common elements that recur across program types:

• Integration, assembly, test and checkout.
• Systems engineering.
• Program management.
• System test and evaluation.
• Training.
• Data.
• Peculiar support equipment and common support equipment.
• Operational and site activation.
• Industrial facilities.
• Initial spares and repair parts.

Check which revision your solicitation cites. The standard changes periodically, and a program carries the revision in effect on the date someone wrote it.

The standard element names and numbering are not merely stylistic. They let the government compare your cost structure against the cost structure of every other program, which is precisely why the government asks for them.

Where the WBS appears in a bid

A solicitation may hand you a Contract WBS (CWBS) to at least level three and require your proposal to follow it. Or it may require you to propose one.

Either way the WBS becomes the spine of the cost volume. You write the basis of estimate per WBS element. You build the schedule against WBS elements. On programs with earned value reporting, the control accounts sit on the WBS. If the contract requires a WBS dictionary as a deliverable, it appears as a CDRL line.

The mistake that makes this term matter

The WBS usually gets built by whoever owns the cost volume, under deadline, from the only structure the company has already agreed and written down: itself. Departments become elements. The engineering group gets a number, the logistics group gets a number, and every hour has an obvious home. It is fast, everyone recognizes it, and the cost volume reconciles.

It also produces a structure nobody outside the company can read. The government compares bids and historical programs using standard element names, and a structure organized by department does not contain them. The same structure breaks the first time a subcontractor takes over part of the scope, or the first time the company reorganizes. That rework does not happen during the bid, while it is still cheap. It happens under a contract already in performance.

What goes wrong with a WBS in practice

It mirrors the org chart. Elements named after departments produce a structure that cannot survive a subcontract change or a reorganization. That also makes cost comparison meaningless.

The team builds it after the estimate instead of before it. When the numbers come first and the structure follows, elements overlap. Some scope then gets counted twice, and other scope falls into the gap between two elements.

It does not reconcile to the Statement of Work (SOW). Every SOW paragraph should map to at least one WBS element, and every WBS element should trace to something the contract actually requires. An unmapped SOW paragraph is scope with no price against it. An unmapped WBS element is usually scope you invented.

The team decomposes it too far, or not far enough. Levels below the reporting requirement create administrative burden with no benefit. Too few levels make a variance impossible to diagnose. Decompose to the level at which you can meaningfully manage and report, then stop.

What to do

1. Build the WBS from the SOW and the CDRL before you price anything.
2. Write a one-paragraph dictionary entry for each element.
3. State what each entry covers and, where the boundary is genuinely ambiguous, what it excludes.
4. Confirm that every SOW requirement lands in an element.
5. Confirm that no element holds work the contract does not ask for.

What a WBS is not

A WBS is not a schedule. It carries no dates and no dependencies. It is not an organizational breakdown structure, although teams commonly cross-reference the two to form control accounts.

A contractor WBS is also not automatically the government CWBS. Where the solicitation specifies a CWBS, you may extend it downward. You may not renumber its upper levels.

Silas™ builds a WBS from the shredded SOW and maps each requirement to the element that carries it.