Work Breakdown Structure

A finished WBS on one screen — eight branches, thirty-one work packages, 100%

Most people who look up a work breakdown structure want to see one. Here is a complete one for a common IT project: a retailer replacing its online shop, at a fixed pricefixed priceagreed scope, agreed sumA contract where an agreed scope is delivered for an agreed sum, so the supplier carries the cost of anything that takes longer than planned. That is why fixed-price work comes with the strictest change control: every change to the scope is a commercial event, not just a planning one.All terms, over nine months. Every line is a deliverable — a noun, something that will exist at the end — and carries its code. The percentage beside each branch is its share of the budget, and the eight add up to 100. Later sections cite the lines by code.

1. 1.Project management — 10%

   1. 1.1Project management plan and baseline
   2. 1.2Status reports and steering committee packs
   3. 1.3Risk register and change log
   4. 1.4Supplier contract register

2. 2.Customer accounts — 11%

   1. 2.1Registration and sign-in
   2. 2.2Password reset
   3. 2.3Profile and saved addresses
   4. 2.4Account deletion and data export (GDPRGDPRGeneral Data Protection Regulation — EU personal-data lawThe European regulation governing personal data: what you may collect, on what legal basis, how long you may keep it, and what a person can demand you do with theirs. It applies by where the people are, not by where the company is, which is why it reaches software built anywhere.All terms)

3. 3.Catalogue and search — 14%

   1. 3.1Product pages
   2. 3.2Category navigation and filters
   3. 3.3Search
   4. 3.4Catalogue feed from the ERP

4. 4.Checkout and payments — 18%

   1. 4.1Cart
   2. 4.2Delivery options and prices
   3. 4.3Card payments, one provider
   4. 4.4Order confirmation emails

5. 5.Data migration — 12%

   1. 5.1Customer records
   2. 5.2Order history
   3. 5.3Reconciliation report

6. 6.Platform and operations — 12%

   1. 6.1Environments: development, stagingstagingthe rehearsal environmentA copy of production that changes are tried on before real users meet them. How much it proves depends entirely on how closely it matches production — a staging environment with a tenth of the data, no real traffic and a different config demonstrates that the code starts, and not much more.All terms, production
   2. 6.2Build and deployment pipeline
   3. 6.3Monitoring and alerting
   4. 6.4Backups and a tested restore

7. 7.Quality and acceptance — 13%

   1. 7.1Test strategy
   2. 7.2Performance test report
   3. 7.3Security test report
   4. 7.4User acceptance sign-off

8. 8.Launch and handover — 10%

   1. 8.1Cutover plan and its rehearsal
   2. 8.2Runbooks and support documentation
   3. 8.3Training for customer service
   4. 8.4Hypercare, four weeks after launch

The rules that make a tree a WBS

The idea is older than software projects. In June 1962 the US Department of Defense and NASA published a guide to the PERT/COST system, built for programmes like the Polaris missile, and it organised all the work under a product-oriented tree. In 1968 the military made it a standard, MIL-STD-881, which is still in use in its sixth revision. The reason was the same then as now: when thousands of people spend money on one programme, the only way to know whether the money is buying the product is to tie every hour and every invoice to a piece of that product.

The 100% rule, and its twin

One rule governs the whole structure: the children of any node must add up to exactly 100% of that node — no more, no less. In the WBS above, the eight branches add up to 100% of the project, and the four work packages under branch 4 add up to all of checkout and payments. Nothing extra slips in at a lower level, and nothing quietly goes missing.

The rule has a twin that usually goes unstated: nodes at the same level must not overlap. A piece of work may appear in exactly one place in the tree. Break that and the 100% rule still looks satisfied while the estimate rolled up from the bottom counts the same work twice. Testing is the usual victim: if every feature’s work package includes its tests and branch 7 also has “system testing”, part of the testing is now in the budget twice, and nobody can point at the line where the error is.

Nouns, not verbs

The right-hand column looks reasonable and fails at once. “Write the code” cannot be checked against the 100% rule, cannot be marked done unambiguously, and repeats identically under every branch, so the tree tells you nothing you did not already know. A deliverable can be inspected; an activity can only be reported on. That is also why the activities come later: once the work packages exist, each is broken into the steps that produce it, and those steps go into the schedule, which changes weekly, not into the WBS, which changes only by agreement.

Three ways to organise the second level

The top node is the project. The second level is the one real design decision, because everything below it inherits the choice. There are three legitimate patterns, and mixing them at the same level produces trees nobody can navigate. The WBS above is organised by deliverable, with management, platform, assurance and launch as deliverables in their own right.

• By major deliverable

  Accounts, catalogue, checkout, migration. The default, and the right choice when the product has clearly separable parts that different people can own.

• By phase

  Discovery, design, build, migration, handover. Suits work whose phases really produce different deliverables — a data migration, a certification, a physical rollout.

