Delay Analysis Methods Explained: Time Impact vs As-Planned vs As-Built

Time impact analysis inserts each delay event into the programme at the point it occurred, as-planned vs as-built compares the planned programme against what actually happened, window analysis tests each update period separately, and collapsed as-built removes events from the as-built record. The right method is the one your records can actually support.

Every delay analyst has a favourite methodology, and that preference is usually the first thing that goes wrong. Choosing a method because it is familiar rather than because it fits is like choosing a scalpel because you like the handle. The instrument has to match the operation. Across delay claims in the GCC we see the same pattern repeatedly. A technically competent analyst applies a method that does not match the available records, the contract requirements, or the nature of the delay. The analysis is internally consistent. It is also useless, because the foundation cannot bear the weight the tribunal places on it.

Time Impact vs As-Planned vs As-Built: The Four Methods Defined

There are four methods in common use, and each can be stated in a single sentence. As-planned vs as-built compares the planned programme with what actually happened and attributes the difference to identified delay events. Window analysis splits the programme into consecutive periods, normally the monthly update cycle, and tests which events drove the critical path inside each window. Time impact analysis, usually shortened to TIA, inserts each delay event into the programme at the point it occurred and measures its impact prospectively. Collapsed as-built strips events out of the as-built to test what would have happened without them.

All four are recognised in the Society of Construction Law Delay and Disruption Protocol, which is the most widely referenced guidance document in this field. The Protocol catalogues the accepted methodologies and the records each one requires. Tribunals across the GCC and internationally test expert analyses against it as a matter of routine. An analyst who cannot explain why one method was chosen over the others is already in difficulty before the substance is reached.

The differences between the four are not academic. As-planned vs as-built asks the critical path question once, end to end. Window analysis asks it every month. Time impact analysis asks it at the moment each event landed. Collapsed as-built asks it in reverse, after the fact. Windows carry more weight than a single end to end comparison, provided a contemporaneous programme update exists at every boundary. Take away that update trail and the method quietly becomes something weaker wearing a better name.

Why Delay Analysis Methodology Selection Determines Outcomes

The SCL Protocol, now the closest thing the industry has to an international standard, makes one position clear. No single methodology is inherently superior. Each method has conditions under which it is appropriate and conditions under which it is not. The choice depends on the quality and completeness of the programme records, the nature of the delays in question, and the requirements of the contract. That sounds reasonable in the abstract. In practice it means the analyst must audit the evidence before selecting the tool, not after.

This is where most analyses go wrong. The method is selected at the start of the engagement, often at proposal stage, before anyone has examined the contemporaneous programme records. It is then applied to whatever records happen to exist, regardless of whether those records can support it. The result looks rigorous on paper and collapses under cross-examination when the opposing expert asks a simple question. Where is the baseline programme that underpins this analysis, and can you demonstrate that it was accepted by the Engineer.

The commercial consequence is not a technical footnote. A discredited methodology takes the whole extension of time claim down with it, and with the extension of time goes the prolongation money and the defence to liquidated damages. The method is therefore a commercial decision dressed as a planning one, and it is normally settled with a forensic delay analyst before any narrative is written.

As-Planned vs As-Built: Simple, Seductive, and Frequently Misapplied

The as-planned vs as-built method is the most intuitive approach to delay analysis. It compares the original planned programme with the actual sequence and timing of events. The difference between the two, mapped against identified delay events, forms the basis of the claim. It is easy to explain, relatively quick to prepare, and often sufficient for a straightforward delay situation. It is also the method most likely to be selected by a contractor preparing a claim without specialist delay analysis support, for the simple reason that it can be produced from records the contractor already has.

The seduction of simplicity is its weakness. As-planned vs as-built is a retrospective method. It looks at the gap between what was planned and what happened, but it does not account for the dynamic reality of a live construction programme. It assumes the as-planned programme was achievable, that the logic and durations were realistic, and that the critical path at the start of the project remained the critical path throughout. On a 24-month infrastructure project in Qatar or Saudi Arabia that assumption is almost never valid. The critical path shifts as work progresses, as resources are redeployed, as design information arrives out of sequence, and as access constraints evolve.

The evidence requirements for a credible as-planned vs as-built analysis are lower than for any other method, which is both its advantage and its vulnerability. The analyst needs the original baseline programme and a reliable record of actual dates. Daily reports, progress photographs, monthly reports and completion certificates provide the as-built chronology. What the method offers no mechanism for is testing whether the as-planned programme was reasonable in the first place. If the planned durations were optimistic, or the logic was flawed, or the resource assumptions were unrealistic, the entire gap between planned and actual completion is attributed to delay events that may not have caused it. Arbitral tribunals in the GCC have rejected as-planned vs as-built analyses on precisely this ground. The as-planned programme was aspirational rather than achievable, and the delay attributed to the employer was in reality float the contractor never owned.

