Work breakdown structures and the scope baseline

The work breakdown structure (WBS) is the backbone of predictive planning. It decomposes the total scope into smaller, manageable pieces that can be estimated, scheduled, assigned, costed and controlled. Almost every later planning output, from the activity list to the cost baseline to earned value reporting, is organized by the WBS. This lesson covers what a WBS is and is not, the 100 % rule, ways to organize and decompose it, work packages, planning packages and control accounts, the WBS dictionary, coding, and how the scope baseline is assembled.

What a WBS is

A WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. Three phrases in that definition matter. Hierarchical: each level breaks the level above into smaller pieces. Total scope: everything in scope appears somewhere, including project management. Deliverables: the WBS is oriented toward outcomes, the things produced, rather than actions.

A WBS is not a schedule. It shows what will be produced, not when or in what order. It is also not an organization chart, although an organizational breakdown structure can be mapped to it to show who is responsible for each element. Activities, durations and dependencies come later, in the schedule. Mixing these up is a common exam distractor: if an answer suggests putting dates or sequence into the WBS, it is wrong.

The 100 % rule

The 100 % rule says the WBS includes all of the work defined by the project scope and nothing else, and that at each level the children together represent 100 % of the parent. Nothing outside the scope should appear, and nothing in scope should be missing. The rule applies to work and, by extension, to costs: if work package estimates are rolled up, the total at each level must equal the sum of its children, with no hidden amounts.

The rule has practical consequences. Project management is work and must appear in the WBS, usually as its own element at the second level. Work that is out of scope, such as the excluded exterior signage, must not appear. If someone adds a cost at a summary level that is not in any work package, the rule is broken and the budget can no longer be traced to deliverables.

Organizing and decomposing

There are several ways to organize the second level. By major deliverables, as in Project Compass. By phases of the life cycle, such as design, build, test and deploy. By subprojects, when parts of the work are contracted out. By geography, for multi-site projects. The choice should reflect how the project will be managed and reported. Mixing bases at the same level, such as some elements by phase and others by deliverable, often leads to overlaps and gaps.

Decomposition continues until the lowest elements, the work packages, can be reliably estimated, scheduled, assigned to a single responsible party and monitored. Common heuristics include the 8/80 rule (a work package should take between 8 and 80 hours of effort) and the reporting period rule (a work package should not span more than one or two reporting periods). These are guides, not laws; a construction work package worth hundreds of thousands of dollars may be fine if it has one responsible contractor and a clear deliverable. Over-decomposition creates administrative burden without improving control.

Decomposition is best done with the team and subject matter experts. The people who will do the work are best placed to identify what is involved, and their involvement builds commitment. A WBS template from a previous similar project, such as the last branch fit-out, is a valuable organizational process asset and can save much time, but it must be checked against this project's scope.

Work packages, planning packages and control accounts

Work packages are the lowest level of the WBS for which cost and duration are estimated and managed. In the schedule, each work package is broken into activities; in the budget, work package estimates are summed into control accounts.

A control account is a management control point where scope, budget, actual cost and schedule are integrated and compared to earned value for performance measurement. Each control account has a control account manager and contains one or more work packages. A control account is placed at a level of the WBS that makes sense for management, often the third level. In Project Compass, the construction contract (2.3) is a control account managed by the facilities lead, and the app (4) is a control account managed by the product lead.

A planning package sits below a control account but above work packages, holding work whose content is known but whose detailed activities are not yet planned. It is the WBS form of rolling wave planning. In Project Compass, transition to operations starts as a planning package; its detailed work packages for training and moving the collection are defined three months before opening, once the staffing plan and collection list are firm.

The WBS dictionary

The WBS dictionary gives detailed information about each WBS element, especially work packages. Typical contents include the code, a description of the work, the responsible organization, schedule milestones, associated activities, resources required, cost estimates, quality requirements, acceptance criteria, technical references and agreement information. The dictionary prevents misunderstandings that a short label in a tree diagram cannot.

Coding and rolling up

Each element has a unique identifier, usually a hierarchical number such as 2.3.1. Codes link the WBS to the schedule, cost accounts, the chart of accounts in the finance system and reports. A clear coding scheme makes it possible to roll up costs and progress from work packages to any level. The example below rolls up the Project Compass work package estimates and checks a draft budget memo against them.

