XER File Analysis: How to Review and Assess Primavera P6 Schedules from XER Exports

You’ve received the contractor’s programme as an XER file. You don’t have a Primavera P6 licence. You open it in a free viewer, see 800 activities and some Gantt bars, and the completion date looks right. You move on. Six months into a dispute, the delay analyst finds 47 open-ended activities, 23 hard constraints overriding logic, and a critical path that doesn’t connect to the contractual completion milestone. You reviewed the file but you didn’t analyse it. There’s a big difference.

XER files are the primary medium for exchanging Primavera P6 schedule data. Every contractor submission, every programme update, every forensic schedule review starts with an XER. But an XER file contains far more information than what’s visible in a Gantt chart. This article explains what’s inside an XER, what to look for, and how to run a proper construction schedule analysis whether you have P6 or not.

What Is an XER File?

An XER file is Oracle Primavera P6’s native export format. When a contractor exports a schedule from P6, the XER file contains the project’s entire data structure: activities, relationships, resources, calendars, the Work Breakdown Structure (WBS), and project-level settings.

XER is the industry standard for P6 data exchange. Most construction contracts that require P6 scheduling specify XER as the deliverable format. It’s preferred over XML exports because it preserves more of P6’s data structure, and it’s preferred over PDF or printed reports because it allows the recipient to recalculate and analyse the schedule.

XER vs other formats

An XER file version corresponds to the P6 version that created it. An XER exported from P6 version 21 cannot be imported into P6 version 8. When you receive an XER, check the version. If you’re running an older version of P6, you may not be able to open it directly.

Callout box: Never accept a PDF as the sole programme submission. PDFs don’t show logic, constraints, float calculations, or calendar assignments. If you can’t recalculate the schedule, you can’t verify it. Request the XER.

Why Analyse XER Files?

XER analysis serves four main purposes:

1. Reviewing schedules without P6 access. Not every employer, consultant, or lawyer has a P6 licence. XER analysis tools let you examine the full schedule data without needing the software.
2. Schedule quality assessment. Before accepting a baseline or approving an update, you need to check the schedule’s integrity. XER data contains everything needed to run quality checks like the DCMA 14-Point Assessment.
3. Forensic schedule analysis for claims. In delay disputes, the XER files from different project dates form the evidentiary chain. Analysts compare XER snapshots to establish what changed and when.
4. Auditing contractor submissions. Contractors submit programmes regularly, and a structured approach to reviewing the contractor’s programme treats every XER as evidence. Comparing each XER to the previous one reveals hidden changes to logic, constraints, calendars, and durations.

The James Webb Space Telescope launched in December 2021 against an original 2007 launch target, with final development costs in the order of US$10 billion against early-2000s estimates of a few billion dollars. The schedule failures were rooted in poor programme management: scope kept expanding, interdependencies weren’t adequately modelled, and the critical path kept shifting as new work was discovered. Proper XER analysis at each programme submission would have revealed the deteriorating schedule quality and the growing gap between planned and actual progress. Instead, the problems accumulated until they couldn’t be hidden.

What to Look For in an XER File: Complete Analysis Checklist

A proper XER analysis covers six areas. Work through them in this order.

Schedule structure and scope

Start with the big picture.

• WBS completeness. Does the Work Breakdown Structure cover all contract scope? Missing WBS elements suggest missing scope.
• Activity count. Is the number of activities proportionate to the project’s size and complexity? A $500M project with 200 activities probably doesn’t have enough detail.
• Scope coverage. Walk through the WBS against the scope of works. Every major deliverable should be represented.
• Missing or added scope. Compare the current XER to the baseline. Activities added or deleted without explanation warrant investigation.

Logic and dependencies

Logic is the backbone of the schedule. If it’s broken, the critical path and float calculations are unreliable.