The common mistakes in applying this method are consistent. The first is using a tender programme rather than an accepted baseline. Under FIDIC, the programme submitted under Clause 8.3 and accepted by the Engineer is the contractual baseline. The tender programme was prepared before contract award, carries no contractual status, and may rest on entirely different assumptions. The second mistake is failing to identify all delay events, including contractor-caused delays, and attributing the whole gap to employer risk. An honest analysis must account for the contractor's own delays or it will be challenged as one-sided. The third is ignoring concurrent delay entirely and presenting the gap as if only one party caused it.

Window Analysis: Precision Through Segmentation

The window analysis delay method, sometimes called the time slice method, divides the project duration into discrete periods and analyses the delay within each window separately. Each window typically corresponds to a programme update period, a monthly reporting cycle, or a period bookended by significant delay events. Within each window the analyst compares planned progress against actual progress and identifies the events that caused the variance.

The strength of window analysis is its granularity. By breaking the project into segments, the method captures the moving critical path. A delay event that was critical in month six may have been absorbed by float by month eight. Window analysis can show that progression in a way a single end to end comparison cannot. The SCL Protocol identifies window analysis as generally more reliable than a simple as-planned vs as-built comparison, because it reflects the evolving reality of the project rather than a snapshot taken before work started.

The evidence requirements are substantially higher. The analyst needs not just the baseline programme but programme updates at each window boundary. If the contractor maintained and submitted monthly updates that were reviewed by the Engineer, window analysis is the natural fit. If the contractor submitted one programme at the start and never updated it, window analysis becomes an exercise in reconstruction rather than analysis. The distinction matters more than contractors expect. A window analysis built on contemporaneous updates carries real evidential weight. A window analysis built on reconstructed programmes carries very little, because the opposing expert will challenge every assumption embedded in the reconstruction.

The common mistakes here are methodological rather than conceptual. The first is selecting window boundaries that are too wide. A six-month window on a two-year project produces three or four data points, which is not enough granularity to isolate the impact of individual events. Monthly windows aligned with the update cycle are the norm for a reason. The second mistake is inconsistency in critical path identification across windows. The critical path must be assessed independently in each window based on the programme status at that point, not projected forward from the baseline. The third is failing to reconcile the sum of window-by-window delays against the actual project delay. If the individual windows show 120 days of employer delay but the project was delayed by 90 days, the analysis has a credibility problem the opposing expert will exploit.

Time Impact Analysis: What Arbitrators Expect and What It Demands

Time impact analysis is the method most frequently endorsed by arbitral tribunals and by the SCL Protocol as the most reliable prospective approach. It inserts each delay event into the programme at the point it occurred and measures the impact on the critical path at that moment. It is a forward-looking analysis that replicates the decision-making context of the project as it unfolded. The output is a sequence of programme snapshots, each showing the state of the project immediately before and immediately after the event was introduced.

TIA is generally preferred by arbitrators because it reflects the reality of how delays affect a live programme rather than how they look in hindsight. Its weakness is the mirror image of that strength. It requires a robust and properly updated baseline programme, which many contractors do not maintain. A tribunal that prefers time impact analysis in principle will still reject one that was built on a programme nobody accepted and nobody updated.

The evidential demands are the highest of any method. Time impact analysis requires a baseline with properly defined logic, realistic durations and an identifiable critical path. It requires contemporaneous progress records sufficient to update the programme to its status immediately before each delay event. It requires that the events themselves are documented with start dates, end dates and causal descriptions supported by site records, correspondence and instructions. Without those records TIA is not a viable method. Attempting it anyway produces an analysis that is theoretical rather than evidential.

Under FIDIC, the programme submitted and accepted under Clause 8.3 provides the baseline. If the contractor never submitted a programme, or the Engineer never accepted one, the analyst faces a foundational problem. The SCL Protocol permits a reconstructed programme in certain circumstances, but the weight attached to a TIA built on a reconstructed baseline is materially lower than one built on a contemporaneous accepted programme. This is why the contemporaneous records that make or break a delay claim extend well beyond daily diaries and site instructions. The programme itself, and the record of its submission, review and acceptance, is among the most important documents in the file.

