Four situations, four paths
RP 29R-03 classifies forensic methods by timing (prospective or retrospective) and by whether the analyst observes the schedules as they are or models a scenario by adding or removing delay. Observational methods divide again into static (one plan against one as-built) and dynamic (the updates, whose logic changed as the job went on). The four paths sit in that map as follows.
| Path | You are reviewing | Family and method | What it answers |
|---|---|---|---|
| A A submitted TIA | The contractor has inserted fragnets for one or more events into an update and says completion moves | Modelled, additive, single base: MIP 3.6 (events inserted one at a time into one update), with RP 52R-06 | What would this event do to completion, given the progress at the time it arose? Events that have already started are history, not forecast; the page lists them and sends you to B or C. |
| B This month's update | Completion moved since the last update and you want to know why | Observational, dynamic, split: MIP 3.4 | What moved completion between two updates: progress, or re-planning? |
| C Delay over months | You need the delay to date and whose it was | Observational, dynamic: MIP 3.3 and 3.4, with 3.2 as a cross-check | What was critical at each update, how far did completion move in each period, and whose delay was it? With reliable monthly updates this is the strongest record there is. |
| D No usable updates | Updates were never produced, were not used, or cannot be trusted | Observational, static: MIP 3.1 and 3.2; the collapsed as-built (3.8) only as a disclosed last resort | How late did the work finish against the plan along its critical chain, and who caused each slip? |
RP 29R-03 deliberately does not rank the methods; the right one depends on the purpose, the contract and the records. If you are not sure, the page's Help me choose asks the four questions the practice's own selection factors come down to: has the delay event happened yet; which updates do you have; does the contract prescribe a method; and what do you need to decide (time only, time and money, or whether acceleration is owed). It then names a path, gives its reasons and says what the record cannot settle. A time impact analysis alone, for instance, cannot settle money: it models the events you insert and does not test for concurrent contractor delay, so a claim for time and money needs path C or D for the same period as well.
The four steps every path runs
- Set up. The measuring point (normally the last contract milestone), the record, and the contract settings. The method is written down, with the reason, before any number is shown.
- Check the record. A result cannot validate the record it came from, so the record is checked first, and one verdict is given: fit; fit, with disclosures (the analysis runs, and the items marked for disclosure print with the result); or not fit as it stands (something must be corrected before the result can be relied on; the analysis still runs so you can see what the correction is worth, and the verdict travels with every answer). What is checked depends on the path: the base schedule and every change outside the events for a TIA; the number and spacing of dated files, restated actual dates and whether each window re-schedules to its own dates for windows; the baseline pairing and the continuity of the chain for path D; and, for all of them, the settings that move a date without any change in the work (hard constraints, expected finishes, progress override, float calculated to the project finish, open ends, leads, lags, several calendars, out-of-sequence progress).
- Analyse. One number in one unit (calendar days or working days, as the contract says), the bridge that produced it, the protocol checklist, the charts and the evidence.
- Decide and report. Who carries each delay, concurrency and pacing, the tests for a time extension, a draft determination brief and the workbook.
Three rules the page never breaks
The method is chosen before the answer is seen. Owner, contractor and neutral days are reported in separate buckets and never subtracted from each other. And the inputs a schedule cannot supply (who caused a delay, when it was discovered, what the contract says, what time was already granted) are asked for, never guessed, and printed in the brief as you entered them.
How each path measures
Path A: stepped insertion, in discovery order
Every submitted event is first tested structurally (eleven checks: relationship types, open ends, constraints, status, durations, lags, calendars, and whether it can transmit delay at all). An event that fails is held until corrected and not inserted; an event that is sound but never reaches the driving path is inserted, absorbed by float, and reads "sound; not critical". The page then collapses every accepted event to zero to get the unimpacted completion, and puts them back one at a time in the order they became known, recording completion after each. The steps add up exactly to the all-events figure, and the order decides which event owns the days; removing each event alone, the older approach, can add up to far less or more than the whole when events share a path. Days already granted for the same dates are taken off, and no date is removed twice. When a later update is loaded, a hindsight check compares the forecast with what that update shows.
Path B: the half-step
A monthly update mixes what happened on site with what the scheduler changed in the plan. MIP 3.4 separates them with an intermediate schedule: last month's network carrying only this month's progress (actual starts, actual finishes and remaining durations, nothing else). Then: window movement = completion now − completion at the prior update; by progress = completion of (prior network + this period's progress) − completion at the prior update; by revisions = the rest. Both parts are shown, because a small net figure can hide a large loss and a large recovery. The page also walks the chain that drives the measuring point and credits each activity only with the movement the one before it had not already carried, so you see where delay entered the chain, what was taken back further along it, and what actually reached completion; entries whose predecessor link is new or changed are tagged, because the logic change, not the activity with the largest entry, is then the cause to put.
Path C: every window, then the sum
Each consecutive pair of dated files is one window, oldest first, measured exactly as in path B. The windows must add up to the movement measured directly from the first file to the last; the page prints the reconciliation and flags any gap. Responsibility is decided per window: the same activity can be the contractor's delay in one month and the owner's in another. The buckets follow the usual net-effect rule where the contract is silent: owner delay alone is excusable and compensable; owner and contractor delay together, or any neutral delay, is excusable but not compensable; contractor delay alone is not excusable. A window in which completion came back is shown as recovered, on its own. Where the baseline is loaded, the as-planned against as-built variance (MIP 3.2) is set beside the windows as a cross-check.
Concurrency
Where owner and contractor delay both drive the same window, the page shows both readings, literal (concurrent only on the days both were actually happening) and functional (concurrent if in the same window), draws each party's delaying period for the literal test, and asks the four prerequisites of concurrency from the record: independent, caused by different parties, involuntary, and each substantial enough to have delayed completion on its own. You decide; the page records the decision and its basis.
Path D: allocation along the chain
Take the chain that leads to the measuring point in the order of the work. Each activity's finish variance is its actual (or forecast) finish less its baseline finish; each is allocated only its own variance less what the activity before it had already carried, so the column adds up to the variance at completion and a negative allocation is mitigation. Two chains are offered: the baseline's controlling chain (as-planned against as-built) and the as-built critical chain (the retrospective longest path). The collapsed as-built is offered in the evidence only, on the rows you mark, and is labelled an approximation beside the allocation, never instead of it.
Five worked reviews of one schedule
The Vireo Line Extension is a fictional design-build extension of a transit line with five stations and twin bored tunnels, supplied with the product as a baseline and eight monthly P6 updates; nothing in it is real. Substantial Completion (VL-MS-0410) was planned for 8 November 2029 against a contract date of 31 January 2030. Every figure below is one the product shows when the same files are loaded; the section's guide walks through each review screen by screen.
| Review | Path | What the page found |
|---|---|---|
| The Design-Builder's time impact analysis in the August 2026 update | A | Three events were detected from their IDs. IMPACT 13 was held: its one activity is hung start-to-start and finish-to-finish beside the track installation instead of in series. The record read not fit as it stands: a start-on-or-after constraint added to operational readiness in the same update as the fragnets, and four actual dates restated on two station entrance structures; five relationships retyped or re-lagged, six calendar reassignments and eleven duration changes disclosed. Inserted in discovery order, IMPACT 11 moves Substantial Completion to 24 December 2029, 69 calendar days (47 work days); its own activities run 45 work days end to end, so nothing hidden in the logic is adding time. IMPACT 12 adds nothing: it never reaches the driving path. Conclusion: 69 days as submitted, not yet supportable until the constraints, the restated actuals and the undeclared changes are dealt with and IMPACT 13 is rebuilt. |
| This month's update, July to August 2026 | B | Completion moved 64 days earlier, and the half-step split it progress 0, revisions −64: the month's work, as reported, would have left completion where it was. 283 days entered the controlling chain and 347 were taken back further along it; the largest entries came with new links, and the witnessed systems integration acceptance test took 246 days back. The 40 revisions on or near the chain are acceleration of testing and commissioning: five tests moved to a seven-day recovery calendar, four finish-to-start links between tests became start-to-start with lags, seven test durations shortened. Bucket: recovered 64, on its own. Conclusion: the 24 December forecast rests on acceleration the Design-Builder has to support; undirected acceleration is at its cost and risk, directed acceleration is a change. |
| Delay over months, baseline to August 2026 | C | Seven windows: +8, +12, +6, +13, +65, +6 and −64, adding up to the +46 measured directly. June is the window that matters, +65 (29 from progress, 36 from revisions): the tunnel M&E containment started in May with 1,200 hours to do and on 1 June reported 1,384 still to do. Traced through every window, that activity moved +201 days and carried +74 of completion's movement. Buckets: contractor 110, recovered 64, never netted; no window has both parties on its chain, so concurrency does not arise. Substantial Completion is still 38 days inside its contract date, while traction power (+232), the Rookery Point fit-out (+154) and the cross passages (+90) have lost more time than completion has. |
| The tunnel drives, before any update existed | D | Tunnelling complete was planned for 11 September 2025 and achieved on 30 October 2025, with no monthly update in the period. Measured at that milestone along the baseline's controlling chain (all 26 activities finished, so the as-built is really built): 49 days late, made of 85 days of slips and 36 of recovery. Buckets from the schedule's own responsibility code, provisionally: neutral 7 (a permit and a utility relocation), contractor 78, recovered 36. Limitation, stated in the report: with no update in the period the analysis cannot say when each slip became known. |
| The month after, September 2026 | A then B | The hindsight check on the August TIA: September forecasts completion +100 calendar days from the unimpacted date against the +69 modelled, so something besides the events moved completion. Path B on the month: +31 days, to 24 January 2030, a week inside the contract date, split progress 15, revisions 16. Two activities carry it, 14 days each: the tunnel M&E containment (the contractor's; a supplier short-shipped and the crew was split) and IMPACT 11's notice (the owner's; the Authority said the revised specification would take four weeks, not two). Both parties on the chain opened the window for concurrency; functionally the delays share a window, literally they never ran on the same days, and under a literally-read contract each party keeps the days its own activities carried. Buckets: owner 16, contractor 15, nothing undecided. |
What the analysis cannot tell you
- Whether an event happened as described, or whose fault it was. That lives in daily reports, correspondence and the contract. The page offers the schedule's own responsibility code as a suggestion and says so in the report; every choice is yours.
- Entitlement and compensability. The brief puts the clause, the notice and the tests for a time extension first, then the impact, then any cost arithmetic, in that order.
- A better answer than the record allows. A window of 2,132 days between a 2020 baseline and a 2026 first update is measured, disclosed, and looked at another way (path D); it is not filled in.
- Disruption or productivity loss without project delay. A different analysis.
Where to find it
Delay Analysis & Validation is a module: included in the Expert plan, available as an add-on to Analyst, and open in the fourteen-day trial. Current prices are on the pricing page. The method descriptions here summarise the AACE International recommended practices in this guide's own words; consult the practices for their text.
Fourteen days free
Try it on your own schedule
Fourteen days free, no credit card, every section open. Your XER or XML file is read in your browser and never uploaded; only anonymous numbers reach the calculation service, and nothing is stored.
RelatedHow to compare two P6 updatesDCMA 14-point assessmentPlans and pricing