• Open ends. Activities with no predecessor (other than the project start) or no successor (other than the project finish) are open ends. Per the DCMA 14-Point Assessment, metric 1, fewer than 5% of activities should have missing logic. If 15% of your activities are open-ended, the network is incomplete.
• Hard constraints overriding logic. Mandatory Start On (MSO) and Mandatory Finish On (MFO) constraints force dates regardless of logic. The DCMA 14-Point Assessment, metric 5, limits hard constraints to 5% of non-summary activities.
• Relationship types and distribution. Most relationships should be Finish-to-Start (FS). A high proportion of Start-to-Start (SS) or Finish-to-Finish (FF) relationships can indicate a schedule that’s been logic-manipulated to show earlier dates.
• Circular logic and redundant relationships. Circular logic (Activity A depends on B, which depends on A) prevents P6 from calculating the schedule. Redundant relationships don’t cause errors, but they clutter the network and can mask genuine logic issues.

Durations and calendars

• Unusually long activities. The DCMA 14-Point Assessment, metric 8, flags activities with duration exceeding 44 working days (roughly two months); these should be broken into smaller components. A 200-day activity tells you nothing about what’s happening within that period.
• Calendar assignments. Every activity should be assigned to the correct working calendar. A 5-day calendar on a site works activity that runs 7 days per week creates a timing mismatch.
• Holiday and weather calendar adequacy. Are public holidays modelled? Are regional weather non-working days included? A calendar that doesn’t account for known stoppages will produce unrealistic completion dates.

Critical path and float

• Critical path validation. Does the critical path make sense? Trace it from the first activity to the last. Does it follow a logical construction sequence consistent with the critical path method in construction?
• Float distribution. How much total float does the schedule show? A programme with 150 days of float on every path may be artificially padded. A programme with zero float on multiple paths may be in trouble or may have suppressed float through constraints.
• Negative float. Per the DCMA 14-Point Assessment, metric 7, any negative float indicates the schedule is already behind the contractual baseline (the pass threshold is 0%). Even one day of negative float on the critical path means the contractual completion date has been breached.
• Near-critical paths. Paths with low float (say, less than 10 working days) are vulnerable to becoming critical. Identify them and monitor them.

Constraints

Constraints are the most common quality issue in contractor programmes.

Hard constraints (MSO, MFO) override logic entirely. An activity with an MFO constraint will finish on that date regardless of what its predecessors or durations say. Once the constraint count climbs well above the DCMA five-per-cent threshold, the schedule isn’t logic-driven any more. It’s date-driven. You can’t trust the float values, and any delay analysis based on it will be unreliable.

Resources and costs

Not every schedule review requires resource analysis, but when it’s relevant:

• Resource loading completeness. Are activities resource-loaded as required by the contract? Unloaded activities can’t be cost-tracked.
• Cost loading alignment. Do the cost profiles align with the contract value? A schedule where 90% of costs are loaded in the first 40% of the programme may front-load payments.
• Over-allocated resources. Are resources assigned to more activities than they can physically perform in the available time? P6 can flag over-allocations, but only if you check.

How to Run a DCMA 14-Point Assessment on an XER File

The Defense Contract Management Agency (DCMA) 14-Point Assessment is the most widely used schedule quality metric in the construction and defence industries. It checks 14 specific indicators of schedule health, and the full DCMA 14-Point assessment guide walks through each one in detail.

The 14 checks at a glance

All 14 checks can be run on XER data. You don’t need P6 to calculate them; any tool that can read the XER structure can perform the assessment. The results give you an immediate health check on the programme.

Interpreting the results

No schedule passes all 14 points perfectly. A programme that fails one or two checks isn’t necessarily bad. A programme that fails five or more has serious quality issues. The key is understanding which failures matter.

Failing checks 1 (logic), 4 (negative float), and 5 (hard constraints) is more consequential than failing check 10 (resources) on a project where resource loading isn’t contractually required. Context matters.

What we found: Four DCMA structural checks sit at five per cent thresholds: missing logic (1), hard constraints (5), high float (6), and high duration (8). A programme that fails several of them at once is telling a connected story: an incomplete network drives phantom float, hard constraints suppress what the logic can’t produce, and long-duration activities hide whatever the network can’t model. The thresholds are deliberately conservative; they’re the floor, not the ceiling.

What it means: A programme that fails on multiple structural checks cannot support a reliable delay analysis. Float values are unreliable because the logic is incomplete and overridden. Any EOT claim built on this schedule is vulnerable to challenge. The programme has to be corrected before it can serve as the basis for any forensic work.

