Five checks on an EPC contractor's schedule before you discuss delay

Why check the schedule before talking about delay?

In shortWhen an EPC project falls behind, the contractor explains the delay through its own schedule (on large projects often kept in Primavera P6): design was late, vendors were late, owner data was late. Before discussing causes, the owner's team should check the schedule itself: does it have an agreed baseline, did the links between activities survive, and are the actual dates supported? Five such checks follow.

The situation is familiar. A milestone slips, the contractor points to engineering, to vendors or to owner-furnished information, and shows the schedule. HKA, a consultancy, keeps a database of 1,801 projects in 106 countries on which its experts investigated claims and disputes. Among the mining and metals projects in it, late design is the second most common cause of claims and disputes after change in scope: it appears in 36.1% of them, more than one in three (HKA CRUX Insight 2023, p. 40).

A PDF print will not get you far. It does not show constraints, it shows the relationships only partially if at all, and the data date is not always on it. You need the native schedule file (for Primavera, an XER export) for the baseline and for every monthly update. The SCL Delay and Disruption Protocol recommends that updates be provided "in native format, not as a PDF" and that no version be overwritten (para. 1.59). If the contract is silent on this, ask anyway. If the contractor treats resource rates and costs as commercially sensitive, they can be stripped from the export: none of the checks needs them.

You do not need your own copy of Primavera. An XER file is plain text with the tables one after another: TASK (activities and dates), TASKPRED (relationships), PROJECT (project settings). Excel or Power Query can split it into tables; the first time, that takes about an hour. Free libraries such as MPXJ and xerparser read XER files if you have an analyst at hand. The simplest route is to ask the contractor for an Excel export of activities and relationships alongside the XER, or for read-only access to P6.

If the contractor schedules in another tool, such as MS Project, Asta Powerproject or Spider Project, the checks stay the same; the file format and field names change. Ask for the native file or an XML export, and for the first check find out where the baseline is stored. The technical details below use P6 as the example.

The checks cut both ways. The same relationships that show design waiting for vendor data will also show it waiting for the owner, and it is better to find that out before the meeting. A date in a schedule is like a number in a cost estimate (see my note on estimate classes): without a basis, it is an opinion.

Check 1. Where is the baseline?

In shortThe planned dates in a working P6 schedule are not the baseline. For activities that have not started, P6 recalculates planned dates every time the schedule is run, and if no baseline is assigned it compares the project with itself. The baseline is a frozen copy of the schedule agreed by both parties. Ask for it separately and note its data date, the date as of which progress was recorded in it.

Every P6 activity carries several pairs of dates, and the names mislead. Planned Start and Planned Finish sound like the plan, but according to Oracle's documentation they are calculated by P6's scheduling engine and stop changing only once the activity has started. Planner Yaser Al-Bustanji writes on the Planning Planet blog: "Planned dates are neither static like baseline dates nor dynamic like Early and Late dates." As he shows, a manual edit of the planned start of an activity that has not started is reset the next time the schedule is calculated, "without providing any warning to the user".

A P6 baseline works differently: it is a copy of the project at a point in time. If none is assigned, Oracle's help says: "If a baseline does not exist, the current project is the default value." The variance columns then compare the schedule with itself, and for activities not yet started the variance comes out as zero. There is a second trap. The Project Baseline and the user baselines (BL1 to BL3 in the columns) are different settings, and the user baselines belong to whoever is looking at the schedule. A screenshot with BL1 columns may have been comparing the schedule with a different baseline altogether.

The US Government Accountability Office's Schedule Assessment Guide says: "The baseline schedule is not the same as the current schedule" (GAO-16-89G, p. 135). It adds that "a rebaselined schedule should be rare" and that "a schedule rebaseline normally eliminates historical variances" (p. 140). P6 also has an Update Baselines function that loads current data into a baseline without changing its name, so the owner should keep its own copy of the agreed baseline.

I once tripped over this myself. I compared key milestones with the planned dates in the working schedule and everything looked on time. The baseline told a different story. Since then my first question is which file we are comparing against.

What to do:

1. Ask for the baseline agreed by both parties in a letter or minutes. P6 does not export assigned baselines in XER format, so ask for the baseline as a separate XER, restored as an ordinary project, or for a P6 XML export, which carries baselines with the project. Note the baseline's data date.
2. Ask whether the schedule has been rebaselined. If it has, get every version and the document by which the new baseline was agreed.
3. Compare 10 to 20 key milestones: baseline date against current forecast or actual.
4. Look more closely if future milestones match the baseline to the day while neighbouring activities are clearly behind. Find out what is actually in the baseline column.

