ExamFinch.com My Study

Study guide

3.4 Schedule Scope and Schedule Specification

Practice this exam

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.4 Schedule Scope and Schedule Specification

Key Takeaways Explain This Topic AI

Schedule scope defines the work, interfaces, milestones, and level of detail the schedule model must represent.

A schedule specification defines submittal, coding, calendar, logic, update, narrative, quality, and review requirements.

Requirements should support decision-making and contract administration without dictating arbitrary software behavior.

Compliance review checks both technical model quality and conformance with the governing specification.

Last updated: October 2026

3.4 Schedule Scope and Schedule Specification

Schedule scope answers what the time model must include. Schedule specification answers how the schedule will be developed, submitted, updated, reviewed, and controlled. Confusing them leads either to a compliant file that omits important work or a complete model that cannot be administered consistently.

Define schedule scope

Begin from project scope, WBS, contracts, interfaces, and control objectives. Define:

  • included lifecycle work, from required inputs through closeout;
  • contractor, owner, designer, vendor, regulator, and third-party interfaces;
  • contractual and internal milestones;
  • systems, areas, phases, and work packages;
  • design, procurement, construction, testing, commissioning, and turnover;
  • level of detail appropriate to decisions and updates; and

exclusions or work controlled in linked schedules.

The schedule scope should cover enough work to calculate a credible path to each protected milestone. An owner-furnished equipment date cannot remain an unexplained constraint; the model needs the delivery milestone and interface even if the owner manages its detailed activities elsewhere.

Define the specification

A schedule specification may address:

  • Topic Example requirement
  • Platform/file Native electronic file and readable report
  • Coding WBS, responsibility, phase, area, contract, and system codes
  • Calendars Working periods, holidays, weather treatment, shifts
  • Activities Naming, duration limits, milestone types, level of detail
  • Logic Relationship types, lags, open ends, constraints, required explanations
  • Resources/cost Loading rules, coding, reconciliation, earning methods
  • Baseline Submission timing, review, comments, approval, preservation
  • Updates Data date, actuals, remaining durations, change logs, narratives
  • Quality Required diagnostics and thresholds or explanations
  • Recovery Trigger, content, alternatives, and review process

Requirements should be measurable. “Provide a good schedule” is not administrable. “Identify activities without predecessors or successors and explain approved exceptions” can be reviewed.

Avoid specification traps

A specification can damage the schedule when it mandates form over meaning. Examples include requiring every relationship to be finish-to-start, prohibiting all long activities regardless of work type, or forcing one calendar on all work. Good specifications allow justified exceptions and focus on transparency, completeness, and fitness for control.

Avoid tying approval solely to one diagnostic score. A schedule can pass numeric thresholds while containing poor scope or unrealistic logic. Conversely, an unusual but justified operation may trigger a metric without being defective.

Reconcile multiple schedules

Projects may use an integrated master schedule, contract schedule, control schedule, detailed execution schedule, and lookahead plans. Define hierarchy and data flow:

Which model calculates the contractual completion forecast?

How do subcontractor or vendor schedules connect?

Which dates are statused and approved?

How are interface changes communicated?

Which schedule is the record for change analysis?

Without these rules, teams compare dates from models with different data dates and logic.

Baseline compliance review

Check:

  • scope and milestones are complete;
  • coding supports required views;
  • calendars and constraints are documented;
  • logic is connected and physically credible;
  • durations and resources reconcile with the plan;
  • required reports and narratives are present; and

exceptions are explained and accepted through the stated process.

Compliance is not a one-time event. Update requirements preserve the schedule as a current communication and forecasting tool throughout execution.

Applied review: write requirements that can be tested

Schedule scope establishes the boundaries of the model: included deliverables, external interfaces, required milestones, phases, control level, and excluded work. It should state how owner, contractor, vendor, and third-party obligations connect. If a boundary item can affect completion, represent its interface even when another party performs the underlying work. An exclusion that can drive the project is not safely handled by silence.

A schedule specification converts control needs into measurable requirements. It may define calendars, coding, activity identification, relationship practice, permitted constraints, progress rules, resource or cost loading, submittal timing, narratives, change control, quality checks, file format, and review cycle. Requirements should explain the management purpose and acceptance criteria. Arbitrary numerical limits can create compliance theater if they do not improve model reliability.

Review compliance in two layers. First, determine whether the submitted model conforms to the specification. Second, determine whether it is technically credible for its intended use. A schedule can satisfy a coding rule while omitting scope, and it can be logically sound while missing a required narrative. Document each exception, its effect, and its disposition. On the exam, prefer a response that resolves ambiguity before detailed development and tests both contractual compliance and technical fitness rather than treating software defaults as the specification.