Comparing Two XER Files: Baseline vs Update

XER comparison is a separate discipline from single-file analysis. It answers a different question: not “is this schedule good?” but “what changed between this schedule and the last one?” Comparing each update against the one immediately before it, as well as against the baseline, surfaces the incremental changes that individually look minor but compound over the project.

Confirm the two files are comparable

Before diffing anything, check that both XER files describe the same project. Three checks save hours chasing phantom changes:

• Project ID and scope. Both files should carry the same project ID and cover the same WBS scope. If one file has 400 activities and the other has 1,200, a straight comparison produces noise until you filter to the common scope.
• Data dates. Record each file’s data date. The comparison measures movement between those two points; without them, you can’t attribute change to a period.
• Activity ID consistency. This is the one that catches people out. If the contractor renumbered activities between updates, the comparison treats every renumbered task as a deletion plus an addition and buries the real changes. Where IDs have shifted, map old to new before comparing, and raise the renumbering with the contractor.

What to detect

Methods for XER comparison

1. Manual comparison in P6. Open both files, assign one as the baseline, and use the variance columns. Time-consuming but complete.
2. ScheduleReader. Opens both XER files side by side. Shows differences in activities, logic, and dates without needing P6.
3. ScheduleLens. Automates the comparison and produces a structured change report. No manual setup required.

The Berlin Brandenburg Airport was years late and billions over budget. The official inquiry found that programme management was fundamentally inadequate, with multiple inconsistent versions of the schedule in circulation. PDF exports didn’t match the native P6 files. Different parties were working from different versions of the truth, and no one was systematically comparing what changed between submissions. That’s exactly what XER comparison prevents: it ensures everyone can see what’s different and what it means.

XER Analysis for Forensic Schedule Analysis

In forensic schedule analysis, XER files serve as contemporaneous evidence. Per AACE International RP 29R-03, Section 2 (Source Validation Protocols), the analyst must use validated and reliable schedule data, and the native XER file is the most reliable form because it preserves the full schedule structure.

AACE RP 29R-03 (§1.4, Taxonomy and Nomenclature) groups the observational analysis methods, those that examine the schedule “by itself or in comparison with another” without the analyst altering it, into two variations that both depend on XER comparison. Static logic observation compares the as-built schedule against a single as-planned network; the as-planned versus as-built method is the example. Dynamic logic observation works across a series of updates whose logic changes from period to period; contemporaneous period analysis is the example. Either way, the analysis is only as reliable as the XER snapshots behind it.

How XER data supports each analysis method

The SCL Delay and Disruption Protocol, 2nd Edition (Guidance Part A paragraph 13), requires the claim document to explain the cause of the delay and the remedies claimed; XER files provide the data needed to demonstrate cause and effect: the programme as it stood before the delay, the programme after, and every change in between.

Contemporaneous XER snapshots (those saved at the time of each update, not reconstructed later) carry more evidential weight than retrospectively assembled schedules. This is why contracts should require the contractor to submit the native XER with each programme update, not just a PDF.

Tools for XER File Analysis

Key Takeaways

• An XER file contains the full P6 data structure: activities, logic, resources, calendars, constraints, and WBS. It’s far more than a Gantt chart printout.
• Always request the native XER, not just a PDF. A PDF can’t be recalculated, analysed, or compared.
• Work through the six analysis areas in order: structure and scope, logic, durations and calendars, critical path and float, constraints, and resources.
• Run a DCMA 14-Point Assessment on every XER you receive. It takes minutes and reveals the programme’s quality at a glance.
• Hard constraints are the most common quality issue. If constraints are overriding logic, the schedule is date-driven, not logic-driven, and the float values are unreliable.
• Compare each XER to the previous one. Single-file analysis tells you if the schedule is healthy; comparison tells you what changed.
• For forensic analysis, contemporaneous XER snapshots are the most reliable evidence. Require them in the contract.

The XER file is the raw material of schedule analysis. Whether you’re reviewing a baseline, auditing a monthly update, or preparing for a delay dispute, the quality of your analysis depends on understanding what’s inside the file and how to extract the right information from it. A Gantt chart shows you what the scheduler wants you to see. An XER analysis shows you what’s actually there.