The wrong question, carefully answered
Two weeks are lost. The mechanical contractor was waiting for a slab that came late, and during the same fortnight their own pipe spools had not arrived from a supplier they chose.
That looks exactly like concurrency, so it gets analysed as concurrency: two causes, one delay, and the familiar argument about which one drove it.
The analysis is careful and it is answering a question that neither contract asks. Under the mechanical contract the late slab is not a competing cause — it is an employer risk event, because access was owed and not given. And the pipe spools are a contractor risk event under the same contract. That is not concurrency between two contractors. It is concurrency in the ordinary sense, inside one contract, and it is the only place the question can be asked.
What concurrency needs in order to exist
Claims Week 16 set the ground: the standard forms don't define concurrency, the definition lives in the Particular Conditions when it lives anywhere, and two analysts can reach opposite answers on the same facts.
Underneath all of that is a requirement so obvious it is never stated. Concurrency is a question about one contract. It compares two causes of delay to the same completion date, where the contract allocates one of them to the employer and one to the contractor, and asks what follows when both are running.
Take away the single contract and the comparison has nothing to sit in. Two delays under two contracts aren't competing for anything: each is measured against its own completion date, its own allocation of risk, and its own extension mechanism.
Why the cross-contract case is not it
This is the part worth being precise about, because getting it wrong produces a lot of work that can't be used.
When another contractor delays you, that event reaches your contract through the employer. Access, possession or a preceding-work obligation was owed to you by the employer, and it was not delivered. What the employer's reason was — that a different contractor was late — is not a matter your contract addresses.
So from inside your contract it is a single employer risk event, and it is claimed as one. The other contractor is not a party to that analysis and their delay is not a competing cause. It is the mechanism by which the employer failed to perform.
Which means the concurrency question, if there is one, is between that employer risk event and something you did — your own late spools, your own resourcing. Exactly as it would be on a single-contract job.
Where the real problem moves to
The genuine multi-contract difficulty hasn't disappeared. It has moved to the employer, and under the contracts as let there is no forum for it.
The employer has granted an extension to the mechanical contractor because access was late. They now want to recover that from the civil contractor. As last week set out, that is a separate determination under a separate contract, and it turns on whether the civil contract obliged a handover at all.
If it did, the employer has a recovery. If it didn't, the employer carries both: time given to one party and nothing recoverable from the other. And under the contracts as let there is no forum in which that outcome can be argued, because the employer is not in dispute with themselves. That is a consequence of how the packages were drafted rather than a law of the structure. A forum can be created, by a separate agreement signed across all of the packages, and the week on owning a boundary comes back to what it takes to make one work. What matters here is when: it has to exist before the packages are signed, because nothing in a package contract produces one afterwards.
That is the shape of the problem. Not two contractors arguing about concurrency, but one employer holding a gap that neither package contract creates a route to close, and that nobody thought to close in advance.
Two contracts, two tests
There is a second difficulty and it is quieter.
Packages let at different times, by different teams, under different standard forms won't treat delay identically. One may carry a provision on concurrent delay and another may be silent. One may use a dominant cause approach and another an apportionment. One may define the completion obligation by section and another as a single date.
So the same fortnight can be tested two different ways, and the difference is not analysis — it is drafting that was settled before anybody on site arrived. An approach that produces an extension under one contract can produce nothing under the other, on identical facts, correctly.
Claims Week 15 showed that method choice is the real dispute between two analysts. Here the method is not chosen by the analyst at all. It is chosen by whichever contract the question is being asked under.
What a planner does differently
Before any analysis, one decision: which contract is this question being asked under? Everything else follows from it, including which records are admissible and which test applies.
Then a second: is the other party's delay a competing cause, or is it the reason an employer obligation was not performed? Wherever an access or possession obligation ran through the employer, it is the second, and recognising that turns a difficult concurrency argument into an ordinary extension claim with a straightforward evidential basis.
And where the employer is the one carrying the gap, the useful contribution is not an analysis. It is showing where the recovery route is missing, early enough that the next package contract is drafted with a handover obligation in it.
System design
The first row does the work and it is one extra column on a register that already exists.
| Record | Produced by | Required quality | Verified against | Feeds |
|---|---|---|---|---|
| Cause register | Project controls | Coded by contract and risk owner, not only by date | The contract’s risk allocation | Which claim is being run |
| Delay test per package | Contracts | The concurrency and EOT wording, quoted per contract | Each package contract | Which method applies |
| Employer risk events | Project controls | Access and possession failures, whatever caused them | The access obligation | Extension claim |
| Missing recovery route | Project controls | Named where an obligation to hand over doesn't exist | The upstream contract | Drafting of the next package |
Coding a cause by contract and risk owner rather than by date is what separates an access claim from a concurrency argument, and it has to happen when the event is recorded. Doing it afterwards means going back through a year of entries with a question nobody was asking at the time.
Practical insight
Take a delay on your project that you have been treating as concurrent, and separate the causes by contract rather than by date.
Write each cause down with one label: is this something my own contract makes my risk, something it makes the employer's risk, or something that happened under a contract I am not party to? The third category is the one that gets miscoded, and it belongs in the second.
If everything in your analysis falls into the third category, you don't have a concurrency question at all. You have an access claim, and it is a considerably easier one to run.
Key takeaways
- Concurrency compares two causes under one contract, where the contract allocates one to each party.
- Two delays under two contracts compete for nothing. Each is measured against its own completion date and its own mechanism.
- Another contractor's delay reaches you through the employer as a failure to give access or possession.
- From inside your contract that is a single employer risk event, not a competing cause.
- The real difficulty moves to the employer, who may hold time given and nothing recoverable.
- Under the contracts as let there is no forum for that. One can be created, but only before the packages are signed.
- Packages under different forms can test the same fortnight differently, and the method is chosen by the contract rather than the analyst.
- Separate causes by contract before by date. Miscoding the third category is what turns an access claim into a concurrency argument.
Records born here. The cause register coded by contract rather than by date · the delay test that applies under each package · the note of where a recovery route is missing.
What is coming next
So far the contractor on each package has been one company. Sometimes it is two or three, sharing a name on the contract and nothing else.
Next week: joint ventures and consortia — one face to the employer, several sets of books behind it.
Enjoyed this lesson?
Join with Google to get each new lesson the moment it's published — and help me see which topics matter most to you. No spam, one email a week, unsubscribe anytime.
Already following on LinkedIn works too — this is just for the weekly email.