Resource-Loaded, Shift and Outage Schedules

A refinery turnaround, a nuclear outage, a plant shutdown and a two-shift civil pour have one thing in common. The unit of work is not a working day. It is a shift, a window, or a clock that runs through the weekend. Feed that schedule to a tool that assumes eight hours and Monday to Friday and the arithmetic goes wrong in a way nobody notices, because the answer still looks like a date.

The failure is rarely dramatic. It is a 10-hour shift treated as an 8-hour day, so every duration reads 25 percent short. It is a 24-hour continuous calendar divided by 8, so a lag inflates by 200 percent. It is a four-hour lag rounded up to a full day, fifty times over, and a finish date that drifts weeks from what the planning tool says. On a claim, that drift is the first thing an opposing expert finds, and once found it contaminates everything downstream of it.

Our position is the unglamorous one. Name the limit, gate it, and work inside it. The work behind this page has been construction scheduling and forensic delay analysis, and about twenty years of it has been in nuclear and energy.

Where this class of schedule actually breaks

Sub-day durations

P6 stores durations and lags in hours, not days. A turnaround schedule routinely carries two-hour isolations, four-hour lifts and six-hour tie-ins. Converted to days on an eight-hour calendar those become 0.25, 0.5 and 0.75. Any engine that works in whole days has to do something with the fraction, and every choice is lossy. Rounding half up inflates the positive lags. Rounding half to even loses the half day in the other direction. Truncating destroys short leads entirely. The honest handling is not to pick a favourite rounding rule; it is to detect the fraction, say so, and refuse to produce a court-grade number until the analyst has decided what the fraction means.

Hourly and shift calendars

A calendar is not just which days are working. It carries an hours-per-day figure, a work week, intra-day time slots with clock start and finish times, and a list of exceptions. Outage calendars use all of it: seven days a week, twelve-hour shifts, a continuous 24-hour clock on some paths, statutory holidays worked, and normally-off days switched on for the duration of the window. Two of those are traps. The first is the hours-per-day divisor, because using 8 when the calendar says 10 or 24 silently rescales every duration in the file. The second is the exception encoding, because a P6 exception that carries work hours is a modified working day, not a day off, and a parser that treats every exception as a holiday turns a continuous calendar into hundreds of phantom non-working days.

Levelled dates

Levelling is not logic. It moves work because a crew or a crane is not available, not because a predecessor said so. The engine does not perform levelling, by design, and it does not attempt to reproduce a levelled date. That is a deliberate boundary, not an omission: a resource-constrained date is the output of a heuristic with a priority rule, and reproducing somebody else's heuristic is not evidence of anything. What we do instead is read the levelled dates as recorded facts, compute the logic-driven answer separately, and treat any gap between them as a finding to explain. On a claim that gap is often the most useful number in the file, because it separates delay caused by logic and events from delay caused by resource availability, and those two things sit in very different places in a contract.

Outage and turnaround work

Outage schedules compress a year of decisions into a fixed window with a hard end date. Four features make them different from a building job. The window boundary is contractual and the clock does not stop for weekends. Durations are short, so rounding error is proportionally large. Work is often performed out of sequence when a system comes free early, and that out-of-sequence progress is real, not a modelling error. And the drivers are frequently permits, isolations, holds and system availability rather than trades. Two consequences follow for the analysis. First, the analysis window has to be the outage window, not a calendar month, or every result is smeared across the boundary. Second, a zero-resource waiting activity does not hold a date. If a system is unavailable, the gate milestone is what carries the constraint, and the way to prove which one drives is a knock-out test on the candidate driver rather than an appeal to the bar that looks longest.

The register: what the tooling models, and what it does not

This is the whole list, not a selection. Where the answer is no, the reason is stated. Where an alert is named it is the literal alert context the engine emits, so an opposing expert can filter for it in the result object.

SCHEDULE-FEATURE REGISTER  ·  20 rows  ·  scroll within the frame; the header stays fixed

End of register. 20 of 20 rows shown.

The alert, verbatim

When a fraction appears, this is the text the engine produces. It is quoted exactly, including the rounding-direction disclosure, because the wording is the disclosure.

context: SUB_DAY_LAG_ROUNDED   severity: ALERT

SUB_DAY_LAG_ROUNDED: lag/duration value 0.5 is fractional; engine
rounds to 1 day(s). V8 Math.round rounds half toward +Infinity;
sub-day lags inflate, sub-day leads truncate to zero — sub-day
precision is forensically unavailable in this engine. P6 typically
stores lags in hours; re-run with full-day lags or accept the
documented drift.

How the analysis is done correctly anyway

The limit is real and it is narrower than it first sounds. The engine's day is not eight hours by definition; it is whatever the calendar says. So a twelve-hour shift calendar carrying twelve hours per day makes one engine day exactly one shift, and a continuous calendar carrying twenty-four makes one engine day exactly one round-the-clock period. Sub-day precision is only lost when a duration or lag is not a whole multiple of the calendar's working day. That reframes the problem from "the tool cannot do shift work" to "the unit of the analysis has to be chosen deliberately, and every value has to be a whole multiple of it".

The sequence below is how that gets enforced. It is ordinary discipline rather than anything clever, and the order matters.

Resource-loaded files get verified before they are analysed

A resource-loaded export has a specific failure mode that has nothing to do with dates. Remaining durations reset to zero the first time the file is scheduled. It happens because the planning tool recomputes remaining duration from remaining units, so if a generated file ships with a blank or zero remaining quantity, a units-driven duration type, or missing remaining fields, every remaining duration collapses on the first schedule run and the file is worthless after import. It is the kind of defect that lives in nobody's checklist, which is why it kept recurring until it was scripted.

So every loaded file, whether it was generated here or received from someone else, is run through verify_loaded_xer.py before any analysis. The script exits zero or the file does not move. It checks five things.

1. Duration type. Every activity must be fixed duration. Any units-driven type lets the planning tool recompute duration from remaining units, which is the root cause of the reset.
2. Remaining equals original on not-started activities. A mismatch is a failure unless the activity code is explicitly listed as an accepted compression, in which case it is recorded as a warning with an "allowed" marker rather than hidden.
3. Remaining early dates are populated on every not-started activity. A missing remaining start or remaining finish is a failure.
4. Assignment-level remaining fields. On every assignment against a not-started activity, remaining quantity must equal original quantity within 0.005 units, and remaining cost must equal original cost within half a cent. A zero or blank remaining quantity is flagged in the output as the classic reset trigger. Remaining units per hour must be above zero wherever remaining quantity is above zero, and every actual quantity and cost field must be zero.
5. Orphan and total checks. An assignment pointing at an activity that is not in the file is a failure. Where an expected loaded total is supplied, the sum of assignment costs is compared to it within half a cent, so a penny-level drift in the loading cannot pass unnoticed.

What we will not claim

Four things, stated plainly, because a capability page that only lists strengths is not useful to anyone deciding whether to hire.

1. The engine does not model sub-day work. It is day granular. Fractions round, and the rounding is disclosed and fatal in strict mode. If a matter genuinely turns on hour-level sequencing inside a shift, that analysis is done against the native planning tool's own output and the engine is used for the day-level questions only.
2. The engine does not level resources. It will not reproduce a levelled date, and it does not try to. It reports the logic answer and the gap.
3. Strict mode does not make an override correct. It enforces that the override was written down with a reason. Whether the reason holds up is the analyst's burden, not the tool's.
4. Passing the gate is not the same as being right about the project. The observed error rate on the published validation suite describes the computation, not how well the schedule represents what happened on site. That second question is answered with records, and it is where the real work is.