Site Weather, Site Evidence: A Contemporaneous Record for UK Programme Delay

UK weather is a familiar explanation for late completion. It is less often a well-evidenced one. A programme can lose a week to rainfall and still struggle to show, months later, which activity was affected, what was recorded at the site, and why the conditions were outside what the parties could reasonably have planned for. The gap is rarely dishonesty. It is usually a record-keeping gap: the site diary notes rain, the programme shows slippage, and no one has joined the two together in a way a commercial reviewer, adjudicator or court could follow.

This article sets out a practical discipline for building a weather file on UK commercial projects. It is not a substitute for the notice and extension-of-time provisions in the contract. Those provisions govern. Nor does it assume that every wet day is an excusable event. The aim is narrower and more useful: to create a contemporaneous record that allows the parties to test a weather-related delay claim on evidence rather than recollection.

Begin with the site, not the regional forecast

A regional forecast is context, not proof. A project in Leeds, Bristol or Aberdeen needs site-level observations: rainfall measured on or near the site, wind speed at the working height where relevant, temperature and ground conditions where they affect trade activity. Where an automatic weather station is installed, record its location, calibration and download routine. Where readings are taken manually, record who took them, when and with what equipment.

The Met Office and local weather stations can corroborate, but they should not be the only source. A weather file that consists solely of printouts from a station ten miles away invites the obvious challenge: was the site experiencing the same conditions? Use regional data as a cross-check, not as the foundation.

Separate ordinary seasonal conditions from exceptional events

Most UK contracts distinguish between weather that is merely adverse and weather that is exceptional. The wording differs: JCT contracts commonly refer to exceptionally adverse weather conditions, while NEC4 compensation events turn on weather conditions at the site being exceptional compared with the weather data stated in the contract data. The common thread is comparison. Exceptional is a relative concept, and it needs a baseline.

That baseline should be agreed or, at least, recorded early. It might be historical rainfall data for the locality, the parties' stated assumptions at tender, or the contract's own weather data. Whatever the source, write it down before the first lost day. A file assembled after the event to demonstrate that a downpour was a one-in-fifty-year occurrence will always look like advocacy. A file that shows the baseline, the live readings and the comparison as they happened looks like evidence.

Link the lost day to the affected activity

A weather file is not a calendar of bad weather. It is a record of consequence. A day of heavy rain may stop external works but leave internal fit-out unaffected. A week of wind may prevent crane lifts while other trades continue. The commercial question is not 'was it wet?' but 'which planned activity could not proceed, for how long, and what did the team do about it?'

For each weather event, record the activity affected, the location on site, the planned versus actual sequence, and the mitigation considered. Where work was re-sequenced, note the instruction and the effect on the programme. Where no mitigation was possible, say why. This is where a weather file becomes a programme record rather than a meteorological curiosity.

Keep the file contemporaneous and controlled

The strongest weather files share one quality: they were made at the time. That means daily entries, not a reconstruction. It means a consistent format, a named owner and a version history. Photographs should be dated and located. Site diaries should cross-refer to the weather log. Programme updates should show the activity affected and the revised dates.

Control matters as well. A file held only on one person's laptop is vulnerable. A file that cannot be produced promptly when a notice is given is weaker than it need be. Keep the weather record with the project records, index it, and make sure the commercial team knows where it is before the first extension-of-time conversation, not after.

A short checklist before any weather-related conversation

Before opening a discussion about weather delay, test the file against these questions:

• Is there a site-level record for each day relied on, with the source and timing of observations?
• Is the baseline for exceptionality recorded, and was it set before the event?
• Does each lost day identify the activity affected, the location and the mitigation considered?
• Do site diaries, photographs and programme updates cross-refer to the same dates and events?
• Is the file complete, indexed and available for inspection?

If any answer is no, the conversation should start with the record, not the claim. That is not a counsel of perfection. It is a practical recognition that weather is a common cause of delay and a common source of dispute. The difference between the two is usually the quality of the file.

Conclusion

Rain is not an argument. A weather file is. On UK projects, the teams that manage weather-related delay best are rarely the ones with the most dramatic stories about the summer or the winter. They are the ones who can show, day by day and activity by activity, what happened at the site and what it cost the programme. Build that file before it is needed. It is easier to keep a record than to reconstruct one.