Turning Schedule Chaos into Iron-Clad Delay Claims – with Primavera P6
Forensic schedule analysis is the scientific autopsy of a delayed project. Whether you’re a contractor building a claim or an owner defending against one, the goal is identical: prove what delayed the project, who caused it, and how much time/money is excusable or compensable—using Oracle Primavera P6 as the forensic lab.
1. The Golden Rule: One Baseline, Many Updates
| Requirement | Why It Matters |
|---|---|
| Approved Baseline (BAC) | The contract’s “promise” – locked, cost-loaded, resource-driven |
| Progressed Updates (monthly/weekly) | Snapshots of reality – % complete, actual dates, logic changes |
| As-Built Schedule | The final truth – every start/finish date that actually happened |
No baseline = no claim. P6 stores all versions natively—never delete.
2. The 6-Step Forensic Workflow (AACE 29R-03 Compliant)
| Step | Action in P6 | Output |
|---|---|---|
| 1. Data Integrity Audit | – Run Schedule Log (missing logic, lags >0, SF constraints) – Validate activity count, durations, calendars | Clean, defensible dataset |
| 2. Baseline vs As-Built Comparison | – Overlay baseline vs as-built Gantt – Filter critical path shifts | Visual delay “waterfall” |
| 3. Dynamic Analysis (Time Impact) | – Insert fragnets (delay events) into monthly updates – Recalculate critical path after each | Excusable/Compensable days per event |
| 4. Concurrent Delay Test | – Run parallel critical paths in same update – Use longest path filter | Neutral vs excusable concurrency |
| 5. Pacing & Mitigation Check | – Compare planned vs actual resource curves – Flag out-of-sequence progress | Contractor mitigation failures |
| 6. Quantify EOT & Cost | – Claim Digger → logic/duration changes – Link to cost-loaded activities → prolongation costs | Claim narrative + $ |
3. The 4 Main Forensic Methods (Pick One, Justify It)
| Method | When to Use | P6 Execution |
|---|---|---|
| Observational / Windows | Simple, concurrent delays | Split schedule into time windows, measure gain/loss per period |
| Time Impact Analysis (TIA) | Contract requires it (FIDIC, NEC) | Insert fragnets into nearest update before event |
| Collapsed As-Built (But-For) | Owner-caused delays | Subtract delay events → “but-for” completion date |
| As-Planned vs As-Built Longest Path | Quick sanity check | Filter longest path in baseline vs as-built |
Pro Tip: Use Activity Codes to tag delay causes (RFI-001, Weather-2025-03, Owner-Change-17) – enables instant filtering.
4. Contractor Building a Claim (Step-by-Step)
- Preserve the Baseline – Export .xer with approval email
- Log Every Delay Contemporaneously – Add notebook entries in P6
- Insert Fragnets Monthly – Model RFI delay as 7-day successor lag
- Run TIA on Nearest Update – Prove critical path absorption
- Export Claim Digger Report – Show logic changes owner forced
- Link to Cost Ledger – Prolongation = site overhead × excusable days
Deliverable: 30-page PDF + interactive .xer + dashboard (Power BI)
5. Owner Defending a Claim (Red Flags to Hunt)
| Issue | P6 Forensics |
|---|---|
| Float Consumption | Filter activities where TF reduced > planned – was float owner’s? |
| Logic Manipulation | Claim Digger → constraints added mid-project |
| Pacing Delays | Resource histogram → crew stood down during owner delay? |
| Mitigation Failure | Out-of-sequence report → contractor started late before delay |
6. Tools Inside P6 (No Add-Ons Needed)
- Claim Digger → tracks every change (duration, logic, calendar)
- Schedule Log → auto-flags constraints, negative float, lags
- Multiple Float Paths → proves concurrency
- Global Change → bulk-tag delay causes
- Visualiser → Gantt heat-maps (red = delayed critical)
7. Real Case Snapshot
- Project: $1.2 B LNG module yard
- Claim: 184-day EOT for late design
- Forensic Finding (TIA in P6):
- 112 days excusable (design freeze)
- 42 days concurrent (contractor crane breakdown)
- 30 days pacing (contractor reduced shifts)
- Result: $38 M settled (vs $72 M claimed)
Summary
Forensic schedule analysis = using Primavera P6’s versioned baselines, updates, and critical path engines to isolate, quantify, and attribute every day of delay — so claims are built (or broken) on data, not drama.