In MS Project and some other tools the baseline lives in frozen fields of the same file, and the NDIA scheduling guide allows for that: "The forecast and baseline may be captured in the same schedule or be in separate versions of the schedule depending on the tool specifics" (PASEG, section 4.4). Whether the baseline sits in a separate file matters less than whether it is frozen: it changes only through an agreed change procedure.

Check 2. Did the logic survive when the schedule was rebuilt?

In shortOn an EPC project, design activities wait for inputs: basic engineering, vendor data, site surveys, owner-furnished information. A good baseline links them. When the schedule is rebuilt, those links may not be carried over, and the schedule then shows that design is late without showing what it depended on. The check is to trace the predecessor chains of key design activities in the baseline and in the current version.

The EPC chain is standard: equipment purchase order, then vendor data (loads, dimensions, connections), then foundation, steel and services design, then construction. T. M. Corrigan, writing in the American Arbitration Association's mediation magazine, notes that the owner-approved vendor data submittal "facilitates and precedes numerous other critical path activities", and that "too often, project schedules ignore vendor data timelines during procurement planning" (AAA Mediation Magazine, 2026). If those links are missing even in the baseline, that is a finding in itself.

Rebuilding a schedule is normal: it gets more detail, a new structure, a new coding system. The question is what happened to the links. GAO's guide says: "Activities should not be deleted from a baselined schedule. Deleting an activity may disrupt schedule logic and complicate efforts to compare the current schedule to the baseline" (p. 126). The SCL Protocol recommends showing owner information "by logically linking to the activities of the Contractor (and not by means of fixed dates)" (para. 1.43(c)), and attaching to every update a report on revisions to durations and logic with the reasons for them (para. 1.59).

How to check:

1. Pick 10 to 20 key design activities: foundation packages for the main equipment, structural steel, services.
2. For each one, trace the predecessor chain three to five links upstream and note whether it contains vendor data, surveys or owner information. After a rebuild, the input you are looking for often sits two or three levels above the immediate predecessor. P6 has Trace Logic for this. In an XER file, TASKPRED stores relationships by internal activity numbers that differ between files, so take the activity IDs from the TASK table.
3. If activity IDs have not changed, the quickest route is P6's Schedule Comparison (formerly Claim Digger) with added and deleted relationships switched on. If they have changed, the comparison will show almost everything as deleted and re-added. In that case ask the contractor for a mapping of old to new IDs, and if there is none, match activities on the design package number.
4. Put the result in a short list.

A hypothetical example of the result:

• Foundation design, building A. In the baseline, the chain includes loads from the equipment vendor; now the activity has no predecessor.
• Structural steel design, building A. Foundation design precedes it in both versions.
• External services design, building A. In the baseline, the chain includes the site survey; now it starts from a "design start" milestone.

The second activity is fine: its chain has not changed. In the baseline, the first and third waited for inputs; the current version no longer shows those inputs, so the schedule has stopped explaining the delay. That says nothing yet about who is responsible: the links may have been dropped while adding detail, with no intent at all. But it gives you a specific question for the contractor: where are the vendor data and the survey in the schedule now, and when did they actually arrive?

GAO offers a useful indirect signal: "Significant changes in float potentially indicate that a logic link has been broken or that an out-of-sequence activity has been completed" (p. 95). I compare the total float of design activities between two consecutive updates and look for jumps.

If you would like to go through your contractor's schedule together, that is a good reason for a short call.

Check 3. Can you trust the actual dates?

In shortAn actual date in a schedule is a planner's entry, and it does not always match what happened on site. There are two quick signals and one slow one. The quick ones are actual dates later than the data date and dozens of activities sharing the same finish date. The slow one is an actual date nothing can support. Every contested date needs a contemporaneous record behind it: daily reports, transmittals, sign-offs.

GAO states the rule in one line: "No dates in the past should be estimated; no dates in the future are actual dates" (p. 122). The DCMA 14-Point Assessment, which the US Defense Contract Management Agency applies to contractor schedules, has a separate metric for invalid dates. In one GAO case study, 9% of the remaining activities had actual dates in the future (p. 125).

