P6 Constraint Types
Last reviewed 16 September 20269 min read
All eight, and the two that are acceptable
π© In one line β P6 offers eight date constraints plus As Late As Possible; on a live contractual schedule you should be using two of them β Start On or After for things that genuinely can't begin before a date (access, permits, deliveries), and Finish On or Before on contractual milestones so a late finish shows as negative float instead of a moved date. Everything else replaces logic with a typed date and should be gone before submission.
π€ Who this is for β Juniors who've found the Constraints box and are wondering which one "holds the date", and mid-level planners cleaning a schedule for review. You should already understand total float and how a forward and backward pass works.
First, let's be honest about why this page exists
Constraints are the fastest way to make a schedule look right and be wrong. A PM says "completion has to be 30 June", the planner puts Mandatory Finish on the milestone, and the bar sits on 30 June for the rest of the project no matter what happens upstream. Everyone's happy until the delay analyst finds the completion milestone has predecessors finishing in August.
The other reason this page exists is that even experienced planners mix up which constraints touch early dates, which touch late dates, and which ignore the network entirely. That's the whole story: a constraint is a typed date that overrides part of the CPM calculation, and the question is always which part.
π¨ The standard β what "good" looks like
| Standard | What it says |
|---|---|
| DCMA 14-Point, Metric 5 (Hard Constraints) | No more than 5% of incomplete activities may carry a hard constraint. DCMA's "hard" list maps to P6's Mandatory Start, Mandatory Finish, Start On, Finish On, and the two "On or Before" types. Check which set the client's checker counts β some only count Mandatory. |
| GAO Schedule Assessment Guide, Best Practice 2 | Constraints should be minimised, each one justified, and the justification documented; dates should come from logic. |
| PMI Practice Standard for Scheduling | Constraints are a schedule model component to be used sparingly and recorded with their reason. |
| AACE RP 49R-06 (Identifying the Critical Path) | Constraints distort the critical path; the analyst must identify and account for them. |
| NEC3/NEC4 Cl 31.2 | The programme shows the Completion Date, Key Dates and Sectional Completion β the legitimate targets for a Finish On or Before. |
| FIDIC 1999/2017 Cl 8.2 | Time for Completion (and Sections) β same purpose. |
π’ Rule to remember: two constraints on a live schedule β Start On or After for reality, Finish On or Before for the contract β and a written reason next to every one.
How it actually works
Activity Details β Status tab β Constraints. Primary and Secondary. A constrained date shows an asterisk after it in the date columns. To find them all: filter on Primary Constraint is not equal to (none).
| Constraint | What it overrides | Float behaviour | Verdict |
|---|---|---|---|
| Start On or After | Early start can't be before the date | Creates positive float upstream if logic finishes earlier; no effect on late dates | β Use for access dates, permit dates, confirmed deliveries, seasonal windows |
| Finish On or Before | Late finish can't be after the date | Produces negative float if logic pushes past the date; early dates untouched | β Use on contractual milestones only β completion, sections, Key Dates |
| Start On or Before | Late start can't be after the date | Negative float if late | β οΈ Rarely needed; usually a Finish On or Before on the predecessor milestone is clearer |
| Finish On or After | Early finish can't be before the date | Positive float, delays successors | β οΈ Occasionally for "not earlier than" handovers; usually better as a milestone with SOoA |
| Start On | Both early and late start pinned | Zero float at the activity; negative if logic is later | β Hides logic; reviewers treat as hard |
| Finish On | Both early and late finish pinned | Same | β Same |
| Mandatory Start | Ignores predecessors entirely; early = late = date | Breaks float continuity; successors may start before predecessors finish; can sit on a non-work day | β Never on a contractual programme |
| Mandatory Finish | Pins early finish = late finish = the date, regardless of logic | Total float on the constrained activity itself reads zero, not negative. Predecessors in conflict with it should show negative float β but the constraint blocks float propagating back through it from anything further downstream, so a second, tighter constraint later in the network becomes invisible upstream | β Never |
| As Late As Possible | Schedules the activity as late as its free float allows (P6 uses free float here, not total) | Removes the activity's float; any predecessor slip becomes critical | β οΈ Only for just-in-time deliveries where storage is impossible, and only with the reason written down |
Three behaviours worth having in your head:
"On or After" pushes early dates; "On or Before" pulls late dates. That's why one creates float and the other creates negative float. Neither of them moves a bar off its logic β they just tell you when logic and target disagree.
Mandatory constraints don't tell you anything. They set the dates and stop. The schedule log won't warn you that predecessors finish later. The only symptom is a successor starting before its predecessor ends, which looks exactly like out-of-sequence progress and gets blamed on the site.
The project-level alternative. Projects β Dates tab β Must Finish By. It behaves like a Finish On or Before on the whole project and drives the backward pass. Many planners prefer it to constraining the completion milestone because it can't be accidentally deleted with the activity. Either works; using both on the same date is harmless, using them on different dates is confusing.
Bulk removal. Tools β Global Change: Primary Constraint = (none) with a filter for the ones you want gone. Run it on a copy first, and export the list of constraints before you do β the reasons behind some of them may be the only record of an access date.
π Constraints and the contract
A Finish On or Before on the Time for Completion (FIDIC Cl 8.2) or the Completion Date (NEC Cl 31.2) is not just acceptable β it's how the programme shows whether you're meeting the contract. When the network pushes past it, the negative float is the size of the problem, and under NEC that number feeds directly into what the Project Manager sees when judging whether the programme "shows the information which the contract requires" (Cl 31.3).
A Start On or After on an access date is your record that the Employer promised the site on that day. If the constraint is on the activity with a note saying "Access to Zone C per Cl 2.1 β 15 March", you have half an EOT notice already written.
π₯ Where people go wrong
- Mandatory Finish on completion "to hold the date". It holds the bar, not the date. The predecessors run past it and the milestone itself still reports zero float, because the constraint pins its early and late finish to the same date. Worse, it blocks negative float propagating back through it from anything further downstream. When the reviewer finds it, every date in the file is suspect.
- Start On or After as a substitute for logic. The planner doesn't know what drives the start of external works, so pins it to 1 October. Logic gets fixed later; the constraint doesn't get removed; in month 14 the external works still can't start before 1 October even though the building's a month ahead.
- Constraints imported from a subcontractor's programme. Their file arrives with 300 Start On constraints because their planner typed dates. Merged into yours, the network is now a list. Strip them before import β see cleaning-an-xer-before-import.
- As Late As Possible on anything that isn't a delivery. Someone reads that ALAP "optimises cash flow" and applies it to procurement. Every submittal now sits with zero float and the first slip goes critical.
- No reason recorded. A constraint without a note is a constraint that can't be defended or safely removed. Notebook topic "Constraint Basis", one line.
- Stripping all constraints before review to pass the metric. The DCMA count drops to zero and the access dates disappear with it. Now the schedule shows work starting on land you don't have yet. The metric is a prompt to justify, not a target of zero.
βοΈ When you're challenged
"Why does the finish milestone show minus 18 days? Just fix the date." "The minus 18 is the fix working. The milestone has a Finish On or Before on the contract date, and the network is currently 18 days past it. If I pin the milestone with a Mandatory Finish, the 18 days doesn't go away β it just stops being visible. What we need is 18 days of recovery, and I can show you where it can come from."
"You have 40 constraints. The spec says maximum 5%." "Thirty-one are Start On or After on access and delivery dates, each with the source noted β those are the Employer's obligations, and the reviewer will want to see them. The other nine are contractual milestones with Finish On or Before. None are mandatory. If the client's checker counts On-or-Before as hard, I'll move the completion target to Must Finish By at project level and we're at 31, all soft."
"Can you put a constraint on the pour so it doesn't move every month?" "I can, but then it'll stop telling you when it's going to slip. If the concern is the report, I'll add a baseline bar so you can see planned against current. If the concern is the date, the answer is in the predecessors, not a pin."
π Related pages
- Negative float β what the β43 means and how to report it
- Constraints and calendars β the two things that quietly break float
- Milestones and Key Dates β which milestones deserve a Finish On or Before
- Out-of-sequence progress β the symptom mandatory constraints imitate
- DCMA 14-point assessment β Metric 5 and how checkers count it
- Cleaning an XER Before Import β stripping a subcontractor's constraints
- P6 Global Change β bulk removal, done carefully
- Extension of Time Basics β the access-date constraint as the start of a notice
βοΈ Worked example
Podium and tower, Sharjah. Contract completion 30 June. The completion milestone had a Mandatory Finish on 30 June when the schedule came in for review.
| Activity | Early Finish (logic) | Constraint | Total Float shown |
|---|---|---|---|
| FaΓ§ade complete | 22 July | none | negative β see note |
| MEP T&C complete | 8 August | none | negative β see note |
| Authority final inspection | 19 August | none | negative β see note |
| Completion milestone | 30 June | Mandatory Finish | 0 |
The milestone reads zero float while sitting seven weeks before its own predecessors finish. That is the whole problem: the one number a reviewer sorts by says the completion milestone is fine.
β οΈ A note on the predecessor float, because precision matters here. Published sources agree that a Mandatory Finish pins early finish = late finish on the constrained activity, giving it zero total float, and that it breaks the network logic. They do not fully agree on the magnitude of negative float it leaves on predecessors, and the answer shifts with the P6 version and with how Compute Total Float as is set (Start Float / Finish Float / Smallest of Start and Finish Float) in Tools β Schedule β Options. Rather than quote a figure we cannot stand behind, the table says "negative".
The five-minute test, if you want the answer for your own configuration. Build four activities in series, 10 days each, no constraints β note the float. Put a Mandatory Finish on the last one, dated 20 days before its logic finish. Reschedule. Read the total float on all four. Then change Compute Total Float as and reschedule again. Do it once and you will never have to look it up. If you run it, send us the result and we will publish it with your name on it β hello@gridopedia.com.
The point of the example stands either way, and it is not about the magnitude: a constraint that makes the completion milestone report zero float while its predecessors run into August is a constraint that has disabled your only early-warning signal.
Same schedule with the constraint changed to Finish On or Before 30 June:
| Activity | Early Finish | Total Float shown |
|---|---|---|
| FaΓ§ade complete | 22 July | β19 |
| MEP T&C complete | 8 August | β34 |
| Authority final inspection | 19 August | β43 |
| Completion milestone | 19 August | β43 |
Now the milestone sits where the logic puts it, the float column says the project is 43 working days late, and the path with the most negative float β through T&C and inspection β is the one to recover. Same network, same dates, one change in the constraint type; the second version is the one that can be managed.
Two Start On or After constraints stayed in: "Access to substation plot β 12 Feb (Employer, Cl 2.1)" and "Chiller delivery ex-works β 4 May (PO 0417)". Both have notebook entries. Total: 3 constraints on 1,900 activities.
π References
- DCMA 14-Point Assessment, Metric 5 (Hard Constraints)
- GAO Schedule Assessment Guide (GAO-16-89G), Best Practice 2
- PMI, Practice Standard for Scheduling β schedule model components, constraints
- AACE International RP 49R-06, Identifying the Critical Path
- NEC3/NEC4 ECC Cl 31.2, 31.3; FIDIC 1999/2017 Cl 2.1, 8.2 (check the edition in your contract)
- Oracle Primavera P6 Professional User Guide β Constraints, Project Dates (Must Finish By), Global Change
From the field
Notes, corrections and additions from people who've done this on a real job. Everything is checked before it appears here.
Loading notesβ¦
Checked before it appears. No client, project or employer names. Your name is shown; your email never is. Terms.