Creating a Work Breakdown Structure — What a Language Model Takes Off Your Plate and What It Doesn't

A work breakdown structure is the one document on a project that everybody demands and almost nobody uses. It is drawn up during planning, signed off, forgotten — and resurfaces when nobody can say any more why a particular piece of work belongs to the project in the first place.

That is precisely what it is for. A work breakdown structure answers a single question: what belongs to this project, and what does not? Everything else — schedules, costs, responsibilities — hangs off that answer.

What a work breakdown structure is

The work breakdown structure (WBS) decomposes an undertaking into ever smaller components until, at the bottom, you have units that can be estimated, assigned and completed. That lowest level is the work package. The German DIN 69901 standard treats the WBS as a planning object in its own right; in practice it is shown as a tree diagram or an indented list. What matters is not the form of presentation but a property that is easy to overlook: completeness.

That property is formalised in the 100% rule, and it is what separates the structure from any old task list: the structure contains all the work of the project — and nothing beyond it. Each level fully represents what sits in the level above it. Follow this rule and you have a robust plan. Ignore it and you have a pretty diagram.

The second point is missed just as often: a work breakdown structure contains deliverables, not activities. "Training materials produced" is a work package. "Deal with training" is not, because nobody can say when it is finished.

The three ways of structuring

The question on which most structures fall over is not how deep, but by what criterion they are broken down.

Deliverable-based structuring divides by sub-results: vehicle → drivetrain, body, electronics. Sensible when the end product's parts come into being independently.

Function-based structuring divides by type of work: analysis, development, testing, rollout. Sensible when specialist departments determine the structure — but it carries the risk that you end up mapping departments rather than results.

Phase-based structuring divides by sequence: preparation, execution, sign-off. The obvious choice, and for exactly that reason the most common mistake. A phase-based structure tells you when something happens, not what is produced — and so it lacks precisely the information the structure exists to provide.

In practice the top level is usually mixed. That is permissible, provided a single criterion is maintained within any one level.

Where a language model genuinely helps

Creating a work breakdown structure is, to a large degree, donkey work: you know the structure, you know the undertaking, and you write it out as a matter of routine. It is exactly this part that a language model takes off your plate.

Concretely, it contributes in three places:

The first draft. From a ten-line project description you get, in one pass, a three-level structure. It is not correct, but it is complete enough to work with — and a draft you correct comes together faster than one you write from scratch.

The completeness check. The more useful application, and the less commonly used one. You feed in your own finished plan and ask: which work packages are typically missing from an undertaking of this kind? Models are good at naming what has been forgotten — migrating legacy data, training the support team, sign-off by the works council. These are the packages that reappear during the project as "we hadn't planned for that".

Rephrasing. Rewriting activities as deliverables is mechanical and tedious. "Carry out testing" becomes "test report signed off". A model does this for forty lines in a single pass.

Where it reliably gets things wrong

A language model has no model of your project. It has a model of what work breakdown structures usually look like. From this follow three errors that occur reliably:

It does not observe the 100% rule. The output looks complete because it is symmetrical — every level has three to five items, everything looks tidy. But symmetry is no proof of completeness. Real projects are asymmetrical: one branch has twelve work packages, the next has two.

It structures by phase unless you stop it. That is the most common structure in the texts it learned from. Give it no criterion and you get preparation/execution/closure — that is, exactly the variant that holds up least well.

It invents the plausible. Work packages that have no substance in your context but sound good. This is harmless as long as someone with subject knowledge reads over it, and expensive when the plan goes into the estimate unchecked.

All three errors have one thing in common: they cannot be spotted from the output. They look like a good plan. That is why, here, the language model is a tool for someone who can judge work breakdown structures — not one that replaces that ability.

An approach that works

1. Decide the structuring criterion yourself, before the model sees anything. That decision is a matter of substance and does not belong in the tool.
2. Give context, not a task. Not "create a work breakdown structure for a CRM rollout", but: scope, stakeholders, what is explicitly out of scope, and the chosen structuring criterion.
3. Check the draft against the 100% rule — by hand, level by level. Do not ask the model whether its own plan is complete.
4. A second pass with the counter-question: what is typically missing from undertakings of this kind? This is where the real gain lies.
5. Cast work packages as deliverables and record, for each package, how you will recognise that it is finished.

The check in four questions

Before the plan leaves your hands:

• Does each level hold all the work of the level above it — no more, no less?
• Does every work package contain a deliverable whose completion can be

verified?

• Is each level structured by one criterion?
• Does every work package have exactly one responsible person?

Four yeses do not mean the plan is right. Four yeses mean it is open to discussion — and that is more than most work breakdown structures can say for themselves.