ExamFinch.com My Study

Study guide

5.1 Baseline Establishment, Forecasts, and Controlled Revision

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

5.1 Baseline Establishment, Forecasts, and Controlled Revision

Key Takeaways Explain This Topic AI

A baseline is an approved reference for measuring performance; the current schedule is the statused and forecasted model of remaining work.

Baseline review should test scope, logic, durations, calendars, milestones, resources, cost loading, risk treatment, and basis documentation against project requirements.

Performance variance belongs in the current forecast and does not by itself justify erasing or moving the baseline.

Baseline revisions require the authority and process defined by the contract or governance system, with prior versions preserved.

Potential, approved, and implemented changes must remain distinguishable so reports can explain both performance and authorized scope change.

Last updated: October 2026

5.1 Baseline Establishment, Forecasts, and Controlled Revision

A baseline schedule is an approved reference used to measure performance. Its contractual status depends on the governing documents: it may be a contract requirement, an accepted submittal, or an internal management target. A current schedule records actual status to a data date and forecasts remaining work from current information. The two must be related but not confused.

Establishing the reference

Before approval, review the proposed baseline against its specification and intended use:

  • scope and milestone completeness;
  • activity definition and coding;
  • logic, lags, constraints, and calendars;
  • quantity, productivity, duration, and resource assumptions;
  • procurement, owner, third-party, testing, and turnover interfaces;
  • cost or resource loading where required;
  • risk and contingency treatment;
  • schedule basis, assumptions, exclusions, and known limitations; and

reconciliation to the contract, estimate, execution plan, and reporting structure.

Record review comments and dispositions. Approval should identify the file, data date or start basis, revision, responsible authority, and any accepted exceptions. Preserve the approved native file and related basis documentation.

Baseline versus forecast

The baseline answers: what was approved? The current forecast answers: what is now expected? Actual starts, actual finishes, remaining durations, revised logic, and current conditions belong in the working update. Comparing current values with baseline values produces variance. If poor productivity moves completion later, the current forecast should show that movement; changing the baseline merely to remove the variance destroys useful information.

The baseline itself is usually retained as a frozen comparison. Some systems copy baseline dates into designated fields while others maintain separate files or versions. The control principle is preservation and traceability, not a particular software label.

Change states

A disciplined system distinguishes:

  • potential change: identified but not authorized;
  • proposed change: defined and submitted for evaluation;
  • approved change: authorized under the applicable process; and

implemented change: incorporated into the controlled cost and schedule systems.

A proposed change may be modeled in a sandbox, fragnet, or scenario to understand time and resource effects. Modeling does not itself establish entitlement or approval. The live forecast may need to reflect work that is actually occurring even while commercial responsibility remains unresolved; reports should label the situation and preserve both technical truth and governance status.

Controlled revision

An authorized scope, milestone, funding, or execution-strategy change may justify a revised baseline if the governing procedure permits it. Before revision:

  • identify the authorization and effective date;
  • define added, deleted, or modified scope;
  • validate logic, durations, resources, cost, and risk;
  • reconcile time and budget effects;
  • preserve the prior baseline;
  • issue the new revision with a bridge explaining the change; and

retain the current forecast and historical variance record needed by governance.

Organizations sometimes use supplemental or replanned control baselines for major restructures. The terminology and authority vary. Do not infer from a schedule-health problem alone that revision is allowed or prohibited; apply the project’s rules and document the decision.

Reporting

A useful report can show original baseline, current approved baseline, prior forecast, current forecast, and any pending-change scenario as separate series. This allows management to distinguish authorized change from execution performance and emerging risk. Every series should have a named source and status.

The baseline is valuable because it preserves a stable reference. Change control is valuable because projects legitimately change. Sound baseline management supports both needs through authorization, transparent forecasting, version preservation, and an audit trail.

Applied review: build a change bridge

When an authorized revision is proposed, prepare a bridge that starts with the prior baseline and lists each approved scope, logic, duration, calendar, resource, cost, and milestone change. Recalculate the model, reconcile authorized time and budget, and explain any residual performance variance that the change does not address. The bridge lets a reviewer distinguish a changed commitment from changed execution performance.

Preserve scenario models separately from controlled baselines and current updates. Label their purpose, status, assumptions, and owner. This prevents a “what-if” recovery or claim model from being mistaken for the approved plan and keeps management comparisons reproducible across reporting periods. Confirm that the current cost system, change register, and schedule use the same authorized scope cutoff before presenting an integrated variance. Record the effective date, revision, status, and responsible approver for every controlled reference, artifact, and report.

Review disposition and acceptance

Keep technical review, contractual compliance, and approval status distinct. A schedule may calculate successfully yet omit scope, conceal a resource conflict, or violate a required coding rule. Conversely, an unusual relationship or a high-float path is not automatically defective if it has a documented purpose and satisfies the governing requirements. Review comments should identify the requirement or technical concern, its effect on the model, the responsible party, the requested correction, and the final disposition. Recalculate after material corrections because one logic, calendar, or duration change can move paths elsewhere in the network.

If the approving authority accepts a baseline with listed exceptions, retain the exception list beside the approved version and track its closure. Acceptance does not make a known limitation disappear, and a reviewer should not quietly repair another party's file without preserving what changed. In an exam scenario, favor traceable review and documented disposition over either automatic acceptance based on a software health score or automatic rejection based on a single metric.