• By subproject

  Split by supplier, site or system when different organisations deliver different parts. Each subproject then decomposes by its own logic.

Ten checks before anyone signs it

The dictionary — where the scope actually lives

A line in the tree is two to five words, which is nowhere near enough to hold a scope boundary. “Card payments, one provider” could mean a dozen different things to the client and the team. The WBS dictionary is the companion document that says, for each work package, what it includes and excludes, how it will be accepted, who owns it, what it is estimated to cost and what it depends on. It is the part practitioners skip, and it is the part that settles the argument six months later. Here is line 4.3, opened.

The row that does the most work is “Excludes”. Inclusions describe what the team expected to build anyway; exclusions are the cheapest lines anyone will write on the project, because each one is an argument that will not happen. The other row worth reading twice is “Assumptions”. An assumption with an owner and a date is a risk being managed. An assumption that both sides know to be false at signature is not an assumption at all — it is a change requestchange requesta formal request to change something agreedA formal request to change something already agreed — the scope, a design, a live system — which is assessed for its effect on cost, time and risk, and approved or rejected before any work starts. It is how a signed baseline absorbs new information; treated as a failure rather than as information, it becomes the way a plan is defended past its usefulness.Full article →All terms that has been postponed, and the third case below shows what 800 of them cost.

Codes, control accounts and where the money is measured

Every node gets a code: 1, then 1.1, 1.1.2 and so on. It looks like decoration and it is not. The code is the identifier that timesheets, purchase orders, risk entries and change requests all refer to, so the cost actually spent can be added back up the same tree the estimate came down. Once issued, codes are never reused: a deleted branch leaves a gap rather than being renumbered, because the old number is already sitting in six months of invoices.

A control account is the point where scope, budget and actual cost meet and are compared. It sits where a branch of the WBS crosses a unit of the organisation that will do the work, and it has one manager. You do not need one per work package; you need one per piece of the project that somebody is answerable for financially, which is usually a dozen rather than a hundred.

At a control account three numbers are compared each month. Planned value is what the plan said should be finished by now. Earned value is the budget of what actually is finished. Actual cost is what was spent to get there. Earned value below planned value means behind schedule; actual cost above earned value means over budget. The whole method stands or falls on one question: how much of a work package counts as “finished” before it is finished?

How deep — the 8/80 rule, planning packages and rolling waves

The bottom level of a WBS is the work package. The common heuristic is the 8/80 rule: no less than 8 hours of effort and no more than 80. Below 8 you are managing minutiae; above 80 you cannot tell whether a package is on track. A second rule of thumb is often more useful: no work package longer than one reporting period, so that each one is either finished or not finished at every status meeting. Neither number is in the standard; both are conventions that work.

Not every branch needs the same depth. Decompose the risky and unfamiliar parts further than the routine ones: a branch delivered ten times before can stop higher without adding risk. A WBS decomposed to a uniform depth everywhere usually means someone filled in a template rather than thought about where the uncertainty is.

Planning packages and rolling waves

A planning package is the honest placeholder for work that is inside a control account, known to be needed and not yet decomposed. It carries a budget and no detail. Using them is what keeps the 100% rule true for a project whose later months genuinely cannot be planned yet — instead of inventing work packages to fill the gap, which then have to be thrown away. Doing this deliberately over time is rolling wave planning: the next few months are decomposed to work packages, the months after that sit as planning packages, and each planning cycle turns the next wave into detail.

A WBS beside an agile backlog

A WBS assumes the full set of deliverables can be known up front, which is exactly the assumption agile delivery declines to make. That does not make it obsolete. It makes it the wrong tool for a product in discovery and the right one for a defined piece of work inside it — a migration, an integration, a contract with a fixed price.

The two answer different questions. A backlog answers “what should we do next?” and is deliberately never finished. A WBS answers “what did we agree the whole of this is?” and is worthless unless it is complete. When an organisation needs both for the same work — a fixed-price contract delivered in sprints is the usual case — the workable arrangement is a WBS down to the level the contract needs, usually the deliverables and sometimes the work packages, with the backlog living beneath it. Each epicepica large backlog itemA large piece of work that is split into features or stories before anyone builds it, best written as a bet with a hypothesis and a condition that closes it. Its size depends on whose vocabulary is in use — anything above a story in Jira, a portfolio investment with a business case in SAFe — so check before comparing two epics.Full article →All terms then sits under exactly one WBS line, and the dictionary entry for that line is what the epic’s stories must add up to.

Three cases, and the line each one was missing

None of these projects lacked a plan. Each one fixed a price or a date against a scope that had not been defined to the level the commitment needed — and each was told so at the time.

