Delay Analysis Methods
aka: “How to Prove It’s Not Your Fault — With Schedules, Not Speeches.”
In construction, saying “we were delayed” isn’t enough.
If you're claiming an Extension of Time (EOT), you must show — with logic and timelines, not emotion — how the delay affected the critical path.
Let’s walk through the four main delay analysis methods, with real-life examples, pitfalls to avoid, and how each method holds up in arbitration.
1. Impacted As-Planned
What It Is:
Start with the original baseline schedule. Insert the delay event. See how far the finish line moves.
Analogy: A Domino Line
Imagine you’ve set up a line of dominos. You place a rock in front of the third domino — now the fall is delayed.
You haven’t changed anything else — just blocked that one spot and watched the impact ripple forward.
That’s Impacted As-Planned: insert one delay into the baseline and see how far it pushes the end.
Simple, clean, but assumes the rest of the dominos always fell perfectly.
Example:
Baseline Completion: Day 100
Client delays foundation drawings by 7 days
Foundation shifts → Structure shifts → Handover shifts
New Completion: Day 107
Claim: 7-day EOT
Wind Turbine Project, Tamil Nadu
Delay Event: Grid connection drawings delayed 14 days
Approach: Inserted delay into baseline schedule
Claim: 14-day EOT
Common Mistakes:
Assuming the baseline was perfect
Ignoring later contractor-caused delays
Lack of narrative linking delay to dependent activities
In Arbitration:
Preferred? Rarely — seen as simplistic
Tribunal View: “Useful to show early impact, but needs validation with actual progress”
Pro Tip: Pair with records — transmittals, emails, site minutes — to back the modeled shift.
2. Time Impact Analysis (TIA)
What It Is:
Use the latest updated schedule. Insert the delay event. Simulate its impact on the remaining timeline.
Analogy: A GPS Reroute During the Journey
You’re 60 km into a 100 km road trip, and suddenly there’s a traffic jam ahead.
You open Google Maps, drop the new delay into your live route, and see that your ETA shifts by 30 minutes.
That’s TIA — take the actual project position, drop in the delay, and simulate the effect forward.
Works great if your GPS (schedule) is up to date.
Example:
Day 60 of a 100-day project
Electrical design delayed by 10 days
Remaining tasks shift forward
New Completion: Day 110
Claim: 10-day EOT
Data Centre Project, Singapore
Delay Event: 10-day delay due to added SCADA requirement
Approach: Inserted delay into latest Primavera schedule
Claim: 10-day EOT
Common Mistakes:
Using outdated or poorly updated schedules
Not modeling float properly
Failing to align delay with actual critical path
In Arbitration:
Preferred? Frequently — especially under FIDIC
Tribunal View: “Effective if consistently applied and transparently documented”
Pro Tip: Be ready to explain assumptions and software logic.
3. As-Built vs As-Planned
What It Is:
Compare what was planned vs. what actually happened. Assess delays retrospectively.
Analogy: A Before-and-After Fitness Photo
You planned to lose 10 kg in 10 weeks. But now it’s week 10, and you compare your original diet plan with what actually happened (skipped workouts, birthday cake).
The side-by-side photos tell the story.
That’s As-Built vs As-Planned — comparing your goal vs your actual, to see where you fell off schedule.
Honest. Brutal. But only works if you tracked your meals and gym visits (records!).
Example:
Planned: Foundation complete by Day 15
Actual: Completed on Day 30
Delay examined for critical path impact
Claim based on real slippage
Highway Project, Rajasthan
Delay Cause: Monsoon + delayed approvals
Approach: Compared baseline with site logs
Result: Partial EOT granted
Common Mistakes:
Overlooking own delays
Incomplete or missing site records
Confusing correlation with causation
In Arbitration:
Preferred? Yes — especially for completed projects
Tribunal View: “Fact-based and persuasive if supported by records”
Pro Tip: Own up to your share of delays. It builds credibility.
4. Window Analysis
What It Is:
Split the project into time periods (weekly/monthly/milestones). Analyze delays within each “window.”
Analogy: A Monthly Bank Statement Audit
Instead of looking at your whole year’s finances at once, you go month-by-month:
In Jan, high restaurant bills. In Feb, a salary bonus. In March, medical expenses.
That’s Window Analysis — break down your project into “statements,” analyze each period for delays, who caused them, and how they added up.
Tells the evolving story of delay. But only works if your monthly data is clean.
Example:
A 6-month project → 6 windows
Compare planned vs. actual progress per window
Identify who caused delays and their impact on the critical path
Build a phased EOT claim
Hospital Build, Kerala
Approach: 6 windows (each 3 months)
Findings:
Window 1: Employer design delays
Window 4: Labor strike (contractor fault)
Claim: 35-day EOT granted for employer-caused delays
Common Mistakes:
Choosing windows that are too short (creates noise) or too long (dilutes clarity)
Poor attribution of delay causes
Gaps in documentation
In Arbitration:
Preferred? Highly — tribunals see it as robust
Tribunal View: “Best method for allocating responsibility across a project timeline”
Pro Tip: Use visuals (bar charts, time slices) to support your story.
Which Method Is Best?
It depends on:
Your contract (some specify method)
Schedule quality (baseline + updates)
Documentation of delay events
Your audience (Engineer, DAB, Arbitrator)
The more defensible and data-driven your method, the stronger your EOT claim.
Delay analysis isn’t about fancy software or long reports.
It’s about connecting the dots — between cause, impact, and entitlement.
In construction disputes, you don’t win by saying you were delayed.
You win by showing how, when, and why — with precision.