M1.1 — Scope & Work Breakdown Structures

M1.1 — Scope & Work Breakdown Structures

1. Practical outcome

By the end of this section, the learner should be able to take an authorised project scope and turn it into a Work Breakdown Structure (WBS) that can actually be used to control the project. They should be able to explain what belongs in the WBS, what does not, how far to decompose the scope, how to avoid gaps and overlaps, how to define work-package boundaries, and how the WBS becomes the stable scope backbone for schedule, cost, risk, responsibility, progress and change.

The objective is not to produce an attractive hierarchy. It is to create a scope model that makes the project easier to plan, estimate, assign, measure, analyse and govern.

2. Core concepts

Scope and the WBS

Project scope describes the authorised work and deliverables needed to achieve the project objectives. A Work Breakdown Structure is a hierarchical decomposition of that authorised scope into progressively smaller, controllable components.

·       The WBS answers “what scope must be delivered?” It is not the project schedule and should not simply become a chronological task list.

·       A parent element represents the total scope contained within its children. The children should collectively represent the parent without gaps or duplication.

·       A work package is a lower-level WBS component at which the project can sensibly plan, estimate, assign responsibility, measure progress and control change.

Terminology depends on the control system. In formal EVM, work packages sit within control accounts for detailed planning and measurement; planning packages hold future work not yet detailed. State how these objects map to the project WBS rather than assuming that every lowest-level WBS code is itself an EVM work package.

The 100% rule

A sound WBS should represent 100% of the authorised project scope. This includes the project-management or integration work that is genuinely part of the authorised undertaking, but excludes work outside the approved scope.

The rule also applies at each level. If a parent element represents “Digital & Technology Systems”, the children beneath it should collectively represent all of that scope and only that scope.

Mutual exclusivity and clear boundaries

The same scope should not appear in two places. If both “Site & Building” and “Digital & Technology Systems” include the same network cabling, cost, progress and accountability can be double counted. Good WBS design therefore depends as much on defining boundaries as on naming elements.

Deliverables are not activities

A common error is to create WBS branches such as “Design”, “Procure”, “Install” and “Test” simply because those are the stages of work. Those may be legitimate WBS elements in some delivery models, but often they are schedule activities performed to create a deliverable. The practitioner should consciously decide whether the WBS is decomposing scope or merely reproducing the project timeline.

How far should the WBS be decomposed?

There is no universal rule saying that every branch must stop at the same level. Decomposition should continue until the scope is controllable. A useful test is whether the element can be assigned, planned, estimated, measured and changed without ambiguity. Different branches may therefore require different depths.

·       Too little decomposition hides accountability, progress and emerging problems.

·       Too much decomposition creates administration without better control.

·       The correct level is the point at which additional decomposition no longer creates useful control information.

WBS dictionary

Short WBS titles are rarely enough to define boundaries. A WBS dictionary can state what each element includes, what it excludes, the expected deliverable or acceptance condition, responsible owner, assumptions and important interfaces. This becomes especially valuable where two work packages meet.

Relationship to other control structures

The WBS is the scope backbone, but it is not required to be identical to the Cost Breakdown Structure (CBS), Organisational Breakdown Structure (OBS), Resource Breakdown Structure (RBS) or contract structure. Those structures answer different management questions. M1.2 deals with how they are coded and mapped.

3. Step-by-step method — how to build a usable WBS

1. Start with the authorised scope, not a blank software screen. Review the business case, scope statement, requirements, approved deliverables, exclusions, assumptions and any contractual scope descriptions. Identify what has actually been authorised. If the scope boundary is unclear, record that uncertainty before decomposing it.

2. Identify the highest-level project deliverables or controllable scope components. Choose a top-level structure that makes sense for the way the project will be governed. The categories should collectively represent the whole project. Avoid choosing headings simply because they mirror the organisation chart.

3. Choose a sensible decomposition logic for each branch. Break a parent element into meaningful child elements. The decomposition might be by facility area, system, asset, product, geographic zone or another deliverable-oriented logic. Different branches can use different logic when that improves control, provided the boundaries remain clear.

4. Decompose until the work becomes controllable. Continue until a responsible person can understand the scope, estimate it, plan the work needed to deliver it, define progress evidence, identify associated risks and assess changes. Stop before decomposition becomes administrative detail.

5. Apply the 100% rule at every parent. Ask whether the children collectively contain all of the parent scope. Then ask whether any child overlaps another. Missing scope and duplicate scope are both defects.

6. Define work-package boundaries explicitly. For significant or ambiguous work packages, record what is included, excluded and handed across interfaces. State the deliverable or completion condition. This is where a WBS dictionary becomes useful.

7. Identify ownership without turning the WBS into an organisation chart. A work package should have clear accountability, but its place in the WBS should normally be determined by the scope it represents, not by which department happens to deliver it.

8. Test the WBS against the other controls that will depend on it. Ask whether schedule activities, estimate lines, budget, risks, progress measures, change requests and management reporting can be mapped to the WBS. If they cannot, the structure may not be usable enough for integrated control.

9. Validate the WBS with the people who understand the work. Review the hierarchy and dictionary with delivery, planning, cost, risk and commercial stakeholders. Ask them to find missing, duplicated or ambiguous scope. A WBS should survive challenge before it becomes a baseline structure.

10. Control the structure after approval. Once the WBS is part of the project baseline, changes should be governed. Renaming, moving or splitting elements can affect cost history, schedule mappings, reporting and accountability. Do not casually restructure the WBS to make current reporting look cleaner.

