3.3 Schedule Levels of Detail and Schedule Basis Documentation

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

3.3 Schedule Levels of Detail and Schedule Basis Documentation

Key Takeaways Explain This Topic AI

Schedule levels are common communication conventions whose exact content and numbering must be defined by the project or organization.

Higher-level schedules summarize commitments and decisions; lower-level schedules add control or execution detail while remaining traceable to the same scope and dates.

RP 37R-06 provides guidance on schedule levels of detail, not a universal rule that every project must use identical level names or activity counts.

RP 38R-06 concerns documenting the schedule basis: scope, strategy, calendars, durations, logic, constraints, resources, risk, assumptions, and exclusions.

Basis documentation improves transparency and evidence quality but does not by itself make a schedule contractually binding or establish entitlement.

Last updated: October 2026

3.3 Schedule Levels of Detail and Schedule Basis Documentation

AACE RP 37R-06 addresses schedule levels of detail as applied in engineering, procurement, and construction. A common convention ranges from executive milestones and phase summaries to integrated project controls and detailed execution schedules. The labels are useful communication shorthand, but the project specification or organization must define what each level means.

Common level purposes

Executive or milestone view: major authorization, phase, delivery, turnover, and completion commitments.

Phase or summary view: engineering, procurement, construction, commissioning, and major package interfaces.

Integrated control schedule: the cross-functional network used to status, analyze paths, forecast milestones, and coordinate control accounts or packages.

Detailed execution schedule: discipline, area, contractor, or system detail used for near-term coordination and measurable progress.

Short-interval plan: daily or weekly commitments, crew assignments, and work-face coordination.

Numbering varies, and not every project needs five levels. A small project may operate effectively with a milestone view, one integrated schedule, and a look-ahead. A complex program may need several intermediate models. Define purpose, owner, update frequency, coding, and reconciliation rules before calling a file “Level 3” or “Level 4.”

Traceability across levels

Higher-level dates should be explainable from lower-level work. A summary bar is not independent logic. Control milestones can tie packages together, while coding and reporting rules roll detail into management views. If a field schedule forecasts a later system turnover than the control schedule, reconcile status, scope, calendars, and logic rather than maintaining two incompatible truths.

More detail is useful only when it supports a decision and can be maintained. Excessive granularity creates update burden and false precision. Too little detail can hide interfaces, make progress subjective, and prevent path analysis. Select detail based on risk, phase, work complexity, reporting cycle, responsibility, and evidence availability.

Documenting the basis

AACE RP 38R-06 concerns documenting the schedule basis. A basis document commonly addresses:

• project scope, boundaries, WBS, and exclusions;
• execution, packaging, phasing, and contracting strategy;
• milestone sources and stakeholder interfaces;
• activity and coding conventions;
• logic strategy and material preferential relationships;
• duration, quantity, productivity, crew, and procurement sources;
• calendars, shifts, holidays, restrictions, and weather treatment;
• constraints and lags with their justifications;
• resource or cost loading and reconciliation methods;
• risk, contingency, and sensitivity assumptions;
• current critical and near-critical paths; and

known limitations, unresolved items, and approval status.

These are useful content categories, not a claim that every project must use an identical seven- or twelve-section template. Follow the required submittal format where one exists.

Evidence and governance

The native schedule calculates dates; the basis explains why the model was constructed as it was. Reviewers should be able to trace a duration to its source, a calendar to its working-time assumption, a milestone to its requirement, and a constraint to its authority. When assumptions change, update the current forecast and record the change. If an authorized baseline revision occurs, preserve the prior basis and issue a bridge to the new one.

A basis document can be important contemporaneous evidence, but its legal effect depends on the contract, approval history, facts, and applicable law. It does not automatically convert a planning hypothesis into a binding promise or prove delay entitlement.

Review test

Select a management milestone and trace it down to detailed driving work. Then select a detailed activity and trace it up to its scope, responsible organization, cost account, and reporting milestone. Confirm that calendars, logic, and status reconcile across the views. This bidirectional trace is more meaningful than judging schedule quality by activity count alone.

Applied review: choose detail by control need

Define a test for each schedule view. An executive view should expose decisions and commitment dates. A control schedule should support objective status, path analysis, variance, and forecast. A field view should assign near-term work to crews and work faces. If a view cannot support its intended decision, change its content or frequency rather than merely adding activities.

At each reporting cycle, reconcile milestone dates and status between views. Document intentional cutoffs, filters, and aggregation. The basis should also identify which view is the controlled source and how subordinate schedules feed it. That governance prevents a favorable summary chart from drifting away from the current detailed forecast.