The common mistakes in time impact analysis are the most consequential of the four. The first is using a baseline that was never accepted by the Engineer without disclosing that fact, which the opposing expert will establish inside the first hour of examination. The second is failing to update the programme to actual status before inserting each event, so the impact is measured against a theoretical state rather than the real one. The third is cherry-picking events, inserting only employer-caused delays and omitting the contractor's own. A one-sided TIA is transparent to any competent tribunal and damages the analyst's credibility on every other point in the claim.

Collapsed As-Built: Working Backwards From the Actual Completion Date

The collapsed as-built method, also called as-built collapsed or the but-for approach, works backwards from the actual completion date. The analyst builds a fully logic-linked as-built programme, then removes delay events one by one to determine what the completion date would have been without each delay. The difference between the actual date and the collapsed date is the delay attributed to the events removed. It is the only one of the four methods that does not depend on a baseline programme, which is precisely why it exists. It is useful where the baseline programme is unreliable or unavailable.

The evidence requirements are unusual rather than light. The method needs an as-built record detailed enough to establish the actual start and finish of every significant activity, and enough site information to impose credible logic on that record after the event. Daily reports, labour and plant returns, progress photographs, survey records and inspection sign-offs carry the weight that a baseline programme carries elsewhere. Where the as-built record is thin, the analyst is inventing logic rather than reconstructing it, and the opposing expert will say so in those words.

The method is more complex than the others and it can be contentious. The logic imposed on the as-built programme is the analyst's judgement rather than a contemporaneous document, so every link is arguable. Removing events one at a time also raises an ordering problem, because collapsing event A before event B can produce a different answer from collapsing B before A. Tribunals are alert to this. A collapsed as-built that does not test how sensitive the result is to the order of removal invites the charge that the answer was chosen rather than calculated. Before committing to the method it is worth testing what your records will actually support with a claim readiness assessment, because the discovery that the as-built record is too thin is much cheaper made early.

The common mistakes follow from those weaknesses. The first is treating the as-built programme as fact when the logic inside it is opinion, and presenting it without explaining how the logic was derived. The second is removing only employer risk events and leaving contractor delays in place, which produces a collapsed date that flatters the claimant and convinces nobody else. The third is failing to reconcile the collapsed result against what the project team believed was driving completion at the time. If the site minutes for the period record late material approvals as the constraint, and the collapsed as-built points somewhere else, the analysis has to address the contradiction rather than hope it goes unnoticed.

What the Contract Says About the Programme

Standard forms say less about delay analysis method than contractors expect, and more about the programme than they remember. FIDIC requires a programme under Clause 8.3 and requires revised programmes whenever the previous one no longer matches actual progress. That obligation is the whole difference between having an accepted baseline and arguing about one, and it sits at the centre of any FIDIC claims management regime worth the name. NEC goes further. The Accepted Programme is a contractual instrument, updated at the interval the contract states, and compensation events are assessed against it. A contractor who lets the Accepted Programme lapse loses the update trail that window analysis and time impact analysis both depend on.

So the contract rarely prescribes a methodology by name. What it prescribes is the programme regime, and the programme regime decides which methods stay available. That makes programme discipline a commercial control rather than a planning chore. The same records that support the extension of time support the prolongation claim that follows it, and the defence when the employer moves first on liquidated damages.

Choosing the Method: Evidence First, Not Preference First

The decision framework is not about which method is theoretically best. It is about which method the available evidence can support. If the contractor maintained a robust baseline, submitted regular updates and kept detailed progress records, time impact analysis is the strongest option. If the updates exist but the baseline is weak, window analysis may be the better fit. If neither updated programmes nor a reliable baseline exist but the site records are strong, collapsed as-built becomes the serious candidate. If the records are thin across the board, as-planned vs as-built may be all that is left, and the analyst must say plainly what it can and cannot prove.

The SCL Protocol recommends that the analyst explain why the chosen method was selected and why the alternatives were not. That is not a formality. Tribunals expect a demonstration that the method was chosen because it fits the evidence, not because it produced the most favourable number. Many of the reasons EOT claims get rejected come back to a methodology that does not match the records. The method is challenged, the analysis is discredited, and the substantive delay events are never properly considered at all.

There is also a forum question that contractors underestimate. Acceptance of the four methods varies between jurisdictions and between dispute forums. An adjudicator working to a short timetable will read a window analysis differently from a three-member arbitral tribunal with a full expert process and months to sit. A method that is proportionate in one setting is thin in the other. Settling the method early, with the forum in mind, is part of the same conversation as settling the theory of the claim.

The Mistakes That Lose Claims

