Construction claims: delay analysis (part 3 of 3)

We are delighted to be joined by Matthew Klinefelter BSc IEng MICE MCIArb, who is Director – Forensic, Planning & Expert Services at Planetal Limited. We regularly work with Matt and the Planetal Limited team and always find that our aim to deliver high-quality professional services is met by Planetal Limited. We have worked together on some really complex issues and brought entitlement, delay and quantum together to the satisfaction of our respective clients.

This article is the final part of a three-part series focused on delay analysis. These articles are intended to be bite-sized, five-minute reads, so we won’t go into too much detail, but we aim to provide you with some top tips and practical guidance that will help you in your day-to-day role.

This article will cover understanding critical path analysis and the practical realities of critical path logic.

Understanding Critical Path Analysis

Critical path analysis is a widely debated topic and one that cannot be fully explored in a short article. However, I will do my best to cover the core principles that every planner or project team member should understand.

Let us start with the basics. What is a critical path? Most will recognise it as the red sequence of activities on a Gantt chart. These are the tasks that, based on the inputs into the planning software, cannot be delayed without directly affecting the overall completion date. It is important to note that the as-built portion of a programme will not show a critical path. This is because software only calculates and forecasts the critical path based on future dependencies. Therefore, when conducting any delay analysis using an as-built programme, the critical path must be determined manually by the analyst or expert, taking into account actual logic, durations, and sequencing.

Another key point is that it is entirely possible, and in fact very common, to have multiple critical paths within a single programme. Any project that includes sectional completions, for example, will likely have a critical path leading to each completion date. It is essential to differentiate between these when reviewing or analysing the programme. A critical delay to a sectional completion may not necessarily impact the overall project completion but could still breach a contract obligation. In such cases, it is useful to label and track each of these paths separately within the programme or claim narratives, making the logic clear for all involved.

Practical Realities of Critical Path Logic

It is also possible, depending on the nature of the project, for there to be no traditional or logic-driven critical path. This is particularly true in cases where the work is made up of numerous independent, repetitive tasks.

One example from my experience was a contract to replace 300 fire doors. Each door could be installed independently of the others, meaning there was no fixed order of operations. The limiting factor was resource availability rather than logic constraints. In that scenario, the focus of tracking shifted from critical path to volume of work. The contract allowed for a clear duration and a measurable metric, so tracking progress became a matter of counting doors installed. Delays could still be identified, but the mitigation was straightforward. Simply move to another door, assuming access and materials were available.

This highlights a key point. The critical path should always be both credible and practical. Forcing unrelated activities to appear critical by artificially linking them in the software is not genuine planning. It is theoretical manipulation. This kind of approach does not hold up under scrutiny, especially in claims or dispute resolution.

A sound programme must be logically constructed, and any planner should be able to confidently explain the reasoning behind each critical link in the sequence. If you find yourself unable to clearly justify the path you have presented, it is probably time to take another look and carry out a review.

Ultimately, critical path analysis is about understanding what genuinely drives the project. Whether there is one path or several, or even none in the conventional sense, the logic must be transparent and based on how the project is actually delivered. A robust and well-explained critical path is one of the most important tools in ensuring timely and successful delivery.

Final Reflections

Ultimately, critical path analysis is about understanding what genuinely drives the project. Whether there is one path or several, or even none in the conventional sense, the logic must be transparent and based on how the project is actually delivered. A robust and well-explained critical path is one of the most important tools in ensuring timely and successful delivery.

With regards to how the critical path impacts delay analysis, this will be the area of focus, as delays to critical activities will impact completion or contractual obligations. This, however, should not be the sole focus. It is entirely possible and common for the critical path to move during the lifecycle of the project, and a robust analysis should determine when and where the critical path shifts. Understanding changes in criticality is essential and needs to be explainable in order to be credible.

It is not always the case that the critical path on the baseline programme remains the critical path for the entire duration. Therefore, discounting delays simply because they are not on the baseline critical path is not a strong argument. Likewise, claiming delays to a baseline critical activity without showing that it remained critical at the time of the event is also weak.

Critical paths can be simple, or they can be complex. My key takeaways would be:

1. Does it make sense, and is it explainable?
2. Is there a critical path to each sectional completion or contract requirement, and can you differentiate between them easily?
3. If you are analysing delays, have you proven the delay happened to an activity that was critical at the time?

In next week’s article, we will move from delay analysis and will cover quantifying loss and/or expense.

Back to articles