# WBS roll-up and 100 % rule check for Project Compass (invented estimates, $000)
wbs = {
    "1":   ("Project management", None),
    "2":   ("Branch fit-out", None),
    "2.1": ("Design", 120), "2.2": ("Permits", 15), "2.3": ("Construction", 690),
    "2.4": ("Furniture and service desk", 180),
    "3":   ("Self-service technology", None),
    "3.1": ("RFID tagging", 95), "3.2": ("Kiosks and gates", 280),
    "4":   ("Mobile app", None),
    "4.1": ("Discovery and design", 70), "4.2": ("Build and test", 410),
    "5":   ("Transition to operations", None),
    "5.1": ("Training", 60), "5.2": ("Collection move", 55), "5.3": ("Opening", 35),
    "1.1": ("Planning and control", 240), "1.2": ("Reporting and governance", 70),
}
children = {}
for code in wbs:
    if "." in code:
        children.setdefault(code.rsplit(".", 1)[0], []).append(code)

def total(code):
    name, own = wbs[code]
    kids = children.get(code, [])
    if kids:
        if own is not None:
            print(f"  check {code}: has its own estimate and children")
        return sum(total(k) for k in kids)
    return own

top = sorted(c for c in wbs if "." not in c)
for c in top:
    print(f"{c:4s} {wbs[c][0]:28s} {total(c):6,d}")
    for k in sorted(children.get(c, [])):
        print(f"  {k:5s} {wbs[k][0]:26s} {total(k):6,d}")
project = sum(total(c) for c in top)
print(f"Project total (work packages only): {project:,d}")

claimed = {"2": 1010, "3": 375, "4": 480}   # figures in a draft budget memo
for c, v in claimed.items():
    status = "ok" if v == total(c) else f"differs by {v - total(c):+,d}"
    print(f"Memo figure for {c}: {v:,d} -> {status}")

1    Project management              310
  1.1   Planning and control          240
  1.2   Reporting and governance       70
2    Branch fit-out                1,005
  2.1   Design                        120
  2.2   Permits                        15
  2.3   Construction                  690
  2.4   Furniture and service desk    180
3    Self-service technology         375
  3.1   RFID tagging                   95
  3.2   Kiosks and gates              280
4    Mobile app                      480
  4.1   Discovery and design           70
  4.2   Build and test                410
5    Transition to operations        150
  5.1   Training                       60
  5.2   Collection move                55
  5.3   Opening                        35
Project total (work packages only): 2,320
Memo figure for 2: 1,010 -> differs by +5
Memo figure for 3: 375 -> ok
Memo figure for 4: 480 -> ok

The roll-up gives a total of $2.32 million for the work packages. The memo's figure of $1,010,000 for the branch fit-out is $5,000 more than the sum of its work packages, so either the memo includes an amount that belongs to no work package, or a work package estimate is missing. Either way, the 100 % rule is broken until the difference is resolved. In lesson 10, contingency reserve of $80,000 is added to the work package total to form the $2.4 million cost baseline.

The scope baseline

The scope baseline is the approved version of the scope statement, the WBS and the WBS dictionary. It can be changed only through formal change control. It is used as a basis for comparison when controlling scope, when validating deliverables and when assessing change requests. When a change request is approved, all three components are updated and versioned.

WBS in adaptive and hybrid projects

Adaptive projects do not usually build a detailed WBS for the product, because the backlog plays that role. Some organizations still use a high-level WBS with themes or epics at the upper levels and the backlog beneath. In hybrid projects like Project Compass, the WBS covers everything, but the app element is decomposed into releases or epics rather than detailed work packages; the backlog provides the detail. This keeps a single structure for budgeting and reporting while letting the app team work iteratively.

The WBS also supports other planning. Risks can be identified by walking through each element. Responsibilities can be assigned with a RACI matrix that maps WBS elements to people. Procurement decisions, covered in PMP-131, are made at the work package level: for Project Compass, construction and kiosk supply are bought, while tagging is done in-house with temporary staff.