When an EPC project ends up in a delay dispute, the programme stops being a planning tool and becomes evidence. Tribunals, counsel and opposing experts will test it. One of the first tests is usually the DCMA 14-point assessment, a set of schedule quality checks originally developed by the US Defense Contract Management Agency and now used widely on energy and infrastructure projects.

A schedule that fails these checks is not automatically wrong. But every failure gives the other side a reason to argue that the critical path cannot be trusted, and that weakens any delay analysis built on it. Here are the failures we see most often in disputed EPC schedules, why they matter, and what to do about them.

The 14 checks at a glance

#CheckUsual threshold
1Logic: activities missing a predecessor or successor5% or less
2Leads (negative lags)None
3Lags5% or less of relationships
4Relationship types: finish-to-start90% or more
5Hard constraints5% or less
6High float (more than 44 working days)5% or less
7Negative floatNone
8High duration (more than 44 working days)5% or less
9Invalid dates (actuals in the future, forecasts in the past)None
10Resources or cost loadedAll activities with duration
11Missed tasks: finished later than baseline5% or less
12Critical path testMust pass
13Critical Path Length Index (CPLI)0.95 or more
14Baseline Execution Index (BEI)0.95 or more

Thresholds are guidelines, not contractual rules. What matters in a dispute is whether a failure distorts the critical path you are relying on.

1. Missing logic and open ends

This is the most common and most damaging failure. If an activity has no successor, a delay to it cannot push anything else, so the schedule will never show it as critical. On EPC projects we often find whole packages, such as vendor data, long-lead equipment or commissioning systems, sitting in the programme with no ties to construction.

In a dispute, open ends let the other side argue that the delay you are claiming was never on the critical path at all. Before any analysis, every open end should be identified and either justified or corrected, with the change recorded.

2. Constraints doing the work that logic should do

Planners under pressure often fix dates with "start on" or "finish on" constraints instead of building the logic. The schedule then looks right on the day it is issued, but it cannot respond to change. A hard constraint can hide a slip completely, or create artificial negative float that has nothing to do with real progress.

Expect an opposing expert to list every constraint and ask what justified it. Contractual milestones are a fair reason. "It made the dates look right" is not.

3. Long lags and leads

A 30-day lag between "pour foundation" and "set equipment" might represent curing, inspection and access, but nobody can tell from the schedule. Lags hide work and make delays hard to trace. Leads, where a successor starts before its predecessor finishes by a negative amount, are worse because they make the logic difficult to follow at all.

Where lags are genuinely needed, document what they represent. Where they stand in for real activities, replace them with those activities.

4. Activities that are too long

An activity of 120 days called "piping installation, unit 2" tells you very little about progress or delay. If it runs late, you cannot show which part of the work caused the slip. Long durations also make it hard to link the activity properly to the work around it.

For forensic work, high-duration activities often need to be broken down using progress records, so that delay can be measured at a level a tribunal will accept.

5. Invalid dates and poor updating

Actual dates in the future and forecast dates in the past are a sign that updates were not done properly. In contemporaneous delay analysis, each update is a snapshot of what the project knew at the time. If the updates are unreliable, so is the analysis built on them.

Check the status dates, the actuals and the progress on every update you intend to rely on, and be ready to explain any corrections.

6. A critical path that does not pass the test

The critical path test adds a large delay to an activity on the critical path and checks that the project end date moves by the same amount. If it does not, the path is broken somewhere, usually by a constraint, an open end or a calendar problem. A failed test undermines any claim that relies on the critical path shown in the schedule.

What this means for your claim

A poor-quality schedule does not mean you have no claim. It means the analysis needs more work, and the choice of method matters. Under AACE International Recommended Practice 29R-03, there are several recognised forensic schedule analysis methods. Some, such as observational methods using contemporaneous updates, depend heavily on the quality of the original updates. Others allow the analyst to correct and rebuild the schedule, provided every change is transparent and justified.

The practical steps are the same in most cases:

  • Run the 14-point assessment on the baseline and every update you plan to rely on, before the other side does.
  • List each failure and decide whether it affects the critical path for the delay events in question.
  • Correct only what needs correcting, and record every change with its reason and source document.
  • Choose an analysis method that fits the quality of the records you actually have.

Better still: avoid the problem during the project

Most of these failures are easy to prevent while the project is running, and expensive to fix once a dispute starts. A short schedule quality review at baseline and at key updates, using the same 14 checks, is one of the cheapest forms of claim protection a contractor or owner can buy.

If you would like an independent DCMA 14-point review of a baseline or update, or support with a delay claim, contact Energy Total Group or our dispute advisory company, EPC Disputes Advisory.

Sumer Jain is Founder & CEO of Energy Total Group and EPC Disputes Advisory, an AACE Certified Cost Professional and Certified Expert Witness with around 30 years in EPC project controls.