4. Worked example — Reference Project

The Reference Project is the Community & Learning Centre Project: a 24-month project with a 50 million Cost Unit (CU) approved budget and a fixed public opening date. The locked Level-1 WBS is:

·       1.1 Design & Approvals

·       1.2 Site & Building

·       1.3 Furniture & Specialist Equipment

·       1.4 Digital & Technology Systems

·       1.5 External Areas & Access

·       1.6 Operational Readiness, Testing & Handover

Now consider 1.3 Furniture & Specialist Equipment. A reasonable deliverable-oriented decomposition might be:

·       1.3.1 Learning-space furniture

·       1.3.2 Community and meeting-room furniture

·       1.3.3 Office and administration furniture

·       1.3.4 Specialist learning equipment

·       1.3.5 Café and social-area furniture/equipment

·       1.3.6 Shared fixtures, storage and loose equipment

Notice what is deliberately not being done. “Specify”, “Tender”, “Order”, “Manufacture”, “Deliver”, “Install” and “Accept” are not automatically separate WBS branches. They are the activities that may appear in the schedule to deliver a work package such as 1.3.4 Specialist learning equipment.

The Reference Project combines a central Design & Approvals branch with delivery branches. Its dictionary must distinguish central design/approval scope from package-specific design and supplier submittals. Assign each item once and cross-reference the interface; a design activity under a delivery package does not mean the same scope and budget also belong in 1.1.

Worked boundary test

Assume interactive display screens are required in the learning rooms. Should they sit under 1.3 Furniture & Specialist Equipment or 1.4 Digital & Technology Systems? There is no value in arguing that one answer is universally correct. The control requirement is that the project makes one clear decision, documents the boundary and applies it consistently.

For example, the project may decide that permanently networked display screens are part of 1.4 Digital & Technology Systems, while movable teaching equipment is part of 1.3. The WBS dictionary would record that decision so estimating, procurement, scheduling and progress reporting all use the same boundary.

From WBS to schedule

Once 1.3.4 has been defined, the schedule can contain activities such as: finalise specification → issue enquiry → evaluate bids → award order → manufacture → factory inspection → deliver → install → test → accept. The distinction matters: the WBS remains the stable scope container while the schedule models the time-based work needed to deliver it.

5. Interpretation and professional judgement

A WBS can comply with basic definitions and still be poor. Professional judgement is needed in several areas.

Is the structure genuinely helping control? If management cannot use it to understand scope, accountability, cost, schedule or change, the hierarchy may be technically neat but practically weak.

Is the decomposition too shallow? A single 8 million CU “Building” work package might conceal several different contractors, progress methods, risks and interfaces. Additional decomposition may be justified.

Is the decomposition too deep? Breaking every room into every fixture may produce hundreds of low-value WBS elements that do not improve decisions. That detail may belong in the schedule, bill of quantities or asset register instead.

Are the boundaries meaningful? Interfaces deserve deliberate attention. Where responsibility transfers between teams or suppliers, the WBS dictionary should make the hand-off visible.

Should all branches look symmetrical? No. One branch may need four levels because it is complex and high risk, while another is controllable at two. Uniform depth is not a quality criterion.

What happens when scope is progressively defined? Early in a project, some scope may not yet justify detailed decomposition. Controlled progressive elaboration is preferable to pretending uncertain scope is already known. Once the structure is baselined, later changes still require governance.

A useful practitioner test is: “If this WBS element changes, can I identify the schedule, cost, risk, progress and accountability consequences without ambiguity?” If not, the scope boundary may not yet be strong enough for control.

6. Practice diagnostic

Use this table to challenge the quality of the approach or deliverable. The rows consolidate the most important recurring red flags and checks; they are prompts for professional judgement rather than a substitute for the method above.

7. Try-it-yourself practical exercise

Using the Community & Learning Centre Reference Project, work through the following exercise rather than simply drawing a hierarchy:

1.       Choose two Level-1 branches: 1.3 Furniture & Specialist Equipment and 1.4 Digital & Technology Systems.

2.       Decompose each branch until you believe the resulting work packages are controllable. Do not force the two branches to the same depth.

3.       For every child at the lowest level, write a one-sentence scope description.

4.       Identify at least two potential overlap/interface problems between 1.3 and 1.4 and decide which branch owns each item.

5.       Create a WBS dictionary entry for one work package, including scope included, scope excluded, owner, completion evidence and interfaces.

6.       Create five schedule activities that deliver that work package and explain why those activities are not separate WBS elements.

7.       Identify one cost item, one risk and one possible change request and show how each would map to the work package.

8.       Challenge your own WBS using the 100% rule: deliberately look for one missing item and one possible duplication.

9.       Write a short explanation of why you stopped decomposing where you did.

What good performance looks like

The exercise is successful when the learner can defend the structure, not merely produce it. They should be able to explain why a work package exists, why a boundary was chosen, how the WBS supports downstream controls, and what would go wrong if the structure were poorly designed.

8. Bridge to capability

The How-to teaches how to build and use a WBS. The table distinguishes shared understanding at CORE from demonstrated application at APPLIED and above. Evidence is illustrative and should be assessed with the practitioner’s reasoning; possession of a work product alone does not establish capability. Sample learning questions illustrate the judgement at each recognition level; they are discussion prompts rather than validated assessment items.

Learning question: Do you understand how to build and use a sound WBS?

Capability question for APPLIED and above: Can you demonstrate a complete, usable WBS, explain your decisions and resolve weaknesses appropriate to your level?