Constraints and calendars
Last reviewed 9 September 20261,657 words8 min read
The two things that quietly break float
🟩 In one line: A constraint replaces logic with a date and a calendar replaces the project's working pattern with a local one — both change float without changing a single relationship, so both must be justified individually, listed in the narrative, and checked every time the float on a path does something you can't explain.
👤 Who this is for: J/M. Read p6-constraint-types and calendar-setup-and-holidays first; this page is about how the two interact and what to check when float misbehaves.
First, let's be honest about why this page exists
When float looks wrong, the planner's first instinct is to look at the logic. Nine times out of ten the logic is fine and the culprit is a constraint someone added in month three, or an activity that got assigned the wrong calendar when it was copied from another project. Neither shows in the Gantt chart. Both change the dates.
This page is a diagnostic. It exists so that when a reviewer says "why does this path have 40 days float?" you have a five-minute routine instead of a five-hour hunt.
🟨 The standard — what "good" looks like
| Source | What it says (paraphrased) |
|---|---|
| DCMA 14-Point — Metric 5 (Hard Constraints) | No more than 5% of incomplete activities may carry hard constraints (Mandatory Start/Finish, Start On, Finish On). Soft constraints are permitted but should be justified. |
| DCMA 14-Point — Metric 12 (Critical Path Test) | The completion date must respond to a change on the critical path. Constraints and calendar mismatches are the two commonest reasons it doesn't. |
| GAO Schedule Assessment Guide — Best Practices 3 and 7 | Constraints must be justified and documented; calendars must reflect actual working conditions; float must be reasonable and explainable. |
| AACE RP 49R-06, Identifying the Critical Path | Constraints and calendars can both create or destroy float on the driving path; the analyst must account for them when identifying the longest path. |
| FIDIC 2017 Cl 8.3 | The programme must show the logic and float; a programme whose dates are held by constraints rather than logic does not meet this requirement. |
| NEC4 Cl 31.2 | The programme must show the order and timing of operations and float; constraints substituting for logic are grounds for non-acceptance. |
🟢 Rule: two constraint types only (Start On or After for access and deliveries, Finish On or Before for contract milestones), the minimum number of calendars, and a constraint register plus calendar list in every narrative.
How it actually works
1. What each one does to float.
| Change | Effect on early dates | Effect on late dates | Float effect |
|---|---|---|---|
| Start On or After | Pushes early start later if logic would allow earlier | None | Reduces float on that activity and upstream; can create float downstream that wasn't there |
| Finish On or Before | None | Caps late finish | Reduces float on that activity and all predecessors; source of negative float |
| Mandatory Start / Finish | Overrides logic both ways | Overrides logic both ways | Breaks float calculation: predecessors and successors both calculate against a fixed point; negative float upstream while downstream shows positive |
| Start On / Finish On | Fixes early and late | Fixes early and late | Zero float on the activity regardless of logic; upstream may go negative while the activity itself reads 0 |
| As Late As Possible | Delays early start to consume free float | None | Free float goes to zero; hides driving relationships |
| Calendar with fewer working days than successors | Later finish | — | Adds float to predecessors on longer calendars (weekend effect) |
| Calendar with more working days than successors | Earlier finish | Later late finish | Same effect, opposite direction |
| Wrong calendar (e.g., office 5-day on a site activity) | Wrong dates in both directions | Wrong dates in both directions | Float on the whole chain is unreliable |
2. The five-minute check when float looks wrong.
| Step | Where in P6 | What you're looking for |
|---|---|---|
| 1 | Add columns: Primary Constraint, Primary Constraint Date, Secondary Constraint, Calendar | Any constraint other than the two allowed; any calendar you don't recognise |
| 2 | Filter: Primary Constraint is not null | Count against DCMA 5%; check each against the constraint register |
| 3 | Group by Calendar | More than four or five calendars is a warning; any activity on a calendar that doesn't match its trade is an error |
| 4 | Tools → Schedule → Log (tick "Log to file") | The scheduling log lists constraints applied and activities with no predecessors or successors |
| 5 | Add 30 days to the suspect activity, reschedule, look at completion | If completion doesn't move by 30 days, something between it and completion is holding the date — constraint or calendar |
3. The interaction that catches people. A Finish On or Before constraint on a milestone measured in the project's 6-day calendar, with a curing activity on a 7-day calendar immediately before it, produces different negative-float readings on the two activities for the same delay. Report the float on the milestone, not the curing activity. See multiple-calendars-and-float.
4. The constraint register. Every constraint in the submitted schedule goes in a table in the narrative: activity ID, constraint type, date, reason, document reference (access letter, LOI, contract clause). If you can't fill in the reference column, remove the constraint.
5. Calendars on relationships. The lag calendar setting (Tools → Schedule → Options → General) is a third source of surprises. Predecessor calendar is the sensible default. See calendar-on-relationship-lag.
🟥 Where people go wrong
- Adding a constraint to fix a date. The date is wrong because the logic or duration is wrong. A constraint hides the cause and creates float that isn't real.
- Copying activities between projects without checking the calendar. The copied activity brings its source calendar. Six months later the plaster crew is on a 5-day office calendar and nobody knows why the chain has float.
- Mandatory constraints on milestones "to make them fixed". Mandatory breaks the float calculation on both sides. Finish On or Before holds the late date and lets the float show the truth.
- Not listing constraints in the narrative. Reviewers find them anyway and assume you were hiding them.
- Setting the project default calendar and forgetting it. New activities inherit it. If the default is a 5-day calendar on a 6-day job, every activity added in a hurry is wrong.
- Assuming the scheduling log is for troubleshooting only. It should be read every update. It's the fastest list of constraints, open ends and out-of-sequence activities P6 produces.
⚖️ When you're challenged
"Why does this chain have 38 days float when it feeds the critical milestone?" Because the mobilisation activity at the head of it carries a Start On constraint from the tender programme that was never removed. With the constraint deleted and the access date modelled as Start On or After, the float is 4 days. Corrected in this update and listed in the change table.
"You have nine constraints. The spec allows 5%." Seven are Finish On or Before against Section completion dates in the Appendix to Tender; two are Start On or After against the free-issue delivery dates in the Employer's letter of 12 March. The register is in Appendix B with the reference for each. None is a hard constraint under DCMA Metric 6.
"Just put everything on one calendar and the float will make sense." It will read consistently and be wrong for curing, for the consultant's review periods and for the night-shift work in July. I'd rather keep four calendars I can justify and report the float at the milestone.
📄 Related pages
- P6 Constraint Types — the full list and what each one does.
- Calendar Setup and Holidays — building the calendar set.
- Multiple calendars and float — the float distortion in detail.
- Calendar on Relationship Lag — the third calendar setting.
- Negative float — mostly produced by Finish On or Before constraints.
- How to review a schedule — where this check sits in the review sequence.
- DCMA 14-point assessment — Metrics 6 and 12.
✏️ Worked example
A logistics warehouse in Jeddah, Update 05. Reviewer's comment: "Path from steel erection to roof cladding shows 31 days float; expected near-critical."
| Step | Finding |
|---|---|
| Columns added | Steel erection zone B: Primary Constraint = Start On, 14 Sep 25. Calendar on roof cladding = "Office 5-day". |
| Constraint register | Start On on zone B was added in Update 02 "to reflect crane availability". No document reference. Crane availability was already modelled as a resource dependency. |
| Calendar check | Roof cladding was copied from a template project; the template default was the 5-day office calendar. |
| Fix | Constraint removed; cladding moved to the 6-day site calendar. |
| Result | Path float 31 days → 6 days. Completion date unchanged. Both changes listed in the update change table with the Schedule Comparison report attached. |
Neither error had moved the completion date, which is why nobody caught them for three updates. Both would have hidden a real delay on that path when it came.
📖 References
- DCMA 14-Point Schedule Assessment — Metrics 6 and 12.
- GAO-16-89G, Schedule Assessment Guide — Best Practices 3 and 7.
- AACE International RP 49R-06, Identifying the Critical Path.
- FIDIC Conditions of Contract for Construction, 2017 — Cl 8.3 (check the edition in your contract).
- NEC4 ECC — Cl 31.2 (check the edition in your contract).
- Oracle Primavera P6 Professional User Guide — Constraints; Calendars; Schedule Log.
From the field
Experience from working planners. Unreviewed — read it as experience, not guidance.
Add what you know about constraints and calendars. What worked, what the consultant pushed back on, what you would do differently next time. A paragraph is plenty.
Contributors get their name and one link on the site — your own templates, course or consultancy. We take nothing and hold nothing.
Add your experience