Study guide
1.1 Work Breakdown Structure (WBS) Architecture & RP 33R-15
AACE Planning and Scheduling Professional PSP
Track your progress as you read
Finished sections get a check mark.
1 Chapter 0: Introduction & AACE PSP Exam Structure
0.1 Current AACE PSP Exam, Eligibility, and Certification Facts 0.2 Planning and Scheduling Professional Roles and Competencies 0.3 Cost Engineering and Scheduling Terminology per RP 10S-90
2 Chapter 1: Scope Definition & Planning Fundamentals
1.1 Work Breakdown Structure (WBS) Architecture & RP 33R-15 1.2 Organization & Resource Breakdown Structures (OBS, RBS, RAM) 1.3 Project Planning and Activity-Logic Development 1.4 Contract Requirements and Delivery Constraints 1.5 Stakeholder Identification, Needs, and Plan Review 1.6 Constructability Methods and Value Engineering 1.7 Resource Identification and Project Variables 1.8 Scope, Goals, Project Plan, and Phase Definition 1.9 Cost Breakdown Structure and Cost Estimate Development 1.10 Phase Relationships, Baseline Plan, Forecasts, and Risk/Recovery Planning
3 Chapter 2: Critical Path Method Mechanics & Network Logic
2.1 Activity Definition and Logic Relationships 2.2 Activity Durations, Productivity, and Work Calendars 2.3 Forward and Backward Pass Mathematical Mechanics 2.4 Float Calculations and Critical-Path Identification
4 Chapter 3: Advanced Network Techniques & Schedule Constraints
3.1 Schedule Constraints and Their Impact on Dates and Float 3.2 Advanced Logic Modeling: Ladders and Fragnets 3.3 Schedule Levels of Detail and Schedule Basis Documentation 3.4 Schedule Scope and Schedule Specification 3.5 Breakdown-Structure Relationships and the Cost Estimate Model 3.6 Stakeholder Feedback and Types of Schedules 3.7 Activities, Milestones, Schedule Quality, and Basis Documentation
5 Chapter 4: Resource Management & Leveling
4.1 Resource Planning, Allocation, and Histograms 4.2 Resource Leveling vs. Resource Smoothing 4.3 Cumulative Resource S-Curves & Productivity Tracking
6 Chapter 5: Baseline Management & Schedule Updating
5.1 Baseline Establishment, Forecasts, and Controlled Revision 5.2 Progress Measurement and Data Date Mechanics 5.3 Out-of-Sequence Logic: Progress Override vs. Retained Logic 5.4 Schedule Update Review and Quality Verification per RP 53R-06 5.5 Cost/Resource Management, Schedule Change, and Feedback 5.6 Acceleration and Recovery Scheduling per RP 54R-07 5.7 Control Schedules, Variance Analysis, Forecasts, and Management Summaries
7 Chapter 6: Schedule Risk Analysis & Monte Carlo Simulation
6.1 Schedule Risk Principles, Risk Drivers, and Three-Point Estimates 6.2 Monte Carlo Simulation, Criticality, Correlation, and Merge Effects 6.3 Risk Outputs, Confidence Dates, Sensitivity, and Contingency
8 Chapter 7: Earned Value & Earned Schedule Management
7.1 Earned Value Foundations: PV, EV, AC, and Variances 7.2 Traditional EV Performance Indices & Late-Project Quirks 7.3 Earned Schedule (ES) Theory, SV(t), and SPI(t) 7.4 Independent Schedule Forecasting & IEAC(t)
9 Chapter 8: Forensic Schedule Analysis & Delay Claims
8.1 Delay Classification, Criticality, and Contract Questions 8.2 RP 29R-03 Taxonomy, Data Validation, and Method Selection 8.3 TIA, Windowed Analysis, and Subtractive Models 8.4 Concurrency, Pacing, and Float: Technical Analysis Before Entitlement
10 Chapter 9: Executive Communication & Practical Scenario Applications
9.1 Official PSP Memo Writing Framework 9.2 Structured Technical Problem-Solving for PSP Scenarios 9.3 Current Exam Strategy and Core Calculation Review
1.1 Work Breakdown Structure (WBS) Architecture & RP 33R-15
Key Takeaways Explain This Topic AI
AACE Recommended Practice 33R-15 describes the WBS as a hierarchical framework for complete project scope and permits product- or process-oriented structures.
A useful completeness test is that child elements collectively cover the parent scope without omissions or overlapping responsibility.
The WBS organizes scope, while schedule activities and milestones represent time-phased work and events mapped to that scope.
A WBS dictionary or equivalent scope-basis record can document boundaries, acceptance criteria, responsibility, and coding when project governance requires it.
Last updated: October 2026
1.1 Work Breakdown Structure (WBS) Architecture & RP 33R-15
AACE Professional Context: Scope definition is the bedrock of total cost management and project controls. AACE Recommended Practice 33R-15 ( Developing the Project Work Breakdown Structure ) provides guidance for organizing the complete project scope into a usable hierarchical framework that supports estimating, scheduling, responsibility, and performance reporting. For PSP preparation, focus on completeness, traceable decomposition, fit for the project’s control purpose, and the distinction between a scope hierarchy and time-phased schedule activities.
Foundational Architecture of the WBS per RP 33R-15
A Work Breakdown Structure (WBS) is a hierarchical framework for organizing the work that makes up the complete project scope. RP 33R-15 explains that a WBS may be product or deliverable based, or process oriented, provided its parts are unique, manageable, and collectively cover the project scope.
Product-oriented and process-oriented decomposition
A product-oriented WBS organizes tangible or verifiable deliverables, while a process-oriented WBS organizes the work through phases or processes. Neither label alone establishes quality; the selected structure must cover the complete scope, support responsibility and control, and remain internally consistent.
Decomposing by deliverable provides distinct advantages over alternative structures:
Tangible Scope Boundaries: Deliverables can be inspected, measured, verified, and accepted against technical specifications.
Definitive Baseline Ownership: Deliverables can be assigned to discrete control accounts with clear organizational ownership.
Objective Earned Value Measurement: Deliverables provide concrete milestones for physical percent complete verification, eliminating subjective progress claims. [EXAMPLE A: Phase / Process-Oriented]
- 1.0 Commercial Office Building
- ├── 1.1 Engineering
- ├── 1.2 Procurement
- └── 1.3 Construction (Phase/Task lists, not deliverables)
- [EXAMPLE B: Product / Deliverable-Oriented]
- 1.0 Commercial Office Building
- ├── 1.1 Substructure (Foundation & Earthworks)
- ├── 1.2 Core & Shell (Structural Steel & Envelope)
- ├── 1.3 Interior Fit-Out (Partitions & Finishes)
- ├── 1.4 MEP Infrastructure (HVAC, Electrical, Plumbing)
- └── 1.5 Project Management (Controls, Safety, QA/QC)
A phase- or process-oriented WBS can be valid, but the WBS should not be confused with the Organizational Breakdown Structure (OBS), contract packaging, or schedule chronology. Whichever design is selected, use codes or crosswalks to preserve clear scope boundaries, responsibility, cost aggregation, and schedule mapping.
The 100% Rule: Scope Boundary Verification & Mathematical Integrity
A common completeness test, consistent with RP 33R-15’s requirement that the WBS contain all project scope, is the 100% Rule .
The 100% Rule: The WBS must encompass 100% of the scope defined by the approved project scope baseline. Each descending level of decomposition must collectively represent 100% of the scope of its parent element—no more and no less.
Mathematically, for any parent element W p W_p W p decomposed into n n n child elements w 1 , w 2 , … , w n w_1, w_2, \dots, w_n w 1 , w 2 , … , w n :
Scope ( W p ) = ∑ i = 1 n Scope ( w i ) \text{Scope}(W_p) = \sum_{i=1}^{n} \text{Scope}(w_i) Scope ( W p ) = ∑ i = 1 n Scope ( w i )
Budget ( W p ) = ∑ i = 1 n Budget ( w i ) \text{Budget}(W_p) = \sum_{i=1}^{n} \text{Budget}(w_i) Budget ( W p ) = ∑ i = 1 n Budget ( w i )
Critical Requirements of the 100% Rule
Mutually Exclusive and Collectively Exhaustive (MECE): No scope may overlap between child elements (mutually exclusive), and no authorized scope may be omitted (collectively exhaustive). If work appears in two different child elements, double-counting occurs, causing distorted cost tracking and duplicate activity logic.
Child-to-Parent Summation: The scope and budget of child elements roll up exactly to equal the parent element. A parent element does not possess independent work scope separate from its children.
Inclusion of Non-Physical Scope: A frequent exam trap is assuming the WBS contains only physical construction materials. The 100% Rule dictates that non-physical project deliverables must be formally captured in the WBS:
- Project Management & Project Controls (WBS Level 2 element)
- Health, Safety, and Environmental (HSE) Compliance Deliverables
- Regulatory Permits & Environmental Clearances
- Commissioning, Turnover, and As-Built Documentation
- Integrated Systems Testing & Operator Training
Exclusion of Out-of-Scope Work: Any work not contained within the WBS is out of scope. If a schedule activity cannot be mapped to authorized scope in the WBS or an approved crosswalk, investigate whether the problem is missing coding, an inappropriate level of detail, omitted authorized scope, or a genuine change before deciding the control response.
Distinguishing WBS Elements from Schedule Activities
A WBS organizes scope hierarchically; schedule activities model work through time. Confusing those functions makes scope, responsibility, cost, and network review harder even though the two structures must be mapped.
Attribute WBS Element (RP 33R-15) Schedule Activity (RP 24R-03)
Definition A hierarchical scope grouping, deliverable, phase, or manageable component A discrete unit of work or event represented in the time model
Grammatical Form Often a noun or named phase under the adopted coding convention Often an action verb plus object, with milestones naming events
Duration None. A WBS element spans the elapsed time of its children Explicit duration in work periods (e.g., 8 work days)
Network Logic The hierarchy itself does not calculate dates Activities and milestones use the project’s defined relationships and constraints
Resource Assignment Budget and account aggregation only Loaded directly with labor craft hours, equipment, and material quantities
Baseline Role Scope Baseline and Cost Breakdown Structure aggregation Schedule Baseline (CPM Critical Path calculations, Float analysis)
Location At the levels defined by the project’s WBS design Assigned or mapped to the relevant WBS element at the required control level
Exam Trap Alert: A question may ask: "True or False: The WBS is a schedule showing the sequence in which work will be performed." The answer is FALSE . Even a process- or phase-oriented WBS is a scope hierarchy, not the calculated schedule. Dates and sequence come from schedule activities, milestones, calendars, relationships, and constraints mapped to the WBS.
Hierarchy Levels: From Project to Work Package
RP 33R-15 provides WBS guidance and examples, but no one five-level hierarchy fits every project. The following is an illustrative project-controls design: Level 1: Total Project (The overall project undertaking)
- │
- Level 2: Subproject / Summary Phase / Major Facility (e.g., Process Plant, Offsites & Utilities)
- │
- Level 3: System / Discipline / Sub-Area (e.g., Boiler Feedwater System, Electrical Substation)
- │
- Level 4: Control Account (CA) (Intersection of WBS and OBS; management control point)
- │
- Level 5: Work Package (WP) / Planning Package (PP) (Lowest deliverable unit of the WBS)
- │
- └─── [Beneath WBS] Schedule Activities (Discrete CPM tasks with durations & logic)
- Definitions of Core Hierarchical Tiers
Level 1 — Total Project: The entire authorized capital project scope (e.g., WBS 1.0: Greenfield Biofuel Refinery ).
Level 2 — Major Facility / Subproject: Major physical subdivisions, distinct operational units, or major non-physical management scopes (e.g., 1.1 Feedstock Handling , 1.2 Distillation Unit , 1.3 Utilities , 1.4 Project Management ).
Level 3 — System / Discipline: Identifiable functional systems or geographic sub-areas within a facility (e.g., 1.2.1 Distillation Columns , 1.2.2 Reflux Condensers , 1.2.3 Column Piping Systems ).
Level 4 — Control Account (CA): The critical management control point where scope, budget (cost), and schedule are formally integrated and managed. Earned Value performance is measured and analyzed at this level. A single Control Account Manager (CAM) is assigned to each CA.
Level 5 — Work Package (WP): The lowest deliverable element in the WBS. A work package defines a discrete, manageable unit of work assigned to a single performing organization or contractor. Underneath the Work Package, planners build the detailed schedule activities that comprise the CPM network.
Planning Packages vs. Work Packages
Within a Control Account, far-term work that cannot yet be decomposed into detailed work packages is held in a Planning Package (PP) . A Planning Package has a defined deliverable scope, an assigned budget, and estimated start and finish dates, but lacks detailed schedule activities. Under rolling wave planning , planners progressively elaborate Planning Packages into detailed Work Packages and schedule activities before the applicable work-authorization or execution cutoff defined by the project.
Work Package Definition & Sizing Heuristics
Sizing a Work Package is a fundamental balancing act in project controls. If work packages are too large, project managers lose visibility into emerging variances. If they are too small, administrative paralysis and excessive reporting overhead overwhelm the project controls team.
Project-defined sizing checks
Control horizon: Define activity and work-package sizing criteria appropriate to the project. One practical design keeps near-term work measurable within a small number of reporting periods, while larger packages use objective interim measures.
Reporting Cycle Alignment: A work package should not span multiple reporting cycles without tangible, interim physical progress milestones. If a work package spans 6 months with zero intermediate measurable deliverables, early cost and schedule slippages remain invisible until the package is nearly complete.
Materiality and risk: Set project-specific cost, duration, and risk thresholds. A package may warrant greater detail because it is high risk or interface intensive even when its budget share is small.
Independence and Deliverable Focus: A work package must have clearly defined physical entry criteria (prerequisites) and exit criteria (measurable completion/handover).
Over-Decomposition vs. Under-Decomposition
- Attribute Under-Decomposition (Packages Too Large) Over-Decomposition (Packages Too Small)
- Management Visibility Obscured; variances hidden until late High visibility into granular tasks
- Administrative Overhead Minimal bookkeeping Paralyzing paperwork and tracking costs
Earned Value Reliability High risk of subjective 50/50 or percent guesses High precision, but data collection fatigue
Schedule Network Impact Insufficient logic ties; missing critical paths Over-constrained network; artificial float
Practical response Decompose enough to expose interfaces and objective progress Stop when added detail no longer improves decisions or control
The WBS Dictionary: Backbone of the Scope Baseline
The WBS graphical hierarchy alone is merely a tree diagram of titles. Without technical definitions, a title such as "1.1.2.1 Foundation Slab" is open to dangerous interpretation: Does it include excavation? Mud slab? Rebar placement? Embedments? Curing? Backfill?
A WBS dictionary or equivalent scope-basis record can define the boundaries behind short WBS titles. Its required status and format come from the project’s governance and contract.
Scope Baseline Elements:
- Approved Project Scope Statement
- Work Breakdown Structure (WBS)
- WBS Dictionary
- Useful fields for a WBS dictionary entry
A useful WBS dictionary entry may document:
WBS Code of Accounts Identifier: Unique alphanumeric identifier (e.g., WBS 1.2.3.1.04 ).
Deliverable Title & Detailed Scope Description: Precise narrative of the physical deliverable and technical boundaries.
Scope Inclusions and Exclusions: Explicit delineation of what is included and what is excluded (e.g., "Includes anchor bolt placement; excludes structural column erection" ).
Responsible Organization / CAM: The performing department, subcontractor, and assigned Control Account Manager.
Technical Specifications & Drawings: Cross-references to engineering drawings, P&IDs, CSI MasterFormat specifications, and quality codes.
Acceptance Criteria & Quality Inspection Requirements: Objective test standards, hold points, and sign-off criteria required for formal acceptance.
Milestones & Schedule Interface Dates: Earliest allowable start date and required completion handover milestone.
Budget Allocation & Resource Requirements: Assigned direct labor hours, equipment types, bulk material quantities, and cost baseline figures.
Contractual Deliverables & Subcontractor References: Purchase order or contract package cross-references.
Without clear scope-basis documentation, teams may struggle to distinguish included work, interfaces, and changes.
Common WBS Development Pitfalls (Exam Traps)
Review WBS design for common structural weaknesses while remembering that product- and process-oriented structures can both be valid:
Unexplained organizational decomposition: If WBS branches merely duplicate departments, scope and responsibility may be confused. Keep the OBS distinct and document the crosswalk.
Unstable package structure: Contract packages can be useful views, but using them as the sole WBS may make scope continuity difficult when packaging changes. Preserve a stable scope crosswalk.
Chronology without scope definition: A process- or phase-oriented WBS is permitted, but quarter labels alone may not define manageable scope. Dates and detailed sequence still belong in the schedule network.
Inconsistent Decomposition Depths Without Logic: Decomposing low-risk, simple items down to Level 7 while leaving high-risk, complex technical scopes at Level 3.
The Orphan Scope Pitfall: Creating child elements that do not sum to 100% of the parent scope, or introducing child elements with scope not authorized in the parent deliverable (violating the 100% Rule).
Worked Example: Industrial Water Treatment Facility
Consider the hierarchical decomposition of an Industrial Wastewater Treatment Facility, tracing a discrete deliverable from Level 1 down to the schedule activities beneath the Work Package.
- WBS Decomposition Tree
- 1.0 Industrial Wastewater Treatment Plant (Level 1: Total Project Scope)
- 1.1 Clarification Facility (Level 2: Major Facility)
- 1.1.2 Primary Clarifier Basin #1 (Level 3: Functional System / Area)
1.1.2.1 Clarifier Concrete Basin Structure (Level 4: Control Account — CAM: Lead Structural Engineer; Budget: $1,450,000)
1.1.2.1.1 Basin Foundation Slab (Level 5: Work Package — Deliverable: Reinforced concrete base slab per Drawing S-104)
1.1.2.1.2 Basin Perimeter Cantilever Walls (Level 5: Work Package — Deliverable: Circular reinforced concrete walls)
1.1.2.1.3 Basin Effluent Launder Channel (Level 5: Work Package — Deliverable: Concrete collection trough & weirs)
CPM Schedule Activity Decomposition (Beneath Work Package 1.1.2.1.1)
Notice that the schedule activities reside below Work Package 1.1.2.1.1. They possess durations, resource assignments, and CPM logic ties:
- Activity ID Activity Description Type Duration Predecessor(s) Successor(s)
- ACT-1100 Fine Grade & Compact Subgrade Task 3 Days ACT-1080 (Excavation) ACT-1110
- ACT-1110 Pour Unreinforced Mud Slab (Lean Concrete) Task 2 Days ACT-1100 ACT-1120
- ACT-1120 Place Bottom Rebar Mat & Waterstop Task 5 Days ACT-1110 ACT-1130
- ACT-1130 Install Sump Pit & Drain Piping Embedments Task 4 Days ACT-1120 (SS+1) ACT-1140
- ACT-1140 Place Top Rebar Mat & Form Edge Bulkheads Task 4 Days ACT-1130 ACT-1150
- ACT-1150 Pour Clarifier Basin Slab Concrete Task 1 Day ACT-1140 ACT-1160
- ACT-1160 Cure Basin Concrete & Strip Forms Task 7 Days ACT-1150 ACT-1170
- ACT-1170 Milestone: Foundation Slab Complete Milestone 0 Days ACT-1160 ACT-1200 (Wall Forms)
This structured separation maintains absolute scope clarity in the WBS while empowering the planning engineer to optimize CPM network logic, floats, and resource leveling in the schedule.