Calendar on Relationship Lag
Last reviewed 9 September 20261,612 words7 min read
The setting that silently shifts dates
🟩 In one line — Tools → Schedule → Options → Calendar for scheduling Relationship Lag decides whether a 7-day lag means seven working days or seven calendar days; it defaults to the predecessor's calendar, applies to every lag in the project, and on a 6-day site a curing lag of FS+7 quietly becomes 8 calendar days per floor — so check it on every file you receive, and turn any lag that needs a different calendar into an activity.
👤 Who this is for — Anyone who uses lags, which is everyone. You should know what a lag is and why leads-and-lags says to use them sparingly.
First, let's be honest about why this page exists
This is a one-line setting in a dialog most planners open twice a year. It isn't visible on the Gantt, isn't in the activity table, and isn't obvious from the dates. But every lag in the file obeys it, and on a 24-storey tower with a curing lag per floor the difference between settings is over three weeks on the critical path. It's the definition of a setting that silently shifts dates: nobody typed a different number, and the completion moved.
🟨 The standard — what "good" looks like
The standards say little about the setting itself and a lot about the underlying problem:
- DCMA 14-Point, Metric 3 (Lags) — no more than 5% of relationships with lag; lags should be justified.
- GAO Schedule Assessment Guide, Best Practice 2 — lags should represent real waiting time, be documented, and not substitute for activities.
- AACE RP 24R-03 (Developing Activity Logic) and RP 49R-06 — lags obscure the critical path and should be minimised; the calendar assumption behind a lag must be stated.
- PMI Practice Standard for Scheduling — lag is a schedule model attribute whose basis should be recorded.
🟢 Rule to remember: one setting governs every lag — so if two lags need two calendars, one of them should be an activity.
How it actually works
Tools → Schedule → Options → General tab → Calendar for scheduling Relationship Lag. Four choices:
| Option | The lag is counted on | Typical consequence |
|---|---|---|
| Predecessor Activity Calendar (default) | The calendar of the activity the lag comes from | FS+7 after a pour on a 6-day calendar = 7 working days = 8 calendar days |
| Successor Activity Calendar | The calendar of the activity being delayed | Useful when the successor is on 7-day and the predecessor isn't |
| 24 Hour Calendar | Continuous time | FS+7 = 7 calendar days always; SS+3 "three working days after" becomes 3 calendar days |
| Project Default Calendar | Whatever is set in Project Defaults | Whatever that happens to be — usually nobody knows |
Two things make this dangerous:
It's project-wide. You can't say "curing lags on 24-hour, overlap lags on site calendar". Every lag gets the same treatment. A schedule with both kinds — and almost every schedule has both — is wrong for one of them whichever option is chosen.
It travels with the XER but not with attention. The setting is stored in the project's schedule options, so the file you receive carries the sender's choice. It also prints in the schedule log (Tools → Schedule → View Log), which is where a reviewer can prove what was set on the day the dates were calculated.
Hours, not days. P6 stores lag in hours. A lag typed as "7d" becomes 70 hours on a 10-hour calendar or 168 hours on the 24-hour one. Change the option after the fact and the same stored hours are now counted on a different calendar — the displayed "7d" may become "8.75d" or "2.9d". This is why the setting should be decided at setup and left alone.
The fix that avoids the setting. Make the waiting time an activity with its own calendar: Pour L14 → Cure L14 (7 days, 7-day calendar) → Strip L14. It costs one activity per floor. In return the cure is visible, has its own float, can be statused, and doesn't care what the option says. Use lags only for overlaps between two activities on the same calendar, where the default (predecessor) option is correct.
🟥 Where people go wrong
- Never opening the dialog. The file was built on a template with 24 Hour selected because the last project was a shutdown. Every SS+2 overlap between site activities is now two calendar days, and every third one spans a Friday and becomes one working day.
- Curing as a lag on the default setting. FS+7 on a 6-day predecessor: 8 calendar days per floor, 24 floors, and the tower tops out three and a half weeks later than the cycle time says. The client asks why the floor cycle is 8 days when the method statement says 7.
- Changing the option mid-project to "fix" one lag. All the other lags move. The monthly update now has a completion date change with no progress cause, and the narrative has to explain it.
- Assuming the receiving database is the same. It is — the option is in the project, not the database. But Admin Preferences (hours per day) differ, and if the calendar-driven Time Periods box isn't ticked at the receiver's end, the hours get displayed as different days on top of the lag calendar issue. Two silent shifts at once.
- Lags between calendars with different hours per day. A 10-hour predecessor, a lag of 2 days (20 hours), an 8-hour successor. On the predecessor calendar that's two days; expressed on the successor it's 2.5. Whichever way you look at it, one side sees a fraction.
⚖️ When you're challenged
"Your floor cycle says 7 days but the dates show 8 per floor. Why?" "The curing lag is counted on the site calendar, so it skips Friday. Concrete cures through Friday. I'll replace the lag with a cure activity on the 7-day calendar and the cycle will show 7 — it'll bring completion forward about three weeks, which is real, not a trick."
"You've changed the lag calendar setting since last month. That's a baseline change." "You're right that it moved dates, and it's declared in the narrative. Last month's file had it on 24 Hour, which was making our SS overlaps too aggressive. We've put it back to predecessor and converted the curing lags to activities so it can't happen again. The log for both months shows the setting."
"Just set it to 24 Hour so the cures are right." "That fixes the 24 cure lags and breaks the 180 overlap lags. The right answer is to make the cures activities. It's an hour's work."
📄 Related pages
- Leads and lags — why lags should be rare in the first place
- Calendar Setup and Holidays — the 7-day calendar the cure activity needs
- Scheduling options — the rest of the dialog, setting by setting
- P6 Settings That Change Your Dates — this one and its siblings in one table
- Hours per day and duration display — the second silent shift on the same file
- Multiple calendars and float — what happens to float when a path crosses calendars
- How to review a schedule — the schedule log as first-day evidence
- High rise and buildings — the floor cycle where this bites hardest
✏️ Worked example
Residential tower, Doha, 24 floors, 7-day target cycle. Slab pour on the 6-day site calendar, FS+7 lag to formwork strip for curing, strip on the same calendar. The tender template had the lag calendar on 24 Hour; the baseline planner reset it to Predecessor without checking what else it changed.
| Setting | Cure lag counted as | Days per floor cycle | Topping out (24 floors) |
|---|---|---|---|
| 24 Hour | 7 calendar days | 7 calendar days (cure spans Friday, strip resumes Saturday) | Baseline date |
| Predecessor (6-day) | 7 working days = 8 calendar days | 8 working days | +24 working days |
But under 24 Hour, the other lags on the same floors — SS+2 between column rebar and column formwork, SS+3 between slab rebar and MEP embeds — were being counted in calendar days. Roughly one in three spanned a Friday, and those overlaps were a day tighter than the method intended. That optimism was worth about 5 days over the tower, hidden inside the 24 Hour setting.
Resolution adopted for the baseline:
| Item | Before | After |
|---|---|---|
| Lag calendar option | 24 Hour | Predecessor Activity Calendar |
| Curing | FS+7 lag, 24 lags | "Cure Ln" activity, 7 days, 7-day calendar, 24 activities |
| Overlap lags (SS+2, SS+3) | Counted on 24 h | Counted on the 6-day site calendar, as intended |
| Topping out | Baseline | Baseline +5 working days — the honest number |
| Schedule log | Not kept | Attached to the narrative every month |
The five days went into the narrative as a correction to the tender programme, not a slip. Two years later, when the delay analyst rebuilt the as-planned network, the cure activities meant there was no argument about what the cycle had assumed.
📖 References
- DCMA 14-Point Assessment, Metric 3 (Lags)
- GAO Schedule Assessment Guide (GAO-16-89G), Best Practice 2
- AACE International RP 24R-03, Developing Activity Logic; RP 49R-06, Identifying the Critical Path
- PMI, Practice Standard for Scheduling — lags and schedule model attributes
- Oracle Primavera P6 Professional User Guide — Schedule Options (Calendar for scheduling Relationship Lag), Schedule Log, Admin Preferences → Time Periods
From the field
Experience from working planners. Unreviewed — read it as experience, not guidance.
Add what you know about calendar on relationship lag. 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