Forensic Schedule Analysis: The Construction Guide to AACE 29R-03 Methods, Process and Best Practice
Forensic schedule analysis for construction disputes: AACE 29R-03 methods, a decision guide for choosing one, and the process from instruction to expert report.
A contractor submits an extension of time (EOT) claim for 120 days of delay. The claim document runs to 80 pages, with extracts from the programme, a delay event register, and a narrative attributing all delay to employer-caused events. You’re the employer’s representative. You need to know: is this analysis reliable? Was the right methodology used? Does the programme it’s based on actually reflect what happened on site? That’s what forensic schedule analysis answers, and it’s the most rigorous part of a complete construction schedule analysis when a project hits dispute.
Forensic schedule analysis is the systematic investigation of why a construction project ran late, using the programme data, contemporaneous records, and established analytical methods to determine cause, effect, and entitlement. It’s not routine schedule monitoring. It’s not updating a progress report. It’s a forensic exercise: examining the evidence, testing hypotheses, and producing findings that can withstand challenge in arbitration or litigation.
Why Forensic Schedule Analysis Matters in Construction Disputes
Construction disputes are expensive. The Arcadis Global Construction Disputes Report has consistently reported average global dispute values in the tens of millions of US dollars and average resolution times in excess of twelve months, across annual surveys published since 2011. Flyvbjerg’s database of 16,000 projects shows that 91.5% finish over budget, over schedule, or both. Many of those overruns end up as time-related claims. At the heart of most disputes is a single question: who caused the delay, and what are the consequences?
Forensic schedule analysis provides the evidence to answer that question. Without it, delay claims are just assertions. With it, they’re substantiated or disproven based on schedule data and logical analysis.
Callout box: AACE International RP 29R-03 describes forensic scheduling as “the study and investigation of events using CPM or other recognized schedule calculation methods … the study of how actual events interacted in the context of a complex model for the purpose of understanding the significance of a specific deviation or series of deviations from some baseline model.” It’s not about what could have happened; it’s about what did happen, and why.
The Holyrood Parliament Building in Scotland is a case study in what happens when forensic analysis is delayed and disputed. The project finished around three years later than originally programmed with a final outturn of approximately £431 million against an initial cost estimate of around £40 million at the start of construction (Auditor General for Scotland, 2004). The Auditor General’s report identified multiple overlapping causes of delay, but the arguments over responsibility took years to resolve, partly because the initial programme was unreliable and the contemporaneous schedule analysis was inadequate. A proper forensic approach, applied early, would have identified the compounding delays and allowed informed decisions about mitigation before the project spiralled.
The distinction that matters: notification is not substantiation. A contractor notifying a delay event within the contractual time frame has met the notification requirement. But substantiating the claim, demonstrating that the event caused delay to the critical path and quantifying that delay, requires forensic analysis. If you’re on the receiving end of a claim, separating notification from substantiation is the first step.
The AACE 29R-03 Framework Explained
AACE International Recommended Practice 29R-03, Forensic Schedule Analysis, is the primary reference for classifying and conducting forensic schedule analysis. It defines a taxonomy of methods based on four classification layers, complementing the Society of Construction Law’s Delay and Disruption Protocol, 2nd Edition.
The Four-Layer Classification
| Layer | Question | Options |
|---|---|---|
| 1: Timing | When is the analysis performed? | Prospective (during the project) or Retrospective (after completion) |
| 2: Approach | How does the analysis work? | Observational (examining existing schedules) or Modelled (inserting or removing events to test impact) |
| 3: Basis | What schedules are used? | Static (one schedule) or Dynamic (multiple schedule updates), and whether they’re used as-is or modified |
| 4: Method | What operation is performed? | Additive (inserting delay events) or Subtractive (removing delay events) |
These four layers produce nine Method Implementation Protocols (MIPs), each describing a specific analytical approach. Understanding the layers helps you evaluate whether the method used in a delay claim is appropriate for the circumstances.
How AACE 29R-03 Relates to Common Method Names
Most practitioners don’t refer to MIPs by their number. They use the traditional names. Here’s how they map:
| Common Name | AACE MIP | Classification |
|---|---|---|
| As-Planned vs As-Built | MIP 3.1 | Observational / Static / Gross |
| Windows Analysis | MIP 3.2 | Observational / Static / Periodic |
| Contemporaneous Period Analysis | MIP 3.3 | Observational / Dynamic / Contemporaneous As-Is |
| Contemporaneous Period Analysis (adjusted) | MIP 3.4 | Observational / Dynamic / Contemporaneous Split |
| Recreated Schedule Analysis | MIP 3.5 | Observational / Dynamic / Modified or Recreated |
| Impacted As-Planned | MIP 3.6 | Modelled / Additive / Single Base |
| Time Impact Analysis (TIA) | MIP 3.7 | Modelled / Additive / Multiple Base |
| Collapsed As-Built (But-For) | MIP 3.8 | Modelled / Subtractive / Single Simulation |
| Multi-Base Subtractive | MIP 3.9 | Modelled / Subtractive / Multiple Base |
The 9 Method Implementation Protocols: With Construction Examples
MIP 3.1: Observational / Static / Gross
This is the simplest method: compare the entire as-planned programme to the entire as-built outcome. You’re looking at the whole project in two snapshots.
When to use: Small, simple projects with a single clear cause of delay. A warehouse project where the steel delivery was three months late, and everything else followed that delay, is a candidate for MIP 3.1.
Limitation: It doesn’t handle multiple delay events, concurrency, or complex re-sequencing. For anything beyond a simple, single-cause delay, it’s too blunt.
MIP 3.2: Observational / Static / Periodic
Compare schedule updates at specific periods (windows). Instead of looking at the whole project at once, you examine what happened in each reporting period.
When to use: Projects with identifiable phases or windows where delay can be attributed to specific periods. A phased hospital development with separate wing completions, where each wing has its own delay story, fits this method.
Limitation: Still observational, so it shows what happened but doesn’t isolate causation. If both parties caused delay in the same window, you’ll see the combined effect but not the individual contributions.
MIP 3.3: Observational / Dynamic / Contemporaneous As-Is
Analyse schedule updates as they were submitted, without modification. This is the most reliable observational method because it uses the schedules the parties were working to at the time.
When to use: This is the preferred observational method when contemporaneous schedule updates exist and are reliable. If the contractor submitted monthly P6 updates and they’re available, MIP 3.3 gives you the most defensible picture of what happened.
Construction example: Monthly P6 updates show the critical path progressively shifting from the structural sequence to the MEP installation sequence as structural work is completed ahead of programme but MEP falls behind. The contemporaneous updates tell the story without any analyst intervention.
What we found: MIP 3.3 derives the critical path from the contemporaneous updates as they stood at the time, not from a post-event reconstruction. When the contemporaneous critical path traces a different sequence to the one the claim narrative alleges, the data is the controlling evidence. AACE RP 29R-03 §4.2 ranks MIP 3.3 as one of the most reliable observational methods precisely because it forecloses retroactive reinterpretation.
What it means: Always check whether the contemporaneous updates actually support the narrative before accepting the conclusion. If they don’t, the claim has a problem at the evidential layer, not just at the analysis layer.
MIP 3.4: Observational / Dynamic / Contemporaneous Split
Same as MIP 3.3, but with corrective adjustments for obvious errors in the schedule updates. You’re not changing the methodology; you’re fixing data entry mistakes.
When to use: When schedule updates contain minor, correctable issues (out-of-sequence progress, incorrect status dates) that don’t change the overall logic but would distort the analysis if left uncorrected.
Limitation: Every modification, no matter how minor, opens the analysis to challenge. Document every correction and explain why it was necessary.
MIP 3.5: Observational / Dynamic / Modified or Recreated
Significant modifications or recreation of schedule updates that are missing or unreliable. This is the fallback observational method when the record is incomplete.
When to use: When contemporaneous schedules are missing, corrupted, or so unreliable that they can’t be used without substantial reconstruction. For example, if the contractor failed to submit monthly updates for a six-month period, you might recreate the schedule from daily reports, site diaries, and correspondence.
Limitation: Recreated schedules carry lower evidentiary weight. The opposing party will challenge their reliability, and the tribunal may give them less weight than contemporaneous documents. Per AACE RP 29R-03, Section 3.5, recreated schedules should only be used when contemporaneous data is unavailable.
MIP 3.6: Modelled / Additive / Single Base
Insert delay events (fragnets) into the baseline programme to model what would happen if those events occurred. This is the impacted as-planned method.
When to use: Prospective analysis; early-stage forecasting when you need to predict the impact of a known delay event before it has fully played out. For instance, modelling the impact of a design change on the baseline schedule before the change is implemented.
Limitation: Uses only the baseline. Doesn’t account for actual progress. If the project has deviated from the baseline, the model won’t reflect reality. Prospective methods generally need to be updated with actual data as the project progresses; for a full walkthrough of the contemporaneous variant see our guide to time impact analysis.
MIP 3.7: Modelled / Additive / Multiple Base
Insert delay fragnets into multiple schedule updates. This is Time Impact Analysis (TIA), the preferred modelled method and the method endorsed by the SCL Protocol.
When to use: The preferred modelled method for contemporaneous and retrospective analysis. TIA works by inserting each delay event into the programme update that existed at the time of the event, then measuring the impact on the critical path.
Construction example: An employer issues a variation for additional foundations in month four. The analyst takes the month four programme update, creates a fragnet for the additional foundation work, inserts it into the schedule, re-schedules, and measures the impact on the completion date. If the completion date moves out by 15 working days, the delay attributable to that event is 15 working days.
Limitation: TIA requires reliable schedule updates for each period. It also requires well-constructed fragnets that accurately represent the scope and duration of the delay event. Poorly prepared fragnets produce unreliable results regardless of the method’s theoretical soundness.
MIP 3.8: Modelled / Subtractive / Single Simulation
Remove delay events from the as-built schedule to determine what would have happened without them. This is the collapsed as-built or but-for method.
When to use: When no reliable baseline exists and the analysis is retrospective. The argument is: “but for the employer’s late access, the project would have finished on time.”
Limitation: Subtracting events from the as-built requires assumptions about what would have happened otherwise. These assumptions are contested. The method can produce arbitrary results depending on the order in which events are removed; AACE RP 29R-03’s MIP 3.8 description specifically warns that the sequence of event removal can change the result. Document the order and the rationale for it.
MIP 3.9: Modelled / Subtractive / Multiple Base
Remove delay events from multiple schedule updates. Like MIP 3.8 but applied across the project’s update sequence rather than a single as-built programme.
When to use: Complex multi-period disputes with multiple concurrent delays where a single as-built collapse isn’t sufficient.
Limitation: Same concerns as MIP 3.8 about removal order and assumptions, magnified by the complexity of multiple update periods. This is one of the most complex methods and is rarely used in practice.
| MIP | Approach | Pros | Cons | Best For |
|---|---|---|---|---|
| 3.1 | Compare as-planned vs as-built | Simple, quick | Too blunt for complex projects | Simple, single-cause delays |
| 3.2 | Compare updates at periods | Handles phases | Doesn’t isolate causation | Phased projects with identifiable windows |
| 3.3 | Analyse contemporaneous updates as-is | Most reliable observational method | Depends on schedule quality | When good contemporaneous updates exist |
| 3.4 | Analyse contemporaneous updates with corrections | More accurate than 3.3 | Modifications invite challenge | When updates have minor correctable errors |
| 3.5 | Modified or recreated updates | Enables analysis when data is missing | Lower evidentiary weight | When contemporaneous schedules are missing |
| 3.6 | Insert events into baseline | Forward-looking; models future impact | Ignores actual progress | Prospective forecasting |
| 3.7 | TIA: insert events into updates | Preferred modelled method; SCL endorsed | Requires reliable updates and fragnets | Standard delay analysis method |
| 3.8 | Remove events from as-built | Works without a baseline | Removal order affects results | Retrospective analysis with no baseline |
| 3.9 | Remove events from multiple updates | Handles complex disputes | Most complex; rarely used | Multi-period concurrent delay disputes |
Which Forensic Method Should You Use?
The right method depends on five factors: when you’re analysing, what data you have, how complex the dispute is, where the dispute will be resolved, and what the contract says.
Decision Guide
| Factor | Favour MIP 3.1-3.2 | Favour MIP 3.3-3.5 | Favour MIP 3.6-3.7 | Favour MIP 3.8-3.9 |
|---|---|---|---|---|
| Timing | Retrospective, simple | Retrospective, data-rich | Prospective | Retrospective, no baseline |
| Data quality | Good baseline and as-built | Reliable contemporaneous updates | Good baseline available | No reliable baseline |
| Complexity | Low (single delay cause) | Moderate (multiple windows) | Moderate (specific events) | High (concurrent delays) |
| Legal forum | Negotiation, adjudication | Arbitration, litigation | Any forum | Arbitration, litigation |
| Contract requirement | None specified | None specified | Often specified | Last resort |
SCL Protocol and AACE 29R-03: How They Work Together
The SCL Delay and Disruption Protocol (2nd Edition) and AACE RP 29R-03 complement each other. The SCL Protocol provides the legal and contractual structure for delay analysis: what the contract requires, when analysis is needed, and what the results mean for entitlement. AACE 29R-03 provides the technical methodology: how to classify, select, and perform the analysis.
In practice, a forensic analyst uses both. The SCL Protocol determines the contractual basis (which events are employer-risk, what entitlement exists, whether the analysis should be prospective or retrospective). AACE 29R-03 determines the technical approach (which MIP to apply, how to classify the analysis, what quality standards the schedule must meet).
Common jurisdictional preferences: the UK and Commonwealth jurisdictions tend to favour observational methods and the SCL Protocol. The US often uses modelled methods, particularly TIA. Middle Eastern disputes frequently specify the applicable method in the contract. Australian disputes generally follow the SCL Protocol approach.
Schedule Quality: The Prerequisite for Reliable Forensic Analysis
This point cannot be overstated: forensic schedule analysis performed on a flawed schedule produces unreliable results. If the programme has missing logic, excessive constraints, or manipulated durations, the analysis will inherit those defects.
AACE RP 29R-03 codifies the validity-before-analysis principle in its Section 2 Source Validation Protocols: SVP 2.1 (baseline schedule selection and validation), SVP 2.2 (as-built reconstruction and validation), SVP 2.3 (schedule-update validation), and SVP 2.4 (discrete delay-event identification and quantification). Each MIP description lists the SVPs it requires. Run those checks on the baseline and every update used in the analysis before drawing conclusions.
The Quality Checks That Matter Most
-
Logic (DCMA metric 1). Activities without predecessors or successors break the network. If the critical path passes through an open-end activity, the path isn’t logic-driven. For the full DCMA workflow see our guide to the DCMA 14-Point assessment.
-
Hard constraints (DCMA metric 5). Constraints override logic. A schedule with 25% hard constraints is being driven by dates, not by the construction sequence.
-
Logic changes between updates. If the contractor is changing the logic between monthly submissions, the schedule is being manipulated. Compare consecutive XER exports to detect logic changes; for the comparison workflow see baseline vs current schedule comparison.
-
Negative float (DCMA metric 7). Negative float indicates the schedule is already behind the contractual date. If the baseline shows negative float, it was never achievable.
-
Unrealistic durations. Durations that don’t match benchmark data for the project type suggest the schedule is either padded (over-inflated durations hiding float) or compressed (understated durations to meet a deadline).
Callout box: A forensic schedule analysis is only as reliable as the schedule it’s based on. Run quality checks first. Document the results. If the schedule fails quality checks, say so in the report. An analysis on a schedule with 15% missing logic and 30 hard constraints should be qualified accordingly.
Step-by-Step: Conducting a Forensic Schedule Analysis
Step 1: Define the Scope and Period of Analysis
Clarify what you’re analysing and why. The instructing party’s requirements determine the scope: which delay events are in scope, what time period is under analysis, and what question the analysis needs to answer.
Agree on the baseline programme and the set of schedule updates to be used. If the parties disagree on which schedule is the baseline, resolve that before you start. Analysing the wrong baseline wastes everyone’s time.
Step 2: Review Schedule Quality
Run the DCMA 14-Point Assessment on the baseline and every update. Document the results. Flag any issues that could affect the analysis reliability: missing logic, constraints, unrealistic durations, logic changes between updates.
If the schedule quality is poor, record this. It may be necessary to qualify the analysis or recommend that an improved schedule be created before forensic analysis proceeds.
Step 3: Establish the As-Planned Critical Path
Identify the critical path in the accepted baseline programme. Verify that it matches the expected construction logic and contract milestones. A critical path that runs through the wrong trade sequence suggests the baseline is unreliable.
Identify near-critical paths with less than 10 working days of float. These paths may become critical during the analysis period.
Step 4: Establish the As-Built Critical Path
Determine the actual critical path by examining what happened on site. Use the as-built programme or the final schedule update with actual progress data. The as-built critical path may differ from the as-planned critical path if the project was re-sequenced or if delays caused critical path shifts.
Compare the as-planned and as-built critical paths. The differences between them are where the delay story lives.
Step 5: Identify Delay Events and Responsible Parties
Compile the delay event register. For each event:
- What happened (the event)
- When it happened (dates)
- Which schedule activities were affected
- Who bears the risk (employer, contractor, or neutral)
- Whether contemporaneous records confirm the event (site diaries, correspondence, daily logs)
Categorise each event as employer-risk (variation, late information, access delay), contractor-risk (poor productivity, rework, late procurement), or neutral (exceptionally adverse weather, force majeure).
Step 6: Perform the Analysis Using the Selected Method
Apply the chosen MIP. Document every assumption, every fragnet, every modification, and every calculation. The standard the project is held to is reproducibility: another analyst given the same data should be able to follow the working and reach the same conclusion.
Test for concurrent delay. If two delay events in the same window both affected the critical path, the concurrency analysis determines entitlement. This is where most disputes are won or lost. Our concurrent delay guide covers the legal tests in detail.
Step 7: Prepare the Expert Report
Structure the report for its audience. Lawyers read differently from engineers. Include:
- Executive summary of findings
- Scope of analysis and methodology chosen (with justification)
- Schedule quality assessment results
- As-planned vs as-built critical path comparison
- Delay event register
- Analysis results for each window or event
- Conclusions on delay and entitlement
- Appendices with schedule extracts, fragnets, and supporting data
Present results clearly. A Scott Schedule (also called a delay entitlement matrix) showing each window, each party’s delay, and the net effect is the standard presentation format.
AACE 29R-03 vs SCL Delay and Disruption Protocol
| Aspect | AACE RP 29R-03 | SCL Protocol (2nd Edition) |
|---|---|---|
| Focus | Technical methodology classification | Legal and contractual structure |
| Method taxonomy | 9 MIPs with formal classification | Preferred methods discussed; TIA endorsed |
| Schedule validity | Section 3.3: must be established before analysis | Assumes schedule is contractually compliant |
| Prospective vs retrospective | Formal classification layer | Discussed in context of claim timing |
| Concurrent delay | Addressed within individual MIPs | Paragraph 12: dedicated section on concurrency |
| Practical emphasis | How to classify and perform the analysis | What the analysis means for entitlement |
Use both. AACE tells you how to do the analysis. The SCL Protocol tells you what it means for the claim.
Common Challenges in Forensic Schedule Analysis
Incomplete or missing schedule updates. The contractor didn’t submit monthly updates for a four-month period. You can’t run a windows analysis without data for those windows. Options: request the missing data, use MIP 3.5 to recreate the schedules from contemporaneous records, or qualify the analysis.
Schedule manipulation. Logic changes between updates that re-sequence the critical path without reflecting actual construction. Compare consecutive XER files. If the contractor changed the logic from FS to SS between updates for the same set of activities, that’s manipulation. Document it.
Concurrent delay and apportionment. When both parties caused delay in the same window, the legal test applied (but-for, dominant cause, apportionment) can change the outcome entirely. The analyst must apply the correct test for the jurisdiction and contract.
Determining the “true” critical path. When the schedule contains constraints and missing logic, the software-calculated critical path may not reflect reality. The analyst must use professional judgement to determine the actual critical path, supported by the schedule data and contemporaneous records.
Reliability of recreated schedules. MIP 3.5 produces schedules that didn’t exist at the time. They’re models, not records. The further they diverge from available contemporaneous data, the less weight they carry.
Fragnet preparation. Poorly constructed fragnets, such as those with incorrect durations, missing logic, or inappropriate constraint types, undermine TIA and other modelled methods. Every fragnet must be verified against the scope of the delay event it represents.
| Challenge | Impact | Mitigation |
|---|---|---|
| Missing updates | Analysis gaps | Request data; recreate from records; qualify findings |
| Schedule manipulation | Unreliable results | Compare XER files; document changes |
| Concurrent delay | Outcome depends on legal test | Apply the correct contractual/jurisdictional test |
| Unreliable critical path | Wrong delay attribution | Use professional judgement; verify with site records |
| Recreated schedules | Lower evidentiary weight | Minimise recreation; qualify analysis |
| Poor fragnets | Unreliable modelled analysis | Verify against scope; document assumptions |
Tools for Forensic Schedule Analysis
Oracle Primavera P6 is the primary tool for forensic analysis. It performs schedule calculations, supports fragnet insertion for TIA, and enables direct comparison of schedule versions. Most forensic analysts work in P6 and then export results for the expert report.
Deltek Acumen Fuse provides forensic analysis capabilities including the DCMA 14-Point Assessment, schedule comparison, and delay analysis functions.
ScheduleReader allows XER review without a P6 licence, which is useful for legal teams who need to examine schedule data but don’t have scheduling software.
ScheduleLens automates the schedule quality checks that must precede forensic analysis. It runs the DCMA 14-Point Assessment, identifies missing logic, flags constraint abuse, and compares baselines against updates. Before you spend expert hours on forensic analysis of a programme, ScheduleLens tells you whether that programme is reliable enough to analyse.
| Tool | Use For | Limitation |
|---|---|---|
| Oracle Primavera P6 | Schedule calculation, TIA, fragnet insertion | Requires expertise and licence |
| Deltek Acumen Fuse | Comprehensive forensic analysis, DCMA checks | Separate licence from P6 |
| ScheduleReader | XER review for non-P6 users | Read-only; no schedule calculation |
| ScheduleLens | Schedule quality validation, baseline comparison, delay flags | Not a replacement for expert analysis |
Standards and References
| Standard | Relevance | Key Section |
|---|---|---|
| AACE RP 29R-03 | Primary reference for forensic schedule analysis methods | Section 3.3 (schedule validity), Section 4 (MIPs) |
| SCL Protocol (2nd Edition) | Legal and contractual structure for delay analysis | Paragraphs 11, 12 |
| DCMA 14-Point Assessment | Schedule quality metrics | All 14 metrics |
| CIOB Guide to Good Practice | Programme management and analysis best practice | Chapter on delay analysis |
| PMI Practice Standard for Scheduling | Scheduling methodology | Chapter on schedule analysis |
What to Do Next
If you’re facing a delay claim or preparing one, start with the schedule quality assessment before you do anything else. A forensic analysis on an unsound programme isn’t worth the paper it’s printed on. Choose the right method for your circumstances: observational if you have reliable contemporaneous updates, modelled if you need to test specific events. Document everything. And if you’re on the receiving end of a forensic analysis, check whether the schedule quality was verified before the analysis was performed. If it wasn’t, the analysis has a hole in it from the start. Our guide to the broader extension of time claim process walks through the contractual and procedural side that sits around the analysis itself.
Forensic schedule analysis doesn’t tell you who’s right. It tells you what happened. What the parties and the tribunal do with that information is a different matter.