3.1 Schedule Constraints and Their Impact on Dates and Float

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.1 Schedule Constraints and Their Impact on Dates and Float

Key Takeaways Explain This Topic AI

Relationships model dependencies, calendars model working time, and date constraints impose boundaries or fixed dates; these mechanisms should not be conflated.

Flexible constraints generally set one-sided date bounds, while mandatory constraints can override calculated dates and obscure network behavior.

A constraint should have a documented source, purpose, responsible owner, and review disposition.

Negative or positive float may result from comparing network dates with constrained targets, subject to calendars and software settings.

Use logic, milestones, resource analysis, or explicit activities when they better represent the underlying requirement.

Last updated: October 2026

3.1 Schedule Constraints and Their Impact on Dates and Float

A CPM network calculates dates from activities, durations, calendars, and relationships. A date constraint adds a boundary or fixed date. Constraints can represent real requirements, but they can also hide missing scope or logic. Review both the source and the mathematical effect.

Different scheduling mechanisms

Relationship: represents dependency between activity endpoints.

Calendar: defines working and nonworking time.

Milestone: represents a zero-duration event or commitment.

Resource rule: limits work according to available capacity.

Date constraint: restricts an early or late date, or fixes a date depending on type and software.

If one crew must move from Area A to Area B, explicit crew-flow logic or resource-constrained analysis may be clearer than a start-no-earlier-than date. If a regulator permits work only after a stated date, an external milestone and relationship may provide better traceability than an unexplained constraint.

Flexible constraints

A start-no-earlier-than constraint generally sets a lower bound on early start: logic can push the activity later but not earlier. A finish-no-later-than constraint generally sets an upper bound used in the backward pass and can generate negative float if the network finishes later. Exact names and calculation behavior vary by software, so confirm configuration.

Flexible constraints can be legitimate for access dates, contractual windows, permits, or other requirements. Document the governing source and do not use them to conceal an activity that should be modeled.

Mandatory constraints

Must-start-on or must-finish-on constraints commonly force a date and can override or disconnect normal early/late calculations in ways that vary by product. They may create misleading float or prevent upstream delay from visibly moving the constrained activity. Use them only when required and understood, and explain the resulting calculation behavior.

A contractual milestone does not automatically require a mandatory constraint. Many schedules model the contractual date as a finish-no-later-than target or deadline so that the forecast remains visible and negative float quantifies the gap. Follow the contract, specification, and selected software methodology.

Float effects

Suppose unconstrained completion is 15 November and a required finish is 31 October, stated as eleven working days earlier under the applicable calendar. A late-date constraint may create negative eleven days of float on the driving path. That result says the current plan misses the modeled target by eleven working days. It does not identify fault or authorize a time extension.

An as-late-as-possible setting schedules an activity toward its late dates under the model. It can consume operational flexibility and increase exposure to disruption, but its detailed float behavior depends on software and network configuration. Avoid broad claims that every ALAP use automatically creates the project critical path.

Constraint audit

For every material constraint, record:

activity or milestone;
constraint type and date;
source and authority;
business or technical purpose;
calculation and float effect;
whether logic or an explicit activity would be clearer; and

approval or disposition.

Revisit constraints during updates. A permit date may become an actual milestone, an access assumption may change, or a once-valid management target may be superseded. Preserve baseline history while keeping the current forecast technically honest.

The best model exposes why work cannot occur earlier or later. Use constraints deliberately, not as a substitute for planning or as a cosmetic way to force a desired bar-chart date.

Applied review: replace hidden dates with visible causes

For each constrained activity, ask what real event prevents earlier or later work. If the cause is an approval, delivery, outage, access release, or permit, consider modeling that event as a milestone with the work that produces it. This usually gives the update a responsible owner, status evidence, and a path that can move when conditions change.

Where a date constraint remains appropriate, run the schedule with and without it in a controlled copy. Compare milestone dates, float, longest path, and any broken driving relationships. Document the difference in the schedule basis or update narrative. This test shows users which dates come from execution logic and which come from an imposed requirement, improving forecast interpretation and recovery planning. Recheck the constraint after approved change, actual achievement, or a revised external commitment. Remove obsolete constraints through controlled change so they do not continue to influence later forecasts.