Views in the last 30 days: 48
Estimated read time: 31 minute(s)
Understanding delays is key to managing construction contracts, whether under FIDIC or NEC forms. Below we explore six common delay analysis methodologies – what they are, how they work, and their pros/cons – with simple examples to keep things practical and engaging. 😊
Introduction 🤝
Construction projects rarely go exactly as planned – delays happen! Contract managers often need to analyze how and why the project got delayed to determine entitlements for Extension of Time (EOT) or assess liability.
There isn’t a one-size-fits-all approach; experts use several recognized methods to analyze delays. The UK Society of Construction Law (SCL) Protocol (2nd Ed.) outlines six widely used techniques:
- Impacted As-Planned Analysis
- Time Impact Analysis (TIA)
- Time Slice Window Analysis
- As-Planned vs As-Built Analysis
- Retrospective Longest Path Analysis
- Collapsed As-Built Analysis (a.k.a. As-Built But-For Analysis)
Each method differs in when and how it evaluates delays. Some are prospective (predicting impact at the time of events), while others are retrospective (assessing impact after the fact using actual data).
For example, the SCL Protocol recommends using a prospective Time Impact Analysis during project execution.
🔍 Prospective vs Retrospective Delay Analysis – What’s the Difference?
Think of it like looking through a windshield vs checking the rearview mirror while driving:
Prospective = 🔮 “What will happen because of this delay?”
→ You’re forecasting the potential impact of a delay before or as it occurs.
Retrospective = 🔙 “What actually happened and why did we finish late?”
→ You’re looking back after the event or project to understand the actual delay and its causes.
Let’s say you’re planning a vacation road trip 🧳🚗:
- 🔮 Prospective thinking:
You see on Google Maps that there’s traffic on your route ahead. You estimate you’ll be delayed by 30 minutes and let your friends know you’ll arrive late. You’ve predicted the impact before you even hit the jam. - 🔙 Retrospective thinking:
You reach the destination an hour late. Now you check: Was it the traffic? Did you stop for snacks too long? Maybe your friend took the wrong exit? You’re analyzing after the fact what caused the delay.
🛠️ In Construction Delay Analysis:
🏗️ Construction Examples
✅ Prospective Example (During the project):
- You’re in Week 10 of a 40-week project.
- There’s a design change that requires 7 extra days.
- You take the updated program as of Week 10, insert the new activity for the change, and recalculate.
- The new completion date is pushed by 7 days.
- You apply for Extension of Time (EOT) using this analysis. 👉 This is Time Impact Analysis (TIA) — classic prospective method.
✅ Retrospective Example (After the project ends):
- The project was supposed to finish on 30th Sept but completed on 20th Oct (20 days late).
- You reconstruct the as-built program and analyze:
- 5 days delay due to late drawings (Engineer’s fault)
- 10 days due to heavy rains (force majeure)
- 5 days due to subcontractor error (Contractor’s fault)
- You now apportion delays and decide if the contractor is eligible for EOT or LADs apply. 👉 This is Windows Analysis or As-Built But-For — classic retrospective.
💬 Pros & Cons Summary
| Type | 👍 Pros | 👎 Cons |
|---|---|---|
| Prospective |
– Timely EOT decisions – Less chance of dispute – Matches NEC’s early warning culture |
– Needs reliable current data – Not good for after-project claims – Can miss shifting critical paths |
| Retrospective |
– Reflects what actually happened – Good for arbitration/litigation – Useful if no timely updates were done |
– Time-consuming – Needs accurate as-built data – Can be biased if not modeled properly |
In practice, contract conditions influence the approach: NEC contracts explicitly promote a prospective analysis (essentially a TIA) when assessing delays from compensation events during the project
FIDIC contracts, on the other hand, don’t mandate a specific method – EOT claims under FIDIC often end up using retrospective analyses if not resolved in real-time, relying on the best data available after delays occur.
No matter the method, the goal is the same: determine how delays affected the project’s completion date and who is responsible. Let’s dive into each methodology in a conversational way, with simple examples and even a few emojis to keep things fun! 🤓📝
(Throughout the article, we’ll also mention common scheduling tools (like Oracle Primavera P6 or MS Project) used to perform these analyses.)
🧱 What is a Baseline Schedule?
A baseline schedule is like the master plan or roadmap of the entire construction project — it shows when and how each activity is planned to happen, from start to finish.
Think of it as the original promise the contractor makes to the employer:
“Here’s how I plan to build your project – step-by-step, week-by-week, and this is when I expect to finish.”
🎯 Baseline Schedule = Original Time Plan (agreed before starting work)
📘 Example
Let’s say you’re building a commercial tower:
| Activity | Planned Start | Planned Finish |
|---|---|---|
| Site Mobilization | 1 Jan | 10 Jan |
| Excavation | 11 Jan | 30 Jan |
| Foundation | 1 Feb | 20 Feb |
| Structure (G+5 floors) | 21 Feb | 30 June |
| Finishes | 1 July | 31 Aug |
| Handover | 1 Sep | 5 Sep |
🗓️ Planned Completion Date: 5 September
This schedule (usually built in Primavera P6, MS Project, or similar software) becomes your baseline schedule once it’s reviewed and approved by the Engineer or Project Manager.
🛠️ What’s in a Baseline Schedule?
- 📅 Start and finish dates for all key activities
- 🔗 Logic links between tasks (e.g., you can’t pour concrete until rebar is placed)
- 🧩 Critical Path – the chain of activities that controls the project completion date
- 📈 Float/slack – how much flexibility an activity has before it delays the project
- 📊 Usually presented as a Gantt Chart or network diagram
🧮 Why is it so Important?
- Performance measurement
Like a fitness goal — you keep comparing your actual progress against your baseline to see if you’re on track 🏃♂️💨 - Delay Analysis
All delay methods (like Impacted As-Planned or TIA) use the baseline as the reference point to measure how far off you are. - Extension of Time (EOT)
In FIDIC or NEC contracts, you often need to show how a delay impacted the baseline completion date to justify an EOT.
🧠 In NEC & FIDIC Contexts:
🔹 NEC4:
- The “Accepted Programme” is essentially the baseline.
- Clause 31.2 requires detailed programming including logic, float, and risk allowances.
- It’s updated regularly, but your first submitted and accepted programme = your original baseline.
🔹 FIDIC 2017:
- Clause 8.3 (Programme) requires the Contractor to submit a programme showing the order and timing.
- While it doesn’t use the term “baseline,” the Engineer-approved version acts as the contractual baseline for monitoring and delay claims.
❗ One Golden Tip
📌 Baseline is not a static document. It’s the original benchmark, but projects evolve.
That’s why updates and revisions to the schedule are compared against the original baseline to measure deviations and calculate delays.
1. Impacted As-Planned Analysis 🗓️
What is it? Impacted As-Planned is a prospective analysis that starts with the original baseline schedule (the “as-planned” program) and adds the delay events into it to see how the completion date shifts.
Essentially, you’re taking the plan and “impacting” it with delays to measure their effect.
How it works:
Imagine you had a baseline schedule showing project completion on Day 100. Now, suppose a delay event (e.g. late delivery of steel) is expected to take 5 extra days and occurs around Day 20. In an Impacted As-Planned analysis, you:
- Insert a new activity or extend an existing one to represent this 5-day delay at the right spot in the schedule
- Recalculate the schedule (i.e., run the critical path)
- If the project finish date shifts from Day 100 to Day 105, that’s a 5-day delay impact due to the event
- Repeat for multiple delay events (either one-by-one or together) to see cumulative impact
You plan to build a house in 10 weeks. In week 3, a design change is introduced that adds 1 week of work.
👉 Using Impacted As-Planned:
- You take your original 10-week plan
- Insert a 1-week “design change” activity at week 3
- Recalculate the schedule → the finish date moves to 11 weeks
🎯 The extra week is the delay impact due to the design change.
Pros 👍 & Cons 👎:
Pros 👍:
- Easy to understand: It’s straightforward and intuitive – you literally see the effect of delays on the planned program. Even non-experts can grasp the “before vs after” comparison.
- Quick for simple cases: Suitable for smaller or less complex projects where a quick analysis is needed. Contract managers appreciate that it’s not overly technical.
- Useful early on: Great for what–if scenarios before or during project execution. For instance, if a potential change is proposed, you can model it on the baseline to predict the impact (contractors often do this to negotiate EOTs or acceleration).
Cons 👎:
- Theoretical (ignores actual progress): It assumes everything goes as per the original plan except the added delays. Real life is rarely so neat – if the project was already running late or re-sequenced, this method doesn’t account for that.
- Not ideal for complex/concurrent delays: If multiple delays overlapped (concurrency) or the critical path shifted during construction, an impacted as–planned won’t reflect those nuance. It can oversimplify complex interactions by sticking to the original critical path only.
- Data sensitivity: It relies on having a credible baseline schedule. If the baseline was poorly made or not accepted by stakeholders, the analysis could be questioned. (After all, if your starting plan was flawed, adding delays to it may not prove much.)
Tools: Impacted As-Planned can be performed in standard scheduling software. For example, using Primavera P6, an analyst would take a copy of the baseline, insert fragnet (fragmentary network) activities for each delay, and then calculate the new end date
In MS Project, one might do similarly by adding tasks or extending durations. Both tools will show the shift in the Gantt chart, which you can then compare to the original plan. This simplicity is one reason the method is popular for quick analyses.
2. As-Built But-For Analysis (Collapsed As-Built) 🏗️
What is it? As-Built But-For analysis (also known as Collapsed As-Built) is a retrospective method (meaning it looks backward using actual project data). It works in reverse to the Impacted As-Planned method.
Here, we start with what actually happened (the as-built schedule) and remove specific delay events to see how much earlier the project would have finished “but for” those delays.
It’s like subtracting delays from reality to isolate their impact.
How it works:
- You take the final as-built timeline of the project (including all delays).
- Identify delay events caused by others (e.g., the Employer).
- These delay events are represented in the schedule (as added activities or extended durations).
- You then remove those events (or reduce their durations) from the schedule — “collapsing” it as if those delays never occurred.
- Recalculate the schedule to see the new finish date.
- The difference between the actual finish and the recalculated finish is the delay impact caused by those removed events.
For fairness, only delays caused by others are removed — contractor-caused delays remain. This way, the analysis doesn’t let the contractor escape responsibility.
Your project actually finished on March 31st, which was 30 days late.
During the project:
- 10-day delay due to late site access by the Employer
- 20-day delay due to Contractor’s slow-down
👉 In the Collapsed As-Built analysis, you remove the 10-day late access event. The recalculated finish now shows March 21st. That means the Employer caused 10 days of the total delay, and the remaining 20 days are on the Contractor.
Pros 👍 & Cons 👎:
Pros 👍:
- Uses real data: This analysis is grounded in actual events and durations – making it very factual. It answers “What actually delayed us?” by looking at the real timeline. This makes findings more credible, as it’s based on the actual project record.
- No baseline needed: Even if you lacked a proper baseline program, you can still do a collapsed as-built. This is helpful when the original plan was unreliable or poorly updated — you simply reconstruct what actually happened.
- Clarifies concurrency: It naturally reveals overlapping delays. By removing one party’s delays, any remaining delays point to the other party. This makes it easier to demonstrate delay responsibility in disputes.
Cons 👎:
- Challenging for complex projects: With hundreds of activities, creating a reliable as-built schedule with proper logic links is tough. Removing events without “breaking” the logic is technically tricky — it’s an intensive, expert-driven exercise.
- Potential for bias: Adjusting logic links to remove delays can introduce bias (even unintentionally). Results may vary between analysts, and courts may challenge whether your analysis is objectively correct.
- Data hungry: Though it doesn’t require a baseline, it demands detailed as-built data and records. If start/finish dates weren’t well documented, the whole analysis becomes a guessing game — and less reliable in disputes.
🛠️ Tools: How Is Collapsed As-Built Done in Practice?
Building an as-built program and modifying it is typically done using scheduling software like Primavera P6 or Microsoft Project. Here’s how it works in real-world scenarios:
- 🧠 Primavera P6 – Preferred for complex logic-heavy schedules. Its strong Critical Path Method (CPM) engine makes it ideal for forensic delay modeling and link tracing on large projects.
- 🖥️ MS Project – Great for smaller or less complex schedules. It can handle actual dates and dependencies, but may fall short when advanced logic tweaking is needed.
- ✂️ Removing delays – You either delete the delay activity, set its duration to 0, or unlink it from dependent tasks. This “collapses” the schedule to simulate a world without that delay.
- 🧰 Other tools – Some experts use specialized forensic software like Deltek Acumen Fuse or Asta Powerproject, but most stick with P6, MS Project, or similar tools.
- 📊 Visual output – The result (a collapsed timeline) is typically shown as a bar chart comparing the original as-built vs. the “but-for” scenario. Great for stakeholder reports or dispute presentations!
3. As-Planned vs As-Built Analysis ⚖️
What is it? As-Planned vs As-Built is the most straightforward retrospective delay analysis. It directly compares the original plan (as-planned schedule) with what actually happened (as-built schedule) to identify overall delays and investigate their causes.
🧭 Think of it as a high-level “difference check” between plan vs reality, followed by a reasoned explanation of what caused the deviations.
How it works:
- Take the baseline schedule and the final as-built timeline.
- Compare activity-by-activity to see where durations or finish dates diverged.
- For each delay or early completion, identify the cause by reviewing site records, logs, meeting minutes, and weather data.
- The method may apply to the entire project or be split into periods (time windows) for more detail.
- Finally, apportion the total delay to different causes using expert judgment (e.g., weather, client changes, contractor delays).
The baseline schedule for a road project showed completion by Dec 1. In reality, the project was completed by Jan 15 — a 45-day delay.
- Earthworks: Planned to finish by June 30, actually finished July 15 — 15 days late due to heavy rains ☔️ (excusable).
- Paving: Planned to finish by Oct 31, actually finished Nov 30 — 30 days late due to late design change ✏️ (compensable).
👉 The total delay = 45 days, broken down into:
• 15 days = excusable (rain)
• 30 days = compensable (design change)
Pros 👍 & Cons 👎:
Pros 👍:
- 🧠 Common-sense approach: It’s very easy to grasp for all parties. You’re literally saying “We planned X, but actually Y happened.” This storytelling style mirrors real-world project memory and helps everyone relate.
- 📉 Ideal when baseline is in doubt: If the baseline or updates weren’t reliable, sometimes the only thing agreed upon is the actual outcome. This method leans on the as-built timeline and uses the plan just as a reference.
- 🖊️ Less software-heavy: It can be done even outside of advanced scheduling tools — on paper, Excel, or timelines. It relies on expert reasoning and project logs more than algorithmic modeling, which can help in legal settings or mediation.
Cons 👎:
- ⛏️ Labor-intensive expert analysis: Without a proper CPM model, it’s hard to identify the true critical path. Experts may reach different conclusions about what caused the delay, leading to potential disputes.
- 🎯 Lacks the precision of a model: Comparing plan vs actual doesn’t inherently separate concurrency or logic shifts. It gives a global view, which may miss finer delay mechanics like float changes or resequencing.
- ⚠️ Potentially less “formal”: Some critics argue that it lacks rigor. If poorly done, it might feel like a blame game (“X caused delay because it feels like it did”) without hard evidence. That said, when done thoroughly, it can still be persuasive.
🛠️ Tools: How As-Planned vs As-Built Analysis Is Done
This method can range from very simple to quite detailed depending on the tools you use — but ultimately, the real work lies in expert judgment, not just software output.
- 📊 Excel or Timeline Charts – At its simplest, you can line up planned vs actual dates in Excel, using color-coded bars or basic timelines. This works for small to mid-size projects or early-stage investigations.
- 🖥️ Primavera P6 or MS Project – These allow you to maintain both the original baseline and actual progress schedules. Analysts can overlay Gantt charts or compare schedule versions visually.
- 📈 Delay Histograms – Some practitioners import both the as-planned and as-built schedules into software to generate histograms showing cumulative delays by period or activity group.
- 🧩 Specialized Visualization Tools – Some use tools like Asta Powerproject or forensic add-ons that can show both schedules side-by-side with visual cues to spot variances quickly.
- 🧠 Human Analysis Is Key – Software helps visualize the differences, but identifying why those differences happened depends on site diaries, change orders, reports, and the analyst’s experience. It’s more art than math at times.
4. Time Impact Analysis (TIA) ⏱️
What is it? Time Impact Analysis (TIA) is a prospective delay analysis method used during the project to evaluate the effect of a delay event at the time it happens.
It’s similar to Impacted As-Planned but based on a current updated schedule (not just the baseline). It’s often done event-by-event as new delays emerge, making it a live and contemporaneous tool.
How it works:
- At any point in the project (say, month 6), if a delay occurs (e.g., storm, site access issue), you take the latest approved schedule update as your starting point.
- Insert a fragnet (a mini-network of affected activities) representing the delay — for example, a 5-day no-work period linked to the affected path.
- Recalculate the schedule. If the finish date shifts from Oct 1 to Oct 6, TIA shows a 5-day impact from the delay.
- The goal is to grant an EOT prospectively, based on known information, rather than waiting till project closeout.
- For multiple events, separate TIAs are done as part of successive monthly updates.
In February, the contractor hits an unforeseen underground utility, causing a 10-day excavation delay.
👉 Using a TIA:
- The planner takes the January updated schedule (which showed completion by Aug 30).
- They insert a 10-day fragnet into the excavation activity.
- Recalculate the schedule → finish date shifts to Sep 9.
🎯 TIA recommends a 10-day EOT. If another delay happens in March, a new TIA will be done on the March update, and so on.
Pros 👍 & Cons 👎:
Pros 👍:
- ⚡ Proactive and timely: TIA is done concurrently with the project, so delay impacts and EOTs are addressed as events occur. This aligns with NEC’s “no surprises” culture and reduces disputes later.
- ✅ Widely accepted (when done properly): TIAs are respected when tied to CPM scheduling and current updates. The SCL Protocol endorses it, and many contract admins feel confident granting EOT based on a systematic TIA.
- 📌 Breaks down delay by event: By inserting one fragnet at a time, you can trace delay cause and effect clearly. This helps justify why X days were granted for Y event, and creates excellent documentation for future claims or audits.
Cons 👎:
- 📉 Data and skill intensive: Requires a good, up-to-date schedule. Without accurate monthly progress records, TIA results may be unreliable (“garbage in, garbage out”). Skilled scheduling is a must.
- 📚 Cumbersome for many events: Doing TIA retrospectively for dozens of events can be slow and less accurate. Experts generally recommend TIA for live use only — not as a catch-up exercise after project closeout.
- 🧠 Technical complexity: Interrelated events, fragnet logic, and event order make this method complex for large projects. It’s doable, but needs careful tracking, consistent analysts, and disciplined documentation to avoid errors.
🛠️ Tools: How TIA Is Executed in Practice
Time Impact Analysis is best performed in professional scheduling software that can manage evolving project data and quickly recalculate impacts. Here’s how it’s usually done:
- 📅 Primavera P6 – The industry standard for TIA. It handles multiple baselines, schedule updates, and fragnet insertions with ease. Planners typically:
- Maintain an “accepted programme” (NEC term) or current update
- Copy the file upon delay occurrence
- Insert the fragnet (mini delay network)
- Run the schedule and record the shift in finish date
- 🧾 Claim Digger or Similar Tools – These comparison utilities (built into P6 or available as plugins) help visualize the impact by highlighting what changed before vs after the fragnet was inserted.
- 🖥️ MS Project – Usable for simpler projects. You can:
- Save a baseline
- Add a delay task linked to impacted activities
- Note the slip in project completion date
- ⚙️ Key requirement: The software must be able to recalculate the critical path instantly so the analyst can simulate delay impacts event by event and iterate quickly.
5. Time Slice Windows Analysis 🪟
What is it? Time Slice Windows Analysis (or just Windows Analysis) is a detailed retrospective delay analysis method that divides the overall project into smaller time periods called “windows” or “slices”. It then reviews how the forecasted completion date changed from the beginning to end of each slice — and investigates why.
🔍 It’s like breaking the project into segments and asking: “What happened in this slice? Did we gain time or lose time? And what caused it?”
How it works:
- The project duration is split into logical windows — usually monthly updates, major milestones, or construction phases.
- For each window, compare the schedule status at the start vs. the end of that window.
- Track the shift in predicted project finish — this is the delay (or gain) for that window.
- Investigate what caused that shift by reviewing which activities were critical during the window and what affected them.
- Chain all windows together: each one tells a part of the delay story. You then sum up delays across all windows and attribute them to events or parties.
- This method reflects that the critical path can change over time — so each window uses the contemporaneous critical path.
A building project runs from Jan to Dec (12 months). You break the project into monthly windows (Jan, Feb, …, Dec).
- 📅 End of Jan: Update forecasts completion on Nov 30.
- 📅 End of Feb: Now forecast says Dec 10 → a 10-day delay in Feb.
- 🧐 You review Feb’s window: 5-day bad weather + 5-day late approval = 10-day slip.
- 📅 End of Mar: Now forecast is Dec 5 → a 5-day gain due to acceleration.
🔄 Repeat this for all months → the sum of delays and gains across each window forms the full delay narrative, with responsibility traced window by window.
Pros 👍:
- Captures changing critical paths: This method recognizes that what was critical in March might not be critical in July. By doing segment-by-segment analysis, it reflects the dynamic nature of project execution. This often gives a more accurate and fair delay attribution in long, complex projects.
- Detailed and analytical: It’s systematic and broken into manageable pieces. Each window isolates a time period, making it easier to link delays to specific events and to consider any mitigation or acceleration within that period. Courts and experts consider window analysis as a robust approach when done with good data, since it considers “any and all” causes in each time slice.
- Balances prospective & retrospective: Windows analysis mainly looks retrospectively at what did happen in each window, but it uses the contemporaneous schedule updates (the forecasts at the time) as a basis. This means it respects what was known/planned at each stage (avoiding hindsight bias) while still analyzing actual delays. It’s a nice blend of fairness: using each update as a yardstick for that period’s delays.
- Good for complex disputes: If you’re heading to arbitration on a multi-year project with lots of changes, a time slice analysis provides a narrative of the project’s delay evolution. It can handle concurrency by showing if in a given window two delays happened, how each affected the completion prediction. This level of detail can make for a convincing expert report.
Cons 👎:
- Data heavy and time consuming: You need all the periodic schedule updates or the ability to recreate them. Each window needs analysis – which could mean dozens of mini-analyses. This is labor-intensive, often requiring specialized consultants. Not all projects have complete update files, so sometimes analysts have to reconstruct missing updates which is extra work.
- Complex to present: The results of a windows analysis can be overwhelming to a layperson if not summarized well. Imagine explaining 12 windows worth of delays – it’s easy to get lost in the weeds. Thus, while the method provides a lot of detail, one must distill it into clear findings (often via charts or tables) for contract managers or tribunals.
- Potential disputes on window selection: How you choose the window boundaries can affect results. Usually monthly or milestone-based windows are used, but there’s some subjectivity there. One party might say a different window breakdown shows the delays differently. That said, if windows are logical (e.g. by updates or key events), this is a minor issue, but it’s something to be mindful of (the SCL Protocol even discusses window selection considerations).
- Resource intensive: Because it’s essentially doing multiple analyses, you need good software and expertise. It’s almost impossible to do manually. Typically, Primavera P6 is used with each update saved, and possibly macros or tools to automate comparisons. Not every organization has the capacity to undertake this unless the claim value justifies it.
Tools: Primavera P6 is the go-to for window analysis, since it handles schedule updates and can compare changes. Analysts often use add-on tools or scripts to speed up comparing one update to the next (for example, some use Excel exports of P6 data to track slippage each period, or tools like Steelray or Acumen Fuse to visualize changes). MS Project could theoretically be used if the project was managed in it with regular updates, but extracting the needed info might require extra manual steps. Ultimately, whatever tool was used for project scheduling (P6, MS Project, Asta Powerproject, etc.), having all the update files is gold for window analysis. The output often includes charts showing period-by-period delay contributions, which are great for presentations. 📊
6. Longest Path Analysis 🏁
What is it? Longest Path Analysis (also called Retrospective Longest Path) is a backward-looking method that identifies the actual longest critical path in the as-built schedule and evaluates what delayed that path.
🧐 In simple terms: “Which sequence of activities ultimately controlled the project finish? Let’s analyze what slowed that down.”
How it works:
- After project completion, identify the as-built critical path — the longest chain of activities from start to finish with zero float.
- This can be done using schedule software or by manually analyzing site records and determining which sequence held up the finish.
- Once the path is identified (e.g., A → D → F → Completion), analyze what delayed each activity on that path.
- You may compare actual vs planned durations or remove specific delays to measure hypothetical early completion (like a collapsed as-built, but only for the final critical path).
- This method focuses only on the final critical path — ignoring delays on paths that were once critical but didn’t finish last.
Picture a relay race — only the slowest team’s time matters. In the project, that “team” is the longest path: Excavation → Foundation → Framing → Finishing.
- 🚧 Excavation: 5 days late due to rock (Employer’s risk)
- ⛏️ Foundation: 2 days late due to labor strike (Neutral event)
- 🏗️ Framing: On time
- 🎨 Finishing: 10 days late due to late material delivery (Contractor’s fault)
📊 Total delay = 17 days on the longest path.
→ You can then attribute: 5 days excusable, 2 days neutral, 10 days contractor delay.
Note: If something else delayed the project but wasn’t on the longest path, this method won’t capture it — because it only tracks what actually held up the finish.
Pros 👍:
- Simplicity in concept: It concentrates on the one critical sequence that actually finished last. This can simplify the analysis in a complex project – you zero in on one thread rather than juggling multiple paths. It feels intuitive to say “the project can only finish as fast as its slowest sequence, so let’s focus on that slowest sequence.”
- Efficient when one clear critical path exists: If the project had a dominant critical path that didn’t shift much, this method effectively captures the key delays without extra noise. It can be quicker than full window analysis in such cases, because you’re not analyzing periods when other paths might have been critical (which ultimately didn’t dictate the final finish).
- Good retrospective insight: It fully embraces hindsight (knowing what actually ended up critical). This can be powerful in claims: e.g., even if the contractor thought the critical path was through Task X in April, if by the end it turned out Task Y (different path) was actually the slowest, longest path analysis says Task Y’s delays are what truly mattered. It can cut through arguments about what might have been critical by focusing on what was critical in the end.
- Relatively straightforward to communicate: You can present it as “Here’s the chain of events that controlled the project timeline,” which is a clear narrative. It often pairs well with a timeline diagram of that critical path.
Cons 👎:
- Hindsight bias: By only looking at the final critical path, you ignore interim critical paths. In reality, projects often have periods where a different path was critical and caused interim delays (later overcome by resequencing or acceleration). Those delays might have cost money or resources even if at final completion they weren’t on the longest path. Longest Path Analysis might overlook such effects or concurrency issues by focusing only on one path.
- Oversimplification risk: Especially on projects where the critical path shifted, this method could be seen as too narrow. For instance, if in mid-project a major delay on another path was mitigated later, a longest path view might not give that delay its due consideration (since it didn’t delay the final finish, maybe because of mitigation). Opponents might argue you’re using “Monday morning quarterback” analysis – only looking at outcome, not what risks were faced during the game.
- Requires a solid as-built network: You typically need to construct the as-built schedule with logic links to find the true longest path. If that data is shaky, the identified path might be contested. Some might argue about which activities truly were driving – especially if multiple near-critical paths existed. So while simpler, it still needs good data groundwork.
- Not common as standalone: Longest Path Analysis is often used as part of other analyses (like as a sense-check or supplement). On its own, it’s a bit limited. The SCL Protocol lists it as a recognized method, but it’s generally less used than windows or TIA in formal claims (except perhaps to double-check results). It can be a helpful perspective, but rarely the only analysis done.
Tools: Identifying the longest path is something scheduling software can do once you have the as-built model. In Primavera P6, after inputting all actual dates and logic, one can simply run the schedule and filter the longest path (P6 has a feature for “Longest Path” which traces the driving path to completion). In MS Project, one could achieve similar by setting zero float or just looking at the critical flag if the final date is constrained. Some analysts also do this by inspection of gantt charts and validation with software. The actual delay quantification on that path might involve comparing planned vs actual durations for those tasks (which you could get from a P6 comparison or just manually compute differences). In practice, one might present a table of tasks on the longest path with planned vs actual and reasons for variance. The tool here is mainly for identification; the heavy analysis is figuring out the reason each activity slipped and who was responsible for it.
🔄 Comparative Overview of Delay Analysis Methods
To wrap up, here’s a quick comparison table highlighting key differences between these methods:
📊 Summary: Delay Analysis Methods Comparison
| Method | Type (When) | Data Used | 👍 Strengths | 👎 Drawbacks |
|---|---|---|---|---|
| Impacted As-Planned | Prospective (what-if) | Baseline schedule (plan) |
– Simple, easy to understand – Great for early analysis or small projects – Uses plan everyone agreed on |
– Ignores actual project changes – Struggles with concurrent delays – Depends on a credible baseline |
| Time Impact Analysis (TIA) | Prospective (ongoing) | Current update (rolling) |
– Analyzes delays as they occur (NEC-friendly) – Event-by-event clarity – Resolves EOTs in real time |
– Needs good updated schedules – Laborious if done after the fact – Technical to perform for many events |
| Time Slice Windows | Retrospective (phased) | Schedule updates (windows) |
– Highly detailed and accurate for complex projects – Accounts for changing critical path each period – Thorough cause & effect in each window |
– Time-consuming and data-heavy – Hard to explain without simplification – Requires complete record of updates |
| As-Planned vs As-Built | Retrospective (overall) | Baseline vs Actual |
– Intuitive “big picture” view – Can work even if baseline updates are unreliable – Relies on expert judgment and records |
– Less precise, can oversimplify – Different analysts might differ on conclusions – Doesn’t handle concurrency without extra analysis |
| Longest Path Analysis | Retrospective (hindsight) | As-built schedule |
– Focuses on true driving path at end – Simple concept: “What actually delayed finish” – Useful check on other analyses |
– Ignores shifts in critical path during project – May overlook mitigated delays (hindsight bias) – Requires solid as-built logic to be credible |
| Collapsed As-Built | Retrospective (what-if removal) | As-built schedule |
– Uses real project data (actual delays) – Works even without a good baseline – Clear demonstration of each party’s impact by removal |
– Complex to model for large projects – Can be subjective in how delays are removed – Opponents may challenge the reconstructed model |
(References in the table point to earlier descriptions for consistency.)
🎯 Conclusion
For contract managers under FIDIC or NEC, understanding these delay analysis methods is invaluable.
- 📘 Under FIDIC, you might see any of these methods used – from a global As-Planned vs As-Built in simple claims, to a forensic-level Windows Analysis in formal arbitration.
- 🟢 Under NEC, Time Impact Analysis (TIA) is common for contemporaneous delay assessments, aligned with compensation events and the Accepted Programme.
Each method brings a different philosophy:
- 🔮 Prospective methods look forward – predicting the potential impact of events as they happen.
- 🔙 Retrospective methods look backward – reconstructing what caused the delay after the fact.
✅ The choice of method depends on:
- 📅 The contract requirements
- 📊 Availability of schedule updates
- 🏗️ Project complexity
- ⚖️ Whether delays are concurrent or disputed
🔁 In many cases, a strong analysis uses more than one method to cross-check findings. For example, an expert might perform a Windows Analysis but also reference the Longest Path outcome to validate conclusions.
💡 Remember, no method is perfect. The goal is to choose the approach that fits the situation and available data best – and to present the findings clearly and credibly.
You don’t need to be a planning expert – but with this understanding, you can:
- 👍 Engage confidently in delay discussions
- ❓ Ask smart questions like:
- “Did we update the programme and run a TIA for that big delay?”
- “Is our baseline reliable enough for an Impacted As-Planned?”
- 🧠 Interpret delay claims and consultant reports more effectively
📌 In summary, delay analysis is both an art and a science. With solid data (plans, updates, site records) and the right method, you can untangle the real story of project delays.
And when that story is clear – 📈 managing EOTs fairly, 🧾 reviewing claims, or 💼 defending your position becomes much easier. 🎉🏆
📊 Categorization of Delay Analysis Methods
| Delay Analysis Method | Type | Explanation |
|---|---|---|
| 🔧 Impacted As-Planned | Prospective | Adds delay events into the original baseline schedule to forecast potential impact. Common during early stages of the project. |
| ⏱️ Time Impact Analysis (TIA) | Prospective | Inserts delays into the current updated schedule to forecast finish date changes. NEC promotes this approach. |
| 🪟 Time Slice Windows Analysis | Retrospective | Breaks down project into time periods (windows) and compares each slice’s impact. Done after delays have occurred. |
| ⚖️ As-Planned vs As-Built | Retrospective | Compares what was planned vs what actually happened — typically used after completion. |
| 🏗️ As-Built But-For (Collapsed As-Built) | Retrospective | Starts with actual timeline and removes delays to simulate what would’ve happened but for those delays. |
| 🏁 Longest Path Analysis | Retrospective | Identifies actual as-built critical path and analyzes delays along that path — focused on the final outcome. |
📘 BONUS: Hybrid Possibility
| Method | Hybrid? | When it applies |
|---|---|---|
| Time Impact Analysis (TIA) ⏱️ | ✅ Yes | Can be used prospectively during the project (most common), or retrospectively if done with historical updates — though SCL Protocol prefers it prospectively. |
| Time Slice Windows 🪟 | ✅ Yes (rarely) | Though usually retrospective, it can theoretically be adapted mid-project if you analyze past windows with updates — but not common. |
🧠 Simple Rule of Thumb:
- Prospective = Planning ahead.
🔁 Used during the project → to decide EOT in real-time. - Retrospective = Looking back.
⏪ Used after the project or delay event → to establish liability and actual delay impact.
