Construction claims: delay analysis (part 1 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 team and always find that our aim to deliver high-quality professional services is met by Planetal. 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 first of three parts where we will work through as-planned programmes and as-built programmes before concluding with critical path 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 as-planned programmes and will look at the level of detail needed, information used to coordinate trades, and how to cope with a change to the plan.

The level of detail needed in an as-planned programme

A programme should be as detailed as possible. This frightens many people because there is a misconception that a high-level programme allows for more flexibility. In reality, what it actually does is hide issues that often do not surface until it is too late. Without adequate detail, problems remain buried and become more difficult to resolve when they eventually arise.

Another major issue is demonstrating change. Without the required level of detail, it becomes difficult to prove changes or manage subcontractors effectively. The programme should serve as a tool to manage the works; that is its purpose. When it lacks detail, managing the project becomes more difficult, the programme becomes inefficient, and ultimately it loses its value. Don’t fall into the trap of thinking high-level programmes give flexibility; they often create more problems than they solve. If you know the detail, include it in the programme.

Tender programmes are often incorporated into contract documents, so it is vital to ensure that they are structured for delivery and for assessing change. Too often, we see high-level sequencing programmes become part of the contract. If you have issued one during the tender stage and are now negotiating the contract, it is always advisable to produce a detailed breakdown of your tender intent. In this way, you capture the agreed timescale along with the detail needed to manage the project and assess changes from the outset. Many projects suffer slippage early on while scrambling to produce detailed programmes after work has started, often as change is already occurring. It is much easier to do the hard work upfront and tackle these challenges from a position of control.

What information is useful to manage coordination between trades

As mentioned, the purpose of a programme is to manage the works. It should be used to forecast dates, be updated regularly, and allow both operational and commercial teams to continuously adjust and coordinate interfaces. On large projects, hundreds of subcontractors can be involved, each delivering its own portion of the scope. These subcontractors often have different critical activities that may not directly correlate with those of other trades. Without careful coordination, these disconnects can quickly lead to delays. That’s why integration at this point is not just helpful; it is imperative to the success of the project.

One of the most effective tools we have implemented to manage this complexity is the use of GIVE/GET milestones. These are used to coordinate and track handovers between trades. A milestone can be framed as one party handing something over (GIVE) and another taking responsibility (GET). This simple but powerful structure clarifies accountability and creates a shared understanding of the interface dates. Monitoring these milestones regularly and actively managing any changes between the parties involved is essential to keeping delivery on track. It also helps avoid misunderstandings and reinforces collaboration between subcontractors who are often working on competing priorities.

How to cope with change to the plan

With the exception of an as-built programme, any programme is ultimately a forecast. It is an estimate of what is expected to happen, and as such, it is subject to change. Programmes rarely unfold exactly as planned because there are simply too many variables and risks, many of which depend on numerous parties acting in full alignment with the plan. Often, the programme reflects an idealistic sequence of events that, in practice, plays out quite differently. That’s why continually adapting to change is critical to successful project delivery.

A common mistake is to keep reporting progress against the original plan on a drop-line programme without updating dates or reflecting changes. This approach causes the programme to drift further away from reality and eventually renders it useless as a delivery tool. The closer a programme remains to the actual site conditions and progress, the more useful it becomes. This means tracking actual outputs closely, inputting forecast and instructed changes promptly, and recording their impact on the remaining works. Ignoring this step not only disconnects the programme from the live project, but it also erodes confidence in the plan.

The as-planned programme should be a live tool for effective project management. At each update, it should reflect the impact of all known changes, giving a clear and realistic view of what lies ahead. This enables the team to respond early to emerging issues and plan future works based on reliable information. Consistently updating and adjusting the programme rather than rigidly reporting to an outdated one supports smoother delivery and improves overall control of the project.

Final reflections

Forecast or as-planned programmes are a project delivery tool. They should sow the required detail to allow the project to be delivered efficiently, including integration between trades. They should also be capable of dealing with change. This means they need to be constantly monitored, adjusted and updated. Depending on the complexity of the project or the scale of the change, it can be necessary on a more regular basis to ensure the programme remains up to date and can be used as an effective tool for the teams to effectively manage the project.

In next week’s article, we will focus on as-built programmes. Look out for that and, in the meantime, enjoy the rest of your week.

Back to articles