In this panel discussion, three NEC practitioners explore why site records are essential on construction projects and how the NEC contract addresses them. They note that while records underpin health‑and‑safety, quality, and commercial assurance, the NEC does not single out "site records" but references specific data such as weather measurements (Compensation Event 13), defined‑cost records, and test/inspection documentation (Clause 4 and the 40‑series). The speakers argue that the contract’s primary function is to prescribe what must be recorded, leaving the how to the parties and to the project scope. Consequently, the scope becomes the key vehicle for detailing record‑keeping expectations, format, and frequency. They discuss the interplay between the scope and the contract, citing the many touch‑points (≈30‑plus) where conditions reference the scope. Practical advice is offered on setting reasonable record‑keeping cadences, especially for programme submissions, using a “bow‑wave” approach that increases granularity as the project progresses and as early warnings or compensation events arise. Finally, they caution against over‑prescribing the method of record capture, warning that excessive detail can stifle innovation and limit collaborative solutions, likening it to dictating a chef’s oven temperature for a chocolate cake.
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 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 programme submissions. But yes, um, and of course, you know, we talked about programme a fair bit. Um, the other thing that, uh, listening to Glenn Hyde and others, uh, on programme, 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. Um, 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, uh, tools and systems that spring up. Um, 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.
