Scheduling & XER

Whose Calendar Does a Lag Actually Use in Primavera P6?

A finish to start relationship with a two day lag landed four days later than I expected, and nothing on the activity explained it. The answer was a project level setting most planners never open. Here is what it does, and how to check it in under a minute.

A

Ali · Founder, Plexxel 5 min read · Published August 2026

Featured image: drop a screenshot of the Schedule Comparison report here
(recommended 1200×675, 16:9)

A contractor sent me a programme where steel erection could not start until two days after the concrete cure finished. Simple enough. Finish to start, two day lag. When I opened it, the successor was starting four calendar days later instead of two, and nothing on the activity explained why.

I spent longer than I want to admit checking the relationship, then the constraint, then the successor's calendar. All three were fine. The answer sat in a dialog I had not opened in about three years.

The part I had wrong

I had always assumed a lag belongs to the successor. It feels logical. The successor is the activity being held back, so the wait should be counted in the successor's working days.

P6 does the opposite. By default, lag is measured on the predecessor's calendar.

In that programme the concrete cure sat on a seven day calendar, because curing does not stop for the weekend. Steel erection sat on the site's five day calendar. Two working days on a seven day calendar ran straight through Friday and Saturday, so the successor could not pick up until Monday. Two days of lag, four days on the wall chart, no error message anywhere.

The setting nobody opens

This is controlled by a project level scheduling option. In the XER it is one field on the SCHEDOPTIONS table:

sched_calendar_on_relationship_lag = rcal_Predecessor

In P6 you reach it through Schedule, then Options, where it reads "Calendar for scheduling relationship lag". There are four choices:

• Predecessor activity calendar. The default, and what most schedules ship with.
• Successor activity calendar. What a lot of planners assume is already happening.
• 24 hour calendar. Lag runs on elapsed time, weekends and holidays included.
• Project default calendar. One calendar governs every lag, whatever the two activities use.

All four are defensible. The trouble is that the setting lives at project level, it is invisible on the Gantt, and it travels with the file. Inherit a programme and you have inherited its lag convention too, whether anyone mentioned it or not.

When it actually bites

If every activity in your programme runs on one calendar, none of this matters. The lag lands in the same place whichever option is selected, and you can go back to your update.

It bites the moment calendars are mixed, which on a real project is most of the time:

• Curing, drying, testing and settlement periods on a seven day calendar, feeding site work on five or six days.
• Shipping and customs durations on a seven day calendar, feeding installation crews who do not work Fridays.
• Authority approval periods running on the authority's working week, feeding yours.
• Shift work on a 22 hour calendar sitting next to day work on 8.

Each of those is a spot where the same FS+2 produces two different successor dates depending on one dropdown. On a single relationship you would never notice. Across a chain of forty, the drift becomes the argument you have in month six about who caused the delay.

Checking it in under a minute

If you have P6 open, it is Schedule, Options, read the value, write it down.

If somebody has emailed you an XER and you would rather not import it yet, the file is tab separated text. Open it in a text editor, search for SCHEDOPTIONS, and read the field on the row below. You will see one of rcal_Predecessor, rcal_Successor, rcal_24Hour or rcal_ProjectDefault. That is the entire check, and it works on a file you have not yet agreed to accept.

While you are in that row, two neighbours are worth reading. sched_retained_logic and sched_progress_override decide how out-of-sequence progress gets handled, and they move dates just as quietly as this one does.

If you inherit the wrong setting

Changing it is one dropdown, but it reschedules everything, so treat it as a revision rather than a tidy up. Take a copy first. Note the project finish date before and after. If the date moves by more than a day or two, you have just learned how much of your programme was leaning on lag, which is useful information even if the news is unwelcome.

The harder case is a programme already submitted and accepted under one convention. Changing it mid project shifts dates other people have signed for. There I leave the setting alone, document it, and push for the correct one at the next re-baseline.

What I do now

I write the lag calendar setting into the schedule basis document, next to the working week and the holiday list. One line, one minute.

I also think a reviewer is within their rights to reject a programme that does not state it. That sounds heavy handed for a single dropdown. But a schedule is a model, and a model with undocumented assumptions cannot be checked by anybody except the person who built it. If two competent planners can look at the same FS+2 relationship and predict different dates, the programme is not saying what it appears to say.

The fix is not difficult. It is just invisible, and invisible is where most schedule arguments start.