Every project that runs late produces the same conversation. The job has slipped, everybody can see it, and the sub-contractor is confident that none of it was their fault. So they are owed more time. It feels obvious. It is also, on its own, worth nothing.
Being late and being entitled to time are two different things. Delay is a fact about the programme. An extension of time is a contractual entitlement you have to establish, on specific grounds, in a specific way, within a specific window. The gap between the two is where most time claims quietly die, and they die not because the delay was imaginary but because nobody proved the things that turn a delay into an entitlement.
What an extension of time actually does
Start with what you are asking for, because it is narrower than people think. An extension of time does one job: it moves the completion date, and in doing so it protects you from liquidated damages for the period of the extension. That is it. It does not, by itself, put a penny in your account.
This is the distinction that trips people up. Time and money are two separate questions with two separate routes. The extension of time deals with the date and your exposure to damages. Recovering the cost of being on site longer, the prolongation, is loss and expense, and it has its own requirements and its own hurdles. You can win the time and still recover none of the money if you treat them as one claim. They are not.
Delay to progress is not delay to completion
Here is the point that sinks more claims than any other. The contract does not care that you were delayed. It cares whether the completion date was delayed. Those are not the same thing.
You can be weeks behind on your own package and entitled to nothing, because your work was never the thing driving the end date. Equally, a short delay to a genuinely critical activity can justify a real extension, even if everything else was comfortable. What matters is the critical path: the sequence of activities that actually determines when the project finishes. Delay to something on that path pushes completion. Delay to something with float in hand does not, until the float runs out.
Which is why "we were held up for three weeks" is not a claim. The question is always: held up on what, was that activity critical, and did the hold-up actually move the completion date? If you cannot answer that with a programme rather than a feeling, you do not yet have an extension of time. You have a grievance.
The contract does not care that you were delayed. It cares whether the completion date was delayed. Those are not the same thing.
The three things you actually have to prove
Strip an extension of time claim back and it comes down to three things, all of which have to be present:
- A relevant event. The cause of delay has to be one the contract puts at the other party's risk. Variations, late information, exceptional weather where the form allows it, and so on. Delay caused by your own performance is not a relevant event, however painful it was.
- Causation. That event has to have caused critical delay to completion, not merely disruption or inconvenience. This is the link that is most often asserted and least often proved.
- Compliance. You have to have followed the contract's machinery: notice within the time it sets, in the form it requires, with the particulars it asks for. On many forms this is not a formality. Where notice is a condition precedent, missing it does not weaken the claim, it ends it. That is the whole argument of a separate point we have made before: the notice you did not serve is the claim you will lose.
Miss any one of the three and the other two do not save you. A perfect causation case built on a cause that is not a relevant event goes nowhere. A cast-iron relevant event with no notice, on a condition-precedent clause, goes nowhere. All three, or none.
Concurrent delay, the argument everyone gets wrong
Now the hard one. What happens when two things cause delay at the same time, one of them a relevant event and one of them your own fault? This is concurrent delay, and it is where a great deal of expensive argument lives.
The traditional English position has been reasonably generous to the contractor on the time question: where a relevant event and a contractor risk operate concurrently, the contractor may still be entitled to the extension of time, so it is protected from damages for that period. The money question is treated less generously, because you will struggle to recover loss and expense for a period you would have been on site anyway for your own reasons.
But that is the default, and defaults can be changed by drafting. Well-advised employers and contractors increasingly write clauses that allocate the risk of concurrent delay expressly, often so that the contractor carries it. If your contract says concurrency is your problem, then it is your problem, and the general position will not rescue you. So the honest answer to "how does concurrent delay work" is: read your contract first, because it may well have decided the question before you got there.
When is it assessed, and on what?
There is a real difference between assessing delay as it happens, looking forward from the event, and assessing it afterwards, looking back at what actually occurred. Contract administrators often have to form a prospective view at the time, on the information then available. When a dispute is later determined, the decision-maker can have regard to what really happened. The two exercises can produce different answers, and a claim that was assessed thinly at the time can look very different once the as-built record is laid alongside it.
The practical lesson is not to relax because the assessment was poor first time round. It is to make sure the record exists to support the better answer later.
"We were held up for three weeks" is not a claim. It is a grievance. The programme is what turns one into the other.
The claim is won in the records, not the narrative
Delay claims are won and lost on contemporaneous records, not on the eloquence of the letter written eighteen months later. By the time the argument arrives, memories have faded, the people who were there have moved on, and the only thing that carries any weight is what was written down at the time.
That means a baseline programme that was actually agreed, updated progress records that show where things really stood, and a clear thread from the event to the effect on the critical path. A delay claim assembled from scratch after the event, reverse-engineered to reach the answer you want, is transparent to anyone who has seen a few of them. A claim built from a record kept as the job went along is very hard to argue with, because it is simply what happened.
What good looks like
The businesses that recover their time consistently tend to do the same unglamorous things:
- They agree a baseline programme at the start and keep it, so there is something to measure delay against.
- They notify relevant events promptly and in the contractual form, treating the notice as part of the entitlement rather than as admin to be done later.
- They think in terms of the critical path, not their own inconvenience, and they can show why a delay was critical.
- They keep the time claim and the money claim separate, because they are separate.
- They keep the records as they go, on the quiet assumption that one day someone will test them.
None of this is difficult in the way that building the thing is difficult. It is a matter of discipline applied steadily, while the pressure of actually delivering the project pulls in the other direction.
The time you can actually keep
An extension of time is not a reward for having had a hard project. It is a contractual entitlement that stands or falls on a relevant event, proven causation, and compliance with the machinery. Get those three right, as you go, and the time is yours to keep. Rely on the fact that everyone could see the job was late, and you may find that everyone could see it, and nobody had to pay for it.
This is one of the things Defender Platform is built for. It reads your contract, pins down the notice periods and the form each relevant event has to be notified in, and keeps the programme obligations in front of you while the job is running, which is the only time they can still be met. Software or spreadsheet, the discipline is the same: notify on time, tie the delay to the critical path, keep the record.