Primavera P6 Constraints Explained (and When to Avoid Them)

What Are Primavera P6 Constraints?

Constraints in Primavera P6 are manual overrides that fix a task’s start or finish date, limiting the scheduling engine’s ability to calculate dates based on logic and calendars. They are sometimes necessary but often misused, leading to distorted float, broken critical paths, and failed DCMA checks.

Common Constraint Types

• Start On or After (earliest start date) – most common, often used for external dependencies.
• Finish On or Before (latest finish date) – sets a deadline without forcing the finish.
• Mandatory Start/Finish (hard constraints) – locks the date regardless of logic; flagged by DCMA.
• Start/Finish On (exact date) – rarely justified; creates a fixed point.
• As Late As Possible – pushes task to the latest possible date; can cause negative float.

How Constraints Distort Float and the Critical Path

When you apply a constraint, Primavera P6 adjusts the early and late dates accordingly. For example, a “Start On or After” constraint on a successor may create negative float if the preceding logic cannot meet that date. Hard constraints (Mandatory Start/Finish) break the forward/backward pass: the task’s date is fixed, so total float becomes undefined or forced to zero. This masks the true critical path and can make the schedule appear compliant when it is not.

In a logic-driven schedule, the critical path is the longest chain of tasks with zero total float. Constraints introduce artificial float values. A task with a Mandatory Finish may show zero float even if it has slack from its predecessors, hiding a shorter path that is actually driving completion.

Why DCMA Penalises Hard Constraints

The DCMA 14-point schedule assessment includes a check for “Constraints” (point 8). It flags any activity with a constraint other than “Start On or After” (which is allowed for external dependencies) or “As Late As Possible” (which is discouraged). Hard constraints (Mandatory Start/Finish, Finish On, Start On) are considered high risk because they prevent the schedule from responding to delays. A schedule with more than 5% of activities having such constraints fails this check. The GAO schedule guide also warns against using mandatory constraints except for truly immovable dates (e.g., regulatory deadlines).

Using too many constraints also undermines forensic delay analysis. When a baseline has hard constraints, it is difficult to determine if a delay was caused by logic or by the constraint overriding the float. For this reason, many owners and agencies require constraint-free schedules or limit them to specific milestones.

When a Constraint Is Justified vs. When to Use Logic Instead

Justified Uses of Constraints

• Contractual milestones: A “Finish On or Before” on a project completion milestone is acceptable if the date is fixed in the contract.
• External dependencies: A “Start On or After” for a task that cannot begin before a permit is issued (where the permit date is known).
• Weather windows: In offshore or winter work, a “Start On or After” may reflect seasonal constraints.

When to Use Logic Instead

• Internal dependencies: Instead of constraining a task to start after a date, add a predecessor relationship (e.g., finish-to-start with a lag) to reflect the actual sequence.
• Resource constraints: Do not use date constraints to simulate resource availability; use resource calendars or activity codes.
• Management reserve: Do not use constraints to hold schedule contingency; model it with a dummy activity or a separate float path.

A good rule of thumb: if the constraint is not driven by an external, non-negotiable date, model it with logic. This keeps the schedule dynamic and responsive to changes.

How to Audit Constraints in Your Schedule

You can easily identify all constraints in Primavera P6 by running a report or using the “Schedule” log. Look for activities with a constraint type other than “Start On or After” (if justified) and check the constraint date against the calculated dates. A large discrepancy indicates a potential logic gap.

For a quick, free check, you can use Project Assure, a browser-based tool that parses your XER file locally and runs DCMA 14-point checks, including the constraints test. It highlights every constrained activity and shows whether it passes the threshold. No upload required – your data stays in your browser.

Best Practices for Constraint Management

• Limit constraints to less than 5% of activities (DCMA threshold).
• Document the justification for every constraint in the activity’s notes or a separate field.
• Review constraints during every schedule update – remove those that are no longer needed.
• Use “Finish On or Before” instead of “Mandatory Finish” for milestones to preserve float.
• Never use “Mandatory Start” or “Mandatory Finish” on non-milestone activities.

By understanding how constraints interact with float and the critical path, you can build a more robust, defensible schedule that passes DCMA reviews and supports reliable delay analysis.