How to Do Delay Analysis: A Complete Guide to TIA, Windows, and As-Built Methods

Construction delays cost the global industry billions each year. When projects run late, someone has to pay—but determining who is responsible and for how much requires rigorous delay analysis.

This guide explains the three main methods used by claims professionals worldwide: Time Impact Analysis (TIA), Windows Analysis, and As-Built vs As-Planned comparison. By the end, you'll understand when to use each method and how to produce defensible delay reports.

What is Delay Analysis?

Delay analysis is the process of examining a project schedule to determine the causes, responsibility, and duration of delays. It forms the technical backbone of Extension of Time (EOT) claims and delay damages disputes.

The goal is straightforward: identify which events caused the project to finish late, quantify the impact of each event, and attribute responsibility to the appropriate party—whether that's the contractor, employer, or neither (excusable delays).

Professional delay analysts typically work with Primavera P6 or Microsoft Project schedules, comparing baseline programmes against as-built records to trace the critical path through the project's history.

Why Methodology Matters

The Society of Construction Law (SCL) Delay and Disruption Protocol—the industry's most widely referenced guidance—emphasises that delay analysis must follow a recognised methodology to be credible.

Using an ad-hoc approach or cherry-picking favourable data will be exposed under cross-examination. Tribunals and adjudicators expect to see:

• A clear statement of the methodology used
• Logical links between cause and effect
• Traceable data sources (schedules, progress records, correspondence)
• Consistent treatment of all delay events—not just those favouring your client

The Three Main Delay Analysis Methods

1. Time Impact Analysis (TIA)

Time Impact Analysis is considered the most rigorous method because it models the impact of each delay event at the point it occurred, using the schedule logic and status from that time.

How it works:

1. Take the contemporaneous schedule (the programme as it existed when the delay event started)
2. Create a 'fragnet'—a network of activities representing the delay event
3. Insert the fragnet into the schedule with appropriate logic links
4. Recalculate the critical path
5. Compare completion dates: the difference is the delay impact

---

2. Windows Analysis

Windows Analysis divides the project into time periods ('windows') and analyses the critical path movement within each window. This shows how delays accumulated over time and identifies who was responsible for delays in each period.

How it works:

1. Divide the project duration into logical windows (typically monthly or aligned with schedule updates)
2. For each window, update the schedule with actual progress and delay events
3. Identify the critical path at the start and end of each window
4. Attribute any delay or acceleration to specific events
5. Sum the delays across all windows to determine total project delay

---

3. As-Built vs As-Planned Comparison

This is the simplest method: compare what was planned against what actually happened. It shows where and when activities deviated from the baseline programme.

How it works:

1. Take the approved baseline programme
2. Overlay actual start and finish dates for each activity
3. Identify activities that finished late
4. Trace the critical path to determine which late activities caused project delay

Choosing the Right Method

The choice of method depends on several factors:

• Data availability: TIA requires contemporaneous schedules; Windows works with periodic updates; As-Built needs only baseline and actual dates
• Timing: TIA is best applied during the project; Windows and As-Built are typically retrospective
• Complexity: Simple projects may only need As-Built; complex projects with concurrent delays warrant Windows Analysis
• Contract requirements: Some contracts specify which methodology must be used for EOT claims
• Value at stake: Higher-value disputes justify the extra effort of TIA or Windows Analysis

Common Pitfalls to Avoid

After reviewing hundreds of delay claims, these are the most frequent errors:

1. Ignoring concurrent delay: When multiple parties cause delay simultaneously, apportioning responsibility requires careful analysis. Don't assume your client's delays would have been absorbed by the other party's delays.
2. Using hindsight: Applying what you know now to decisions made then is unfair and will be challenged. Each delay should be assessed based on information available at the time.
3. Cherry-picking data: If you only analyse delays that support your position, the other side will expose what you've omitted. Analyse all significant delays fairly.
4. Neglecting float: Not every late activity causes project delay. Only delays that consume float and affect the critical path extend completion.
5. Poor documentation: If you can't show where your data came from, your analysis won't be trusted. Maintain clear audit trails to source schedules and progress records.

The Manual Analysis Problem

Performing delay analysis manually is extraordinarily time-consuming. A typical Windows Analysis involves:

• Exporting P6 data to Excel
• Manually comparing thousands of activities across multiple schedule versions
• Building charts and visualisations by hand
• Formatting professional reports
• Repeating the entire process when methodology is challenged

Most experienced delay analysts estimate 3-5 days for a thorough analysis—time that could be spent on higher-value work like expert opinion and strategy.

Modern Approaches to Delay Analysis

Specialised delay analysis software can dramatically reduce the time required while improving consistency and auditability. These tools typically:

• Import P6 XER files directly, eliminating manual data entry
• Automate the comparison of schedule versions
• Generate professional reports with charts and attribution tables
• Provide audit trails that satisfy SCL Protocol requirements
• Allow rapid re-analysis when assumptions change

What once took days can now be completed in hours, allowing claims professionals to focus on interpretation and strategy rather than data processing.

Key Takeaways