How the analysis works
Start from the baseline that the parties actually agreed, not a later re-baseline made to absorb delay. Establish the planned start, finish and sequence for each significant activity or work package.
Then build the as-built: actual start and finish for the same activities, taken from progress records, site diaries, statused P6 updates, or photographic and delivery records where the schedule updates are thin. Where the as-built has activities that were never planned, add them — omissions are usually where the delay lives.
Compare the two on a common timescale. Each activity shows a planned bar and an actual bar; the offsets accumulate into the overall completion delay. The analysis then attributes each significant offset to a cause and identifies which offsets were on the path that drove completion.
Windowed as-planned vs as-built
The plain form of the method compares only the start and end states, which invites the criticism that it ignores everything that happened in between. The windowed variant splits the project into periods — typically monthly updates, or periods bounded by significant events — and compares planned against actual within each window.
This is far more defensible. It shows the critical path moving between windows, it isolates delay to the period in which it occurred, and it makes concurrency visible instead of hiding it in a single end-to-end number. Where the records support it, windowed analysis is what most experienced reviewers expect to see.
How it compares to other methods
Time impact analysis is prospective: it inserts a fragnet representing an event into the update current at the time and measures the predicted effect. It is strong on causation but depends entirely on the quality of the CPM updates.
Impacted as-planned adds delay events to the baseline and reruns the network — cheap, but it ignores what actually happened and is widely discounted. Collapsed as-built removes delay events from the as-built to show what completion would have been without them, which needs a very good as-built record.
As-planned vs as-built sits between them: less modelling risk than TIA, far more grounded in fact than impacted as-planned, and easier to explain in a meeting than any of them. The Society of Construction Law Delay and Disruption Protocol treats it as an accepted method where records are strong and the CPM updates are not.
Building the comparison in TideLine
Take any two schedules — baseline and update, or two consecutive updates — and run the comparison. TideLine aligns the activities across both versions and reports what changed: added, removed, re-sequenced, re-durationed activities, date movement, and how the critical path migrated between the two.
The comparison opens directly in the Delay module, where each pair of snapshots becomes a window. Within a window you get a structured slip analysis: which activities drove the period slip, group-level finish-date slip, and a root-cause walk that follows each late activity back up its dependency chain so cascaded slips collapse into the activity where the delay actually started.
You then place the critical delays yourself. Each one is recorded in the delay-event register with its date, impact days, cause code, affected activity, responsibility and claim type. Where root causes in the same window carry different responsibilities, TideLine flags the concurrent-delay pattern rather than silently attributing the whole window to one party.
Chain the windows and you get contemporaneous period analysis: project-finish trend across windows, total slip by responsibility, and cross-window concurrency — the form of as-planned vs as-built most reviewers expect.
From comparison to schedule, and to the report
A comparison is not the end of the work. TideLine lets you push the Delay workspace into the Schedule module so the compared programme can be re-sequenced, re-logic'd, impacted or modelled further, then captured back as a snapshot for the next window — without editing your source .xer files.
Everything carries through to the output: the window findings, the as-planned versus as-built exhibit, the delay and EOT register, and the narrative sections of the report, with each causal claim tied to the finding, activity ID or dated log entry that supports it.
That traceability is the point. An expert witness has to be able to show where every number came from — which two snapshots produced a window, which activity drove the slip, which record evidenced the cause, and who it was attributed to. TideLine keeps that chain intact from source schedule through to the exhibit in the report.