The mistakes that cause a delay analysis to fail under scrutiny follow a predictable pattern. The first is selecting the method before auditing the records. The second is applying the method without acknowledging its limitations in the specific context. The third is presenting a one-sided analysis that ignores contractor-caused delays. The fourth is failing to reconcile the analytical result with the actual project delay. The fifth, and the most damaging, is treating the delay analysis as an advocacy exercise rather than an expert one. An analysis that reads like a submission rather than an opinion will be treated as a submission, and its evidential weight adjusted accordingly.

CALIM selects the delay analysis methodology after auditing the contemporaneous records, never before. The method is matched to the evidence, the contract and the forum. The analysis accounts for every delay event regardless of which party caused it, and it states its own limitations rather than waiting for the other side to find them.

Where the records will not support the method a claim needs, we say so early, while there is still time to repair the record keeping on the live project. Contractors work with our delay analysis and claims and recovery teams on exactly that problem, and those without a permanent commercial function get the same discipline through outsourced contract management.

The method that fits the evidence is the method that survives cross-examination.

Frequently Asked Questions

Time impact vs as-planned vs as-built: which method should I use?

Use time impact analysis if you have an accepted baseline programme and regular updates, because it measures each delay event prospectively at the point it occurred and is the method arbitrators most often prefer. Use as-planned vs as-built if you only have a baseline and a record of actual dates, accepting that it proves less. Use collapsed as-built if the baseline is unreliable but the site records are strong. The evidence decides, not the preference.

Which delay analysis method do arbitrators prefer?

Time impact analysis is generally preferred by arbitrators because it reflects the reality of how delays affect a live programme rather than how they appear with hindsight. Its weakness is that it requires a robust and properly updated baseline programme, which many contractors do not maintain. Where that baseline does not exist, a well-executed window analysis usually carries more weight than a time impact analysis built on a reconstructed programme.

What is the difference between as-planned vs as-built and window analysis?

As-planned vs as-built compares the original programme with the actual outcome in a single comparison across the whole project. Window analysis divides the project into discrete periods and analyses delay within each period separately, capturing how the critical path moved over time. Window analysis is generally more reliable because it reflects the dynamic nature of construction programmes, but it needs a contemporaneous programme update at every window boundary to be credible.

When should I use time impact analysis instead of another method?

Time impact analysis is appropriate when three things are true. The contractor maintained a baseline programme that the Engineer accepted, kept regular updates reflecting actual progress, and holds contemporaneous records documenting each delay event in enough detail to model its impact. If those records do not exist the method should not be attempted, because the analysis will rest on assumptions rather than evidence and will be vulnerable to challenge on every point.

When should I use collapsed as-built?

Collapsed as-built is the method of choice when the baseline programme is unreliable or unavailable but the as-built record is detailed enough to reconstruct what actually happened. It works backwards from the actual completion date, removing delay events one by one to establish what the completion date would have been without each of them. It is more complex than the alternatives and it can be contentious, because the logic imposed on the as-built programme is the analyst's judgement rather than a contemporaneous document.

What does the SCL Protocol say about choosing a delay analysis method?

The SCL Protocol states that no single methodology is inherently superior and that the choice depends on the circumstances, including the quality of the programme records, the nature of the delays and the contractual requirements. It recommends that the analyst explain why the chosen method was selected and why alternatives were not. It treats time impact analysis and window analysis as generally more reliable than a simple as-planned vs as-built comparison, provided the evidential foundation supports their use.

What is the most common mistake in delay analysis?

The most common mistake is selecting the methodology before auditing the available evidence. An analyst who commits to time impact analysis at proposal stage and then discovers that the baseline was never accepted has a foundational problem no amount of rigour will fix. The second most common mistake is presenting a one-sided analysis that attributes all delay to the employer and ignores contractor-caused delay, which destroys credibility before the substantive issues are reached.

Can I change the delay analysis method after starting the analysis?

Yes, and in some cases you should. If the evidential audit reveals that the records cannot support the method first selected, continuing with it produces an analysis that will not withstand scrutiny. The SCL Protocol does not ask the analyst to commit to a method at the outset. It asks the analyst to select and justify the method that best fits the circumstances, so changing after an honest assessment of the evidence is a sign of discipline rather than indecision.

Note: This article provides general guidance on delay analysis methodology selection and application under FIDIC and NEC contracts and the SCL Delay and Disruption Protocol. The methodology appropriate to any particular delay claim depends on the contract terms, the available records, the nature of the delays and the requirements of the dispute forum. Contractors should engage a qualified delay analyst to assess their own circumstances before committing to a methodology.