Denver International Airport is the case of a branch added after the trunk was built. Construction began in November 1989. United Airlines engaged BAE Automated Systems in 1991 to build an automated baggage system for its own concourse, and in April 1992 the airport contracted BAE to extend it into one integrated system for the whole airport — a $193 million contract, its terms worked out in three intensive working sessions. The buildings, tunnels and schedule it had to fit were already fixed; the opening date of October 1993 was not moved to make room. The system became the reason the airport opened late, four postponements and 16 months later, on 28 February 1995, with a conventional system installed alongside for about $51 million, according to the US General Accounting Office. United abandoned the automated system in 2005. In WBS terms, one branch was added late, its dependencies on every other branch were assumed rather than re-planned, and the 100% of the project that had been agreed in 1989 was no longer the 100% being built.

Edinburgh’s trams are the case for the “Assumptions” row. On 14 May 2008 the city’s project company signed a fixed-price contract for the infrastructure. Its price rested on Schedule Part 4, a list of 43 pricing assumptions, and the schedule itself said that some of them did not match the facts — the design was unfinished and utility diversions were not complete — so that “the Notified Departure mechanism will apply”: every departure from an assumption became a deemed change, to be paid for. Lord Hardie’s inquiry, which reported on 19 September 2023, found that senior management expected 60 to 100 such departures, made no attempt to estimate their cost, and got about 800. Work stopped in the disputes; a mediation in March 2011 settled them. The line opened on 31 May 2014, almost three years late, from the airport to York Place instead of Newhaven, at a reported £776.7 million against a budget of £545 million for the whole line. The infrastructure works alone went from £238.6 million for the full route to £427.2 million for the shortened one. A fixed price is exactly as fixed as the scope definition under it.

Where it degrades

A WBS rarely fails on the day it is drawn. It fails the first time somebody asks “is this in scope?” and the tree cannot answer. Almost every such failure is one of these:

• Verbs instead of nouns, which makes the 100% rule impossible to check.
• The same work under two branches — testing and design most often — so estimates double count.
• No branch for project management, so a tenth of the budget is spent on work the tree says does not exist.
• A tree with no dictionary, which leaves every scope boundary to memory and goodwill.
• Dictionary entries with inclusions and no exclusions — the half of the boundary that prevents arguments left blank.
• Assumptions that both sides know to be false, signed anyway.
• The second level organised by department, which turns the WBS into an organisation chart.
• Uniform depth everywhere — the signature of a filled-in template rather than analysis.
• Planning packages that never become work packages, so part of the project is never planned at all.
• Decomposition down to tasks, which turns a scope artefact into a schedule that has to be rewritten weekly.

The honest limit is that a WBS can only bound what someone understood. It makes scope visible and checkable; it cannot make an unknown scope known. A tree drawn for a product nobody has used yet will be complete, consistent, signed — and wrong in ways no rule on this page will catch, because the missing branch is the one nobody imagined. That is not an argument against the tree. It is an argument for writing down, in the dictionary, which parts of it are guesses, and for pricing them as guesses.

The practical check takes an hour. Add up the percentages at every node. Read the tree aloud and mark every verb. Look for branch 1 and for the five lines in the opening callout. Count dictionary entries against work packages, and in each entry count the exclusions. And list every assumption with its owner and its date — any assumption without both is a risk nobody is managing.

When to use it

Related pages

• ManagementUser StoriesA user story is a short description of a need from the user’s point of view, written to start a conversation rather than to replace one. The template is the least important part; the skill is slicing work so that every story gives a user something they can actually use, and agreeing before the work starts how everyone will know it is done. The page opens with sixteen stories as teams actually write them, what is wrong with each and the rewrite, then covers card, conversation and confirmation, acceptance criteria and example mapping, nine ways to split a story, story mapping, INVEST, spikes and points, five episodes from the format’s history, and where it degrades.
• ManagementEpics, Features, TasksEpics, features and tasks are the levels of a work hierarchy, from a bet a leader makes for a quarter down to a step an engineer takes today. No standard defines them: the Scrum Guide uses none of the three words, and Jira, Azure DevOps and SAFe each put the epic at a different size. The page opens with every level on one screen and one epic taken down to tasks, then covers where the words come from, what each level is for, writing an epic as a bet with an exit, features, enablers and tasks, why rolled-up estimates mislead, five episodes from the hierarchy’s history, and where it degrades.
• ManagementWaterfallWaterfall is a way of running a project in fixed order, where each phase is finished and signed off before the next one starts. It is usually taught as the outdated thing Agile replaced, which is both unfair and unhelpful: it is the right choice whenever changing your mind late costs more than specifying carefully now. The page opens with every phase on one screen — what it produces, the gate that closes it and what a change costs there — then covers what Royce actually wrote in 1970, each phase in turn, the V-model, six questions that decide between a predictive plan and an iterative one, the hybrids real projects run, five documented cases, and where it degrades.