Oracle Primavera P6 constraints are vital for reflecting real-world boundaries, but their use can inadvertently lead to manipulated outcomes. While they should represent genuine contractual or physical limits, improper application can mask poor logic and distort the critical path.
To build a defensible schedule, a scheduler must master the fine line between legitimate application and artificial manipulation.
In P6, a constraint is an externally imposed date or condition that overrides or limits the natural calculation of an activity’s early or late dates. Constraints are applied at the activity level and interact with the scheduling engine during the forward and backward passes of the Critical Path Method (CPM) calculation. P6 offers several constraint types, each with distinct behavior; see Table 1.
Table 1 – P6 Constraints
| Type | Abbreviation | Pass Affected | Effect |
| Start On | SO | Both | Forces an early start and a late start to equal the specified date |
| Start On or Before | SOOB | Backward | Caps the late start; activity cannot start later than the date |
| Start on or After | SOOA | Forward | Sets a floor on the early start; activity cannot start earlier than the date |
| Finish On | FO | Both | Forces early finish and late finish to equal the specified date |
| Finish On or Before | FOOB | Backward | Caps the late finish; activity must finish no later than the date |
| Finish On or After | FOOA | Forward | Sets a floor on the early finish; activity cannot finish earlier than the date |
| As Late As Possible | ALAP | Backward | Delays the activity as late as possible within available float |
| Mandatory Start | MS | Both | Overrides both early and late start; most aggressive start constraint |
| Mandatory Finish | MF | Both | Overrides both early and late finish; most aggressive finish constraint |
Each constraint type interacts differently with the CPM forward and backward pass. A SOOA constraint affects only the forward pass (early dates), while an FOOB affects only the backward pass (late dates). Mandatory Start (MS) and Mandatory Finish (MF) override both passes and are therefore the most schedule-distorting of the available types.
Legitimate Uses of Constraints
There are well-defined situations in which constraints are not only appropriate but necessary to accurately represent project reality, so constraints are not inherently problematic. Some legitimate applications include:
Contractual Milestone Dates
The most common and most defensible use of constraints is to reflect binding contractual commitments. If a contract requires Substantial Completion by a fixed calendar date, applying a FOOB on the Substantial Completion milestone ensures the schedule reflects that obligation. The constraint communicates to stakeholders that this date is not flexible, which is more definitive than a CPM finish calculated from current logic.
Permit and Regulatory Restrictions
Regulatory permits often specify windows during which work may or may not occur. A SOOA might be applied to activities that cannot begin until an environmental permit is issued. A FOOB date might reflect a requirement to complete outdoor construction near a nest site before eagle nesting season begins. These are real-world boundaries that network logic alone cannot capture.
Seasonal or Physical Access Windows
On infrastructure or energy projects, activities may be constrained by weather windows, navigation seasons or access road availability. Applying a SOOA on offshore installation activities to reflect the start of an acceptable weather window, or a FOOB to reflect the end of that window, is a legitimate representation of reality. These constraints mirror conditions that exist entirely outside the project team’s control.
Owner-Furnished Equipment and Long-Lead Items
When owner-furnished equipment has a confirmed delivery date, an SOOA on the installation activity accurately reflects the dependency on that delivery. If the equipment is under a separate procurement contract with a committed ship date, this constraint defines the interface boundary between the P6 schedule and the vendor delivery schedule.
Table 2 below summarizes these legitimate use cases and the appropriate constraint type for each scenario:
Table 2 – Constraint Usage
| Scenario | Recommended Constraint | Rationale |
| Contract completion milestone | FOOB | Reflects binding contractual deadline without overriding early finish |
| Owner-provided site access date | SOOA | Activity cannot start until the owner fulfills an obligation |
| Environmental permit issuance | SOOA | Regulatory floor on when work may begin |
| Marks the beginning of the eagle nesting season | FOOB | Regulatory ceiling on when work must end |
| Confirmed owner-furnished equipment delivery | SOOA | Interface boundary with a separate procurement contract |
| Weather or navigation window open | SOOA | Physical access floor is driven by external conditions |
| Weather or navigation window | FOOB | Physical access ceiling driven by external conditions |
| Project data date/schedule start | MS or SOOA | Standard practice to anchor the schedule start |
Logic Masking: When Constraints Become a Problem
Either intentional or unintentional logic masking occurs when constraints are used to substitute for missing network logic, to manufacture float, to suppress negative float or to force a schedule to appear compliant when the underlying logic does not support the planned dates.
Masking Negative Float with Mandatory Finish
One form of logic masking involves applying a Mandatory Finish (MF) constraint to a project completion milestone that already has negative float. Without the MF, the project’s late finish is driven by the backward pass from the data date or the contractual end date, and negative float signals that the current plan will not meet that date.
By applying an MF on or before the required completion date, the scheduler forces the late dates to align with the constraint, suppressing negative float across predecessor activities and making a schedule in distress appear on track.
This practice has a particularly negative impact on contract environments, where negative float triggers an obligation to submit a recovery schedule. By masking the float, the contractor avoids that obligation—but only on paper. The project is still behind; the schedule simply does not show it. The better alternative is to submit a recovery plan.
Replacing Logic with Constraints
Another form of logic masking occurs when SOOA constraints are applied to activities instead of modeling the actual predecessor relationships. For example, if Activity B cannot start until Activity A is complete, the correct logic is a Finish-to-Start relationship between A and B.
If instead a SOOA is applied to Activity B to reflect the expected finish date of Activity A, the link between the two activities is broken. If Activity A slips, the schedule will not automatically push Activity B’s early start later; the constraint will hold B in place, so the delay in A is not shown downstream.
This is a common problem in large programs where schedulers inherit incomplete schedule networks. Rather than taking the time to build proper logic to drive each task’s start and finish dates, constraints are used as a shortcut. The result is a schedule that is unusable for dynamic forecasting because the activities do not interact.
The table below contrasts each masking pattern with the correct alternative:
Table 3 – Logic Masking and Corrections
| Masking Pattern | Constraint Misused | Correct Alternative |
| Suppressing negative float | MF | Allow negative float to surface; submit recovery schedule if required |
| Replacing predecessor logic | SOOA in lieu of FS link | Build a proper Finish-to-Start or other relationship |
Identifying and Auditing Constraint Use
Responsible schedule quality reviews, whether conducted internally or by an owner’s scheduler or independent reviewer, should always include an audit of constraints. Key audit indicators of logic masking include:
- High constraint density. The Defense Contract Management Agency’s (DCMA) 14-Point Assessment guidelines suggest that no more than 5% of activities should carry constraints (excluding the project start milestone). Schedules with 20% or higher constraint rates almost always contain significant logic masking.
- Mandatory constraints in the body of the schedule. Mandatory Start (MS) and Mandatory Finish (MF) are rarely justified outside the project start milestone.
- Constrained activities with missing relationships. Activities carrying constraints but lacking predecessors or successors are a strong signal that constraints are substituting for logic.
- SOOA dates that coincide with a predecessor’s early finish. This is the classic tell-tale sign that a Finish-to-Start relationship has been replaced by a constraint.
- Constraint dates that shift between updates. Legitimate constraints reflect external obligations and should not move. Constraints that drift with the schedule reflect more on cosmetics than on reality.
Table 4 lists audit flags and the likely issue.
Table 4 – Audit Flags and Issues
| Audit Flag | Threshold / Indicator | Likely Issue |
| Constrained activity ratio | > 5% of total activities (DCMA) | Widespread logic substitution |
| Mandatory Finish on non-milestone activities | Any occurrence | Float suppression |
| Activities with constraints but no predecessors | Any occurrence | Missing open-end logic |
| SOOA date equals predecessor’s early finish | Any occurrence | Relationship replaced by constraint |
| Constraint dates are changing each update cycle | Any occurrence | Schedule managed by appearance |
P6 makes it straightforward to produce a constraint Activity Table filtered for activities where the Primary Constraint or Secondary Constraint field is not empty. Reviewing this list alongside the schedule’s baseline and current logic is a helpful step in any meaningful schedule audit.
Best Practice Guidance
The guiding principle for constraint use should be this: every constraint in a schedule must be traceable to a documented, external obligation. If a constraint cannot be explained by a contract clause, a permit condition, a regulatory deadline, or a physical access limitation, it should be replaced with appropriate network logic.
Schedulers should:
- Default to logic rather than constraints whenever a dependency exists between activities within the contractor’s control.
- Document the basis for every constraint in the activity’s notebook or in a constraint register, identifying the source document or condition that justifies it.
- Prefer SOOA and FOOB as constraint types when external dates must be modeled, as they are one-directional and least disruptive to the CPM calculation.
- Reserve Mandatory Start (MS) for the project start milestone only, and avoid Mandatory Finish (MF) in virtually all circumstances.
- Review constraints at each schedule update to confirm they remain valid and have not become stale, meaningless artifacts from earlier planning phases.
.
Summary
Primavera P6 constraints are a legitimate and sometimes essential scheduling tool, but they must be applied with discipline to accurately communicate project boundaries and contractual obligations.
When applied carelessly or misused, they reduce the schedule to a presentation document rather than a dynamic management tool.
Quality schedules are properly documented and presented, so all stakeholders understand the true scheduling situation; transparency is a key attribute of a quality schedule.