1.4 Contract Requirements and Delivery Constraints

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.4 Contract Requirements and Delivery Constraints

Key Takeaways Explain This Topic AI

Planning begins by translating contract documents, technical requirements, and owner objectives into schedule obligations and controls.

The scheduler must distinguish contractual milestones, access dates, review periods, work restrictions, and reporting rules from internal targets.

Delivery and payment models influence planning responsibility but do not replace scope, logic, duration, and resource analysis.

A requirements matrix should identify the source, owner, schedule treatment, verification method, and unresolved interpretation for each obligation.

Last updated: October 2026

1.4 Contract Requirements and Delivery Constraints

The official PSP scope begins planning inputs with contract requirements . Before building activities, the planner must understand what the project has promised to deliver, when access and decisions will occur, how performance will be demonstrated, and which schedule submittals the parties require.

Build the document hierarchy

Project requirements may come from the agreement, general and supplementary conditions, statement of work, drawings, specifications, addenda, permits, owner standards, proposal clarifications, and executed changes. A planning team should know the document-precedence clause and should not resolve a conflict by silently choosing the most convenient source.

A requirements matrix makes the input traceable:

• Requirement Source Schedule treatment Owner Verification
• Notice to Proceed Agreement Start milestone Owner Executed notice
• Long-lead submittal review Specification Activities and stated review duration Design manager Submittal log
• Restricted outage Operating requirement Calendar/window and milestone Operations Approved outage plan
• Monthly update Scheduling specification Recurring control process Scheduler Accepted update
• Extract time obligations

Look for more than final completion. The plan may need:

• notice-to-proceed and access dates;
• sectional, interim, turnover, and substantial-completion milestones;
• owner-furnished information or equipment dates;
• review and approval periods;
• procurement lead times and required-on-site dates;
• environmental, safety, traffic, or operating windows;
• testing, commissioning, training, and closeout obligations;
• notice deadlines and change-evaluation procedures; and

update, narrative, coding, cost-loading, and recovery-schedule requirements.

Contractual dates should be recognizable in the schedule and traceable to their source. Internal targets can be more aggressive, but label them as internal so they are not mistaken for contractual commitments.

Delivery strategy changes planning interfaces

Design-bid-build, design-build, engineering-procurement-construction, construction management, and multiple-prime arrangements allocate design and coordination differently. A design-build schedule may integrate design release, procurement, and construction packages. A design-bid-build plan may contain more owner/designer review interfaces before construction. The delivery model influences who supplies information and controls an interface; it does not excuse incomplete logic.

Payment type also affects controls. Lump-sum work may use a schedule of values; unit-price work may rely on measured quantities; cost-reimbursable work may emphasize authorization and cost collection. In every case, the schedule must represent the physical and managerial plan rather than merely reproduce billing lines.

Translate prose into model elements

Use the least distorting treatment:

• a zero-duration milestone for a required event;
• an activity for work or review that consumes time;
• a calendar for recurring working restrictions;
• a relationship for a real dependency; and

a constraint only when an external date must be represented and its effect is understood.

Do not replace a review activity with a finish constraint simply because both show the same date in the baseline. The activity preserves duration, responsibility, and logic; the constraint can hide the actual interface.

Resolve ambiguity

When documents conflict, log a request for interpretation. Model the current approved assumption, identify it in the schedule basis, and assess alternatives when the difference can affect a milestone. A planner should not provide unauthorized legal interpretation, but must expose the schedule consequence of unresolved language.

Quality check

Before baseline approval, reconcile the requirements matrix to the WBS, milestone list, calendars, schedule specification, risk register, and change log. Each material time obligation should have an explicit home. This prevents late discovery of omitted turnovers, assumed access, or unrealistic review periods after the network has already been accepted.

Applied review: turn obligations into model tests

A useful requirements matrix is not merely a document index. For each requirement, record the controlling source and clause, the responsible party, the promised event or performance, the schedule representation, the evidence that will confirm completion, and any unresolved interpretation. For example, an owner-furnished equipment date may require an owner procurement chain, a delivery milestone, an inspection activity, and a successor installation activity. A contractual completion milestone may also require separate internal targets that preserve management flexibility without being mislabeled as contractual dates.

Test each extracted requirement against the schedule. Can a reviewer trace a required notice period to logic? Do owner review durations match the governing documents? Are seasonal restrictions represented by activities or calendars that users can understand? Does a milestone describe a real event, and is the work needed to achieve it modeled? If two documents conflict, log the conflict and obtain direction; do not silently choose the convenient interpretation.

On an exam scenario, separate three ideas: the obligation stated by the contract, the planner's technical model of how the obligation can be achieved, and a management target adopted for control. The source controls the first, sound planning supports the second, and management may set the third. Keeping those categories visible prevents an internal goal from becoming an invented contract term and prevents a contract milestone from disappearing inside a summary bar.