AACE 29R-03 Delay Attribution: A Practical Guide

When a project slips, stakeholders do not only ask how late—they ask who owns the days. AACE International’s Recommended Practice 29R-03 (Forensic Schedule Analysis) is the industry’s common language for answering that question with a named method, not a spreadsheet anecdote.

This guide is a practitioner briefing: which method to pick, what data you need, and how to keep outputs defensible in reviews and disputes.

What RP 29R-03 is trying to solve

Forensic schedule analysis sits between:

• Planning quality (DCMA/GAO-style model integrity), and
• Prospective risk (Monte Carlo, weather models, SRI)

Delay attribution is retrospective (or near-real-time contemporaneous): given as-planned and as-built evidence, allocate variance among parties and causes.

If your network fails basic logic tests, forensic math becomes theater. Fix DCMA-class structural issues before arguing concurrency.

Three methods you will actually use

Bellator’s POST /api/v1/forensics/delay-analysis is built so results can cite the methodology name. That citation is not cosmetic—claims packages and expert reports expect it.

1. Windows analysis

Idea: Divide the project into time windows. Update the schedule at each window boundary and measure critical path impact inside the window.

Best when:

• You have periodic updates (monthly/biweekly status cycles)
• You need a narrative that tracks the evolving critical path
• Stakeholders already manage by reporting periods

Watch-outs: Window boundaries can be gamed; document why windows were chosen.

2. Contemporaneous period analysis

Idea: Rely on the schedules as they existed at the time, not a reconstructed perfect model. Emphasizes what managers knew when decisions were made.

Best when:

• Dispute focuses on decision timing and notice
• You have a clean archive of periodic schedule submissions

Watch-outs: Garbage-in from poor contemporaneous schedules stays garbage-out—disclose data quality.

3. Collapsed as-built (but-for)

Idea: Start from the as-built network and remove delay events (or party-caused activities) to estimate a but-for completion.

Best when:

• As-built logic is trustworthy
• You need a but-for completion story for a specific set of events

Watch-outs: Highly sensitive to which activities you collapse and how concurrent delays are treated.

Concurrent delay in plain language

Concurrent delay means owner- and contractor-caused delays overlap such that neither party can claim the full period as exclusively theirs under the contract’s rules.

Good analysis:

1. Identifies overlapping windows on the critical path (not every noisy activity)
2. Separates excusable / compensable / non-excusable categories per contract
3. States assumptions when the network cannot support a unique split

Never hide concurrency inside a single “weather” bucket without dates and path proof.

Worked scenario (illustrative)

Suppose a data-center build with status updates at month ends:

Window	Critical path theme	Observed slip (days)	Preliminary attribution
Jan	Foundation rebar	5	Contractor productivity
Feb	Long-lead switchgear	12	Owner late free-issue
Mar	Both path & switchgear	8	Concurrent (split per contract)

A Windows analysis would restate the critical path each month and sum party impacts with concurrency rules applied in March. A collapsed as-built might instead remove owner free-issue delay activities from the as-built model and recompute finish.

The numbers will differ; the report must say which method produced them.

Data you need before calling an API

Data	Why
Current / update schedules	Progressed network
Baseline or as-planned	Reference for variance
Status dates / window bounds	Periodization
Delay event register (optional but powerful)	Cause coding (owner/contractor/force majeure)
Calendars & constraints	True critical path

Import P6/XER or MSP XML first if needed (import guide), then pass normalized tasks to forensics endpoints. Comparison endpoints remain stateless—send all schedules inline.

Example request shape

curl -X POST "https://api.bellatorsi.com/api/v1/forensics/delay-analysis" \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{
    "methodology": "windows",
    "status_date": "2026-03-31",
    "baseline_schedule": { "tasks": [/* as-planned */] },
    "current_schedule": { "tasks": [/* updated */] },
    "windows": [
      { "name": "2026-01", "start": "2026-01-01", "end": "2026-01-31" },
      { "name": "2026-02", "start": "2026-02-01", "end": "2026-02-28" }
    ]
  }'

Field names may vary by API version—confirm against the API reference and playground schema for forensics-delay-analysis. Always retain the methodology field in stored reports.

How this differs from Schedule Risk Index

	Delay analysis (29R-03)	Schedule Risk Index
Time posture	Mostly retrospective / contemporaneous	Forward-looking structural risk
Output	Attribution of slip	0–100 risk posture pre-simulation
Typical user	Claims, PMO forensics	Portfolio risk, go/no-go reviews

Read: Schedule Risk Index: what the numbers mean.

Reporting checklist (citable package)

• Methodology named (Windows / Contemporaneous / Collapsed As-Built)
• Source schedules identified (baseline, updates, as-built)
• Calendars and data-date disclosed
• Critical path exhibits per period
• Concurrency treatment stated
• Contract clauses referenced for compensability (legal, not API)
• Re-run hash or input snapshot retained for audit

Next steps

• Validate model integrity first with DCMA 14-Point
• Exercise the endpoint in the Playground
• Review standards mapping for AACE coverage by tier

Sources

• AACE International — Recommended Practice 29R-03, Forensic Schedule Analysis
• GAO Schedule Assessment Guide (credible schedules as a prerequisite to forensics)
• Bellator forensics — delay analysis (Tier 2)