The second signal is not described in the standards I refer to; it is my own working habit. Plot the distribution of actual finish dates. If dozens of activities share one date, find out why. There are usually three reasons: status is entered once a month at the report date, activities were added to the schedule later and closed on the day they were added, or a package really did go out under one transmittal. The first two make the date useless as evidence of when the work finished; the third can be checked against the document register. Actual dates that match planned dates to the day across many activities raise the same question.

The third signal is the lack of support. The SCL Protocol says records "must be generated contemporaneously as the works progress, and not afterwards" (para. 1.7). In practice, checking actual dates means comparing them with daily reports, timesheets and sign-offs, and this is the slowest part of the job.

The first two signals are easy to find in Excel. In an XER file, actual dates sit in the act_start_date and act_end_date fields of the TASK table, and the data date in the last_recalc_date field of the PROJECT table. If one file holds several projects, for example a baseline and the current schedule, filter by project.

Check 4. Is "design finish" in the schedule the date design was issued?

In shortThe finish date of a design activity in P6 and the date a design package was issued for construction (IFC) are usually different. Between them lie review, comments, re-issue and revisions. For a delay discussion, take the issue date from the master document register (MDR) and the transmittals, or better still from your own incoming document log. Use the schedule for the logic.

Planners close a design activity at different moments: at submission for review, on receipt of comments, or at issue for construction. Even IFC means different things to different people. Mesa Associates write: "The bottom line is that IFC can mean different things to different stakeholders." The SCL Protocol lists submission logs, with date of submission, date of response and status, among the records a project should keep.

The contractor maintains the MDR and can edit it as easily as the schedule. The firmest ground for the owner is its own: the incoming correspondence log and the stamp your site supervision team puts on drawings released to site.

How to reconcile:

1. Take the design packages in dispute.
2. For each package number, list four dates: activity finish in P6, first submission for review, issue for construction, latest revision.
3. See which of these the schedule date matches. That tells you how far the schedule can be read as an issue log.
4. Note revisions after issue separately: construction may have needed the second issue of a package, with changes.

Check 5. Could design have been holding construction?

In shortLate design and construction delayed by design are different questions. If construction started months after the required design was issued, design was not its direct constraint. The test: measure the lead time from design package issue to construction start, then take the median and quartiles. This screening test shows where to look and does not replace a delay analysis. The metric is my own; I have found no industry benchmark for it.

The first question asks whether design was late. The second asks whether that cost construction any time. A delay discussion turns on the second one, and in the end it has to be answered for activities on the critical path. Schedules usually show only the first.

How to measure:

1. Take construction activities with an actual start in the period.
2. For each, identify the design packages it cannot start without. The package number in the activity description is more reliable than schedule links, which may have been lost (Check 2). If an activity needs several packages, or a package was issued in parts, use the last issue before the start.
3. Take the issue date from the MDR or from your own incoming log.
4. Lead time = construction start minus design issue, in days. Activities started before issue get a negative lead time and stay in the median.
5. Look at the median, the 25th and 75th percentiles, the share of activities with less than two weeks of lead time, and the share started before issue.
6. Separately, list construction activities that should have started by now under the baseline but have not, and check whether their design has been issued. Without this step the sample contains only activities that design did not stop, and the median looks better than reality.
7. Separately, look at activities on the critical and near-critical paths: they drive completion, and a median across all activities says nothing about them.

A hypothetical example with two buildings:

• Building A. 80 construction activities started. Median lead time 120 days, 25th percentile 60, 75th percentile 190. About 10% of activities had less than two weeks, 5 started before issue. Another 2 are waiting for design although their baseline start has passed.
• Building B. 60 construction activities started. Median lead time 9 days, 25th percentile 2, 75th percentile 30. More than half had less than two weeks, 11 started before issue. Another 14 are waiting for design although their baseline start has passed.

The 25th percentile means a quarter of activities had no more lead time than that.

In building A, design mostly sat for months before work started. Design could only have been holding construction there through the fabrication chain, covered in the caveats below, or on the few activities with short lead time and the two still waiting, if they are on the critical path. In building B, construction followed design closely and 14 activities are still waiting. Late design probably did turn into late construction there, but that needs confirming: for activities with short lead time, check that workfront, crews and materials were ready before the design. The numbers in the example are hypothetical.

The test also works the other way. If the baseline allowed months between design issue and construction and that lead time has disappeared in practice, it points to design as a cause.

Four caveats. First, when design and construction overlap by plan (fast-track), short lead time may have been planned. The Construction Industry Institute notes that "there is inherent overlap between design, procurement and construction phases in a typical fast-track project", so compare with the lead time built into the baseline. Second, for work that needs fabrication (structural steel, pipe spools, embeds), compare design issue with the start of fabrication or the purchase order. Measured against the start of erection, the "materials" that held construction may turn out to be the same design packages. Third, one month's snapshot is not the project's history, so measure period by period. Fourth, treat activities started before design issue separately: they started on preliminary documents, or they are mislinked in the schedule.

What else should you check before reading the critical path?

In shortRead the contractor's critical path only after a basic quality check of the schedule. For the owner, four items matter most: open-ended activities, hard constraints, large negative float and the scheduling option for out-of-sequence progress. The full lists are in the DCMA 14-Point Assessment and the GAO guide. DCMA treats its thresholds as triggers for a closer look, and GAO sets no thresholds at all.

• Logic. Every activity apart from the project start and finish milestones should have at least one predecessor and one successor (GAO, p. 31). DCMA counts incomplete activities and uses a 5% threshold.
• Hard constraints. Mandatory Start and Mandatory Finish in P6 override the logic: the activity stays on its date even if its predecessors are late, and the delay disappears behind it. In P6, a Finish On or Before constraint affects only late dates. It leaves the delay visible as negative float and makes the activity critical because of a date, even where the logic does not require it. GAO is explicit that "a customer-mandated date, including contractual obligations, does not constitute a legitimate reason to constrain an activity" (p. 40). The SCL Protocol recommends avoiding such dates or explaining them (para. 1.47).
• Negative float. It appears when the forecast overruns a date constraint, most often the contract date at completion or at an interim milestone. On an update of a project that is behind, that is normal. But GAO warns that "a network that displays large negative values of total float, such as −300 days for some activities, most likely indicates either missing logic or an unrealistic sequencing of activities" (p. 94).
• Scheduling option. When an activity starts out of sequence, P6 can schedule with retained logic, progress override or actual dates. Progress override usually gives a shorter schedule. Switching the option between updates moves the finish date with nothing happening on site, provided there is out-of-sequence progress in the schedule. There can be good reasons for a switch, but you want to see it and discuss it. The option is in the scheduling settings, and in an XER file in the SCHEDOPTIONS table.

DCMA itself cautions that "the identification of a 'red' metric is not in and of itself synonymous with failure but rather an indicator or a catalyst to dig deeper" (DCMA-EA PAM 200.1, section 4.0). GAO adds that "DCMA's 14PA thresholds are not compliance triggers" (p. 190). A green 14-point table does not prove the schedule can be trusted, and a red one does not prove the opposite.

What do you do if a check finds something?

In shortA finding in the schedule is a reason to ask a question. Ask the contractor for an explanation and the files, agree which schedule is the accepted one, and only then argue about causes. If money or an extension of time is at stake, you need a formal delay analysis, and the choice of method affects the answer as much as the dates do.

The SCL Protocol recommends settling disputes over what the Accepted Programme is as soon as they arise (para. 1.56). The earlier the parties agree on the baseline, the less there is to argue about later.

Formal methods are described in AACE Recommended Practice 29R-03, Forensic Schedule Analysis. Among the methods that look at how the project actually ran, some compare progress against the logic of a single schedule, usually the baseline, while others take each update with its own logic. The practice also describes a progress-only half-step update ("bifurcation"), which separates the effect of progress from the effect of logic changes. It also covers methods that model events in the schedule. If the schedule was rebuilt, the choice of approach changes the answer, and it is worth agreeing before anyone starts calculating.

If the links show that design was waiting for owner information, deal with it before the meeting: the contractor will find the same links.

Which questions should you send the contractor?

In shortThe questions below move a delay discussion onto documents. They work best in a letter before the meeting, so the contractor has time to pull the files together. The answers give you material for all five checks: baseline, logic, actual dates, design issue and the link between design and construction.

1. Which file is the accepted baseline, what is its data date, and which document accepted it?
2. Has the schedule been rebaselined? If so, when and why, and where are all the versions?
3. Where are the vendor data, surveys and owner information that design depends on in the current schedule, and when were they actually received?
4. If activity IDs have changed, where is the mapping of old to new?
5. What supports the actual dates for design and for construction?
6. What counts as design issue: the activity finish in the schedule or the date in the document register?
7. Which constraints are in the schedule and why, and which scheduling option is it calculated with?

If you would like me to run these checks on your project, get in touch through the form on the main page. Other notes on checking project numbers are in the notes section.