In this panel discussion, three construction practitioners explore why site records are vital for any construction project and how the NEC suite of contracts treats them. They begin by affirming that records underpin health‑and‑safety, audit, quality, engineering and commercial assurance. The speakers note that the NEC contracts do not single out "site records" but do reference specific record types – weather measurements (Compensation Event 13), defined‑cost records, and test‑inspection records under Clause 4 and the 40‑series clauses. The conversation shifts to the contract’s emphasis on the "what" (the obligations to keep records) while leaving the "how" to the project scope and the parties’ collaboration. They highlight that the NEC’s programming clauses require detailed programme information, but the contract deliberately avoids prescribing the format or frequency of broader site records, encouraging parties to embed such requirements in the scope. The panel warns against over‑prescribing the "how" because it can stifle innovation, using a chocolate‑cake analogy to illustrate the balance between specifying outcomes and allowing flexibility. Practical advice includes setting clear record‑keeping expectations in the scope, using a pragmatic "bow‑wave" approach to increase granularity as the project progresses, and leveraging NEC guidance notes and industry tools to support consistent, useful record‑keeping.
Chapters
So the kind of what you learn on your first day on any construction project feels like records, records, records. That's the old adage, isn't it? So why are site records important for construction projects and why are they important for NEC?
They're incredibly important for all projects, aren't they? Not just NEC contracts. And I think historically they would be used for health and safety records, for audit trails, for quality quality assurance, engineering assurance. I know we're going to talk today more about sort of commercial assurance use of records, but I know from my time working on site as a project engineer, I would have an A4 desk diary to record exactly what's happened on every shift because that's the way that engineers and QSs have been trained, because those records are so important for all those elements. What should have been your experience? Yeah, same.
I've become quite attached to my carbon triplicate A4 pad. I'm not— yeah, so the same really. And I think I'd agree with you. I don't think there's any specific thing that makes NEC sort of more deserving of good record keeping, but certainly we can explore where NEC perhaps either explicitly requires it or relies upon good robust record keeping.
Absolutely. So what does the contracts— and when we talk about the contract, we mean the NEC contract— what does the NEC contract say specifically about site records?
I don't think it explicitly distinguishes site records from any other record. It does on occasions refer to specific records, for instance weather data and weather records— sorry, weather measurements, and that's in one of the compensation events, number 13 I think, in the core clauses. Then there's more broadly records around defined cost that the Contractor must keep. There's no doubt records relating to test inspection under Clause 4 or the 40 series of clauses. So yeah, there's more generally that obligation to keep records and keep them organized in a useful way perhaps will enable us to walk through the NEC procedures effectively and bring each other along, right? So we're not surprising each other, and hopefully we've got a common set of records that we both recognise as the single truth.
As a stimulus for good project management, which is a lot of what the processes in the contract have been written to provide, in certain areas it's quite prescriptive about what needs to be done. Same in programme, in Section 3, it's quite prescriptive about the level of detail needs to be provided in a programme for acceptance, submitting for acceptance, but there isn't any detail around the collection of wider site records in general? Is there a specific reason for that, or is that an observation that's maybe unfounded?
I'm not sure I totally agree with that. I think you're right. So in the programming clauses, there's under time, there's, you know, a fairly extensive list of bullet points. And the important thing to remember there, of course, is that I think it's the last bullet point says, and anything the scope requires. And we're still talking about what, right? What we must capture or what we must achieve. In that document, in that tool. And I think when we start getting into scope, it's natural for people to start moving into how we do that. So it might be, and we would like it in a certain format or kept in a certain way. And so a massive point actually, make sure you read the scope. I can remember in NEC3 there were 28 touchpoints between the scope and the conditions. I think there's more, more, sort of somewhere in the mid-30s of places in the contract where the conditions talk about the scope and rely on statements in that. So this is a really important area. Make sure you've read the scope, and if you're drafting scope, make sure you're putting those extra requirements in there. But to your point about it being perhaps weaker in other areas, I'm not sure that's true. So although the definition of defined cost is fairly, fairly brief, it does point you to— certainly when you get into the price for work done to date, it points you in the direction of the schedule of cost components, or the short schedule of cost components if you're on one of the priced options. And in there is an extensive list of tests which you have to satisfy. And again, these are what it is rather than how to capture it. But I think that's intentional. I think certainly, you know, pretty much everything I do from a business point of view, I try and think about why, the how, and the what. And if we were to map that to NEC, I suppose you could say the conditions of contract, the clauses of the contract, very much tell you what you must achieve and what's expected. The why is, I think, in the guidance notes. So there's a good philosophy and explanation as to how the drafters are approaching these clauses in a narrative, perhaps in Volume 4. And in Volume 2, there's some good material there to explain how it might be used in use. But really, guidance is about why we're doing something. The contract is setting out the what. The how is kind of left to the user.
To what extent would you think that the is beneficial when that can be set out in, in the scope to a certain degree, so you get some level of consistency. For instance, in getting site records with a certain level of detail, you'd expect to see that in as part of the scope to define what the client wants to receive, I think, from site in those records.
Yeah, sure. I think if there's a range of possibilities and some might be better than others, or an expectation might be clearer in, in some areas, then yes, telling— saying what you want in the scope is, is a good move. Um, I think To explain perhaps why the contract doesn't do that briefly, my understanding would be, well, if that was explicit in the contract, then it would perhaps only be valid for a narrow type of works or services. You'd have to make an assumption about what was appropriate and what was applicable for a given environment or given project. So take an example, you know, the core clause test for market open market rates, competitively tendered prices, tender prices, that would be difficult to prescribe how you achieve that. You know, if you're building an extension on your house, you might be comfortable with a couple of conversations over the phone with different plant material providers. If you were building a multi-million pound infrastructure project, then you would need a fair bit more than that. So I think you're right, that kind of how lives more in the scope and an ongoing conversation between the parties. I mean, the best projects will be run. You know, these sorts of things won't be decided all upfront and they won't happen just in the correspondence required in the contract. They'll happen in a collaborative conversation that seeks to get closer to agreement with a small 'a' on a range of issues and records is one of them.
And that's interesting, isn't it? Because actually agreeing what you provide, when you provide it, and to what detail is probably a good thing to do before you start. If it's especially if it's not actually prescribed in the scope. Yeah. Saying I'm going to give you these records and I'm going to give you them at these timescales every day, every week.
Yeah. And the project manager can always instruct a change to the scope to introduce a new requirement if the parties really can't agree on how to administer things and present things.
Yeah, because it's not something that's set out in, say, contract data, like you're going to get a program at these intervals. I want them at these intervals. It's not like I'm So something to agree on maybe before you start work is—
yeah, well, contractors will set an interval for the minimum interval for program submissions. But yes, um, and of course, you know, we talked about program a fair bit. Um, the other thing that, uh, listening to Glenn Hyde and others, uh, on program, um, you know, it's— you again, it's, it's a pragmatic— even the, the presentation of it's got to be pragmatic to a degree. Um, you won't have full high granularity on absolutely everything on day one. And I've always thought of it as being a bit of a bow wave that moves, you know, a couple of months in front of you where you turn up the resolution and the details. And certainly around early warnings and compensation events perhaps that you're aware of, you might turn up the vigilance on your record keeping so that you've got the tools to do those assessments, you know, and that bow wave perhaps serves that next assessment for the application for payment or the next the next payment assessment.
That makes a lot of sense. In terms of the how, do you think we'll ever get to that point where we're prescribing, or is there a risk to, say, kind of to ruin something quite good if we start to do too much on the how?
I think there's always that risk. I think— I don't think the drafters should do much more. I think the contract should— should probably— it's probably got it about right, although, you know, community feedback's always useful. I think it's over to the rich community of NEC practitioners, the fantastic tools and systems that spring up. You know, we mentioned a few already, and you know, let them help us configure the contracts. And in the same way that we're cautious with clients, we, we, as, as clients, we're told not to over-specify the how, um, because by doing so you start to stifle innovation and shut down opportunities that you might not have unlocked through future collaboration. So be careful of that. Um, in my training, I always used to give the example of, you know, if you want a chocolate cake, you specify a chocolate cake, constrain in terms of I don't want nuts in it, but you wouldn't go so far if Gordon Ramsay was your contractor to tell him what temperature to set the oven. Yes. So no, Leave the how at large a little bit opens up some more possibilities and some opportunities for innovation and collaboration with the supply chain.
