Building the Evidence File Behind a Delay Claim

A delay claim succeeds on contemporaneous records, not on argument. The sequence for assembling the file while the delay is happening rather than a year later.

A delay claim is an evidential exercise. The entitlement comes from the contract, but whether anyone accepts it depends on records made at the time by people with no idea they would matter. The sequence below builds that file as the project runs, which is the only point at which it can honestly be built.

Before stage one

You are ready when three things exist: an accepted baseline programme, a record keeping routine that runs whether or not anything has gone wrong, and one person who owns the claim file. Without an accepted baseline there is nothing to measure delay against. Without a routine, records appear only after the argument starts, and records created after the event carry far less weight. Notice and record requirements differ between contract forms and are revised over time, so read your own clauses before relying on any general practice.

• Confirm the baseline programme has been formally accepted, with the acceptance recorded in writing.
• Fix the frequency and format of the site diary, labour returns and plant returns, and name who completes each.
• Set up a single indexed location for correspondence, instructions, minutes, programmes and photographs.
• Extract the notice requirements from the contract into a one page procedure with time limits.
• Name the person who owns the claim file and give them access to every source document.

Stage 1: Fix and protect the baseline

A claim measures delay against an accepted plan, so the baseline programme must be a real document: logically linked, resourced, free of artificial constraints and formally accepted. Keep the native programme file, not only a printed bar chart, because the logic is the part that matters. If the baseline is later revised, keep every superseded version with its date, since a claim often has to show what the plan was at a particular moment rather than what it became.

• Deliverable: An accepted baseline programme in its native format, with a written acceptance and an archive of superseded versions.
• Owner: The planner, with the contract administrator recording the acceptance.
• Approval gate: The baseline is accepted in writing and archived before the first progress update.

Stage 2: Run the routine records whether or not anything is wrong

Site diaries, labour allocation sheets, plant returns, weather records, delivery logs and daily photographs are worth very little individually and a great deal as a continuous series. The value comes from the fact that they were kept consistently before anyone had a reason to shape them. A diary that starts the week a delay event occurs looks exactly like what it is. Keep entries factual: what happened, where, who was present, what was obstructed.

• Deliverable: A continuous, dated record series from mobilisation to completion, stored centrally.
• Owner: The site agent, with weekly spot checks by the commercial manager.
• Approval gate: A random week from six months ago can be reconstructed from the records alone.

Stage 3: Identify the event and give notice in time

The moment something occurs that could delay completion, the clock on the notice provisions starts. Notice requirements are strict in many forms, and a late notice can reduce or defeat an otherwise sound entitlement. Give notice on the facts you have, stating the event, the date, the works affected and that further particulars will follow. Do not wait until you can quantify the delay, because quantification is almost always a later exercise than notification.

• Deliverable: A notice issued within the contractual period, referencing the clause and describing the event factually.
• Owner: The party claiming, through its contract administrator.
• Approval gate: The notice date is inside the contractual limit and the clause reference is correct.

Stage 4: Isolate the effect on the programme

Take the programme as it stood immediately before the event, insert the event as it actually occurred, and observe what moves. The question is not whether the event was disruptive but whether it delayed an activity on the critical path and therefore delayed completion. Where the affected activity had float, say so and explain what happened to that float. A claim that asserts a completion delay without showing the critical path mechanism is the kind that gets rejected without being read properly.

• Deliverable: A programme impact analysis showing the critical path before and after the event, with the method stated.
• Owner: The planner or a delay analyst.
• Approval gate: The analysis identifies the critical path and explains the float position.

Stage 5: Link cause to effect with specific documents

For each link in the chain, attach the document that proves it. The instruction that changed the work, the request for information and the date of the answer, the diary entry showing the trade standing idle, the labour return showing the reduced output, the minute recording the discussion. A claim is a chain of links, and the whole claim is worth no more than its weakest one. Cross reference every assertion to a document reference rather than to a narrative paragraph.

• Deliverable: A cause and effect schedule with a document reference against every link.
• Owner: The claim file owner.
• Approval gate: Every assertion in the narrative points to a document in the file.

Stage 6: Separate time from money and quantify each properly

Time entitlement and cost entitlement are different questions with different tests, and merging them weakens both. Establish the extension of time first, then quantify the cost consequences for the period established. Prolongation cost is the time related cost of being on site longer; disruption cost is the cost of reduced productivity and is proved differently. Keep the two in separate sections with separate evidence.

• Deliverable: A time submission and a cost submission, cross referenced but independently supported.
• Owner: The planner for time, the quantity surveyor for cost.
• Approval gate: The cost period matches the time period established, with no overlap or double counting.

Stage 7: Submit particulars and keep the submission alive

Submit the detailed particulars within the period the contract allows, then keep updating as the event continues. Many forms require interim particulars at intervals for a continuing event, and a single submission at the end of a six month delay can be non compliant even where the delay itself is clearly established. Respond to every request for further information in writing, and record what was supplied and when.

• Deliverable: A dated particulars submission with a log of updates and responses.
• Owner: The claim file owner.
• Approval gate: No request for information is outstanding for longer than the period the contract allows.

Stage 8: Press for a determination and record the outcome

An unanswered claim is not a resolved claim, and in many forms the absence of a determination has consequences for both parties. Ask for the assessment in writing, and if it is given in part, record which elements were accepted and which were rejected with reasons. The accepted elements should be reflected in the programme and the valuation immediately, so that the remaining dispute is as small as possible. Where the determination is contested, take advice from a licensed legal adviser before escalating under the contract dispute procedure.

• Deliverable: A written determination, with the accepted elements reflected in the programme and the account.
• Owner: The contract administrator, with the project lead.
• Approval gate: The open items list is shorter after the determination than before it.

Handovers between stages

The handover that destroys claim files is from the site to the office. Diaries and allocation sheets live in a site cabin, and when the project ends the cabin is cleared. Scan or upload the records weekly into the central file so that nothing depends on a physical location or a departing individual. The second handover is between the planner and the quantity surveyor: if the cost submission is built on a period the programme analysis does not support, the whole claim becomes vulnerable, so the two should agree the period in writing before either writes anything.

How you know it is finished

The file is complete when a person who was never on the project can read it and follow the chain from the event to the instruction to the record to the programme effect to the cost, without asking a question. That is also the test any assessor, expert or tribunal will apply. If you can only explain the claim by talking, the file is not finished, and the explanation will not be available when the matter is decided.

Domira builds and supervises projects across Saudi Arabia, and the commercial discipline above is how its projects stay inside their budget and their programme. Send the drawings, the contract or the site and Domira will tell you where the risk actually sits.