00:00 - Introduction
Glenn Hide: Good afternoon, everyone, and welcome to this afternoon's webinar. This is edition number 13. Hopefully, we'll get it on the screen shortly. The webinar itself seems to have disappeared. So, welcome. This is our next webinar in the in the series, and we're gonna try and explain scope, but in a way that's slightly I'd like a bit radical. We'll see how this session goes down with you when we are using scope as to how to cook a roast dinner. You must have been intrigued, if nothing else. So this is the 13th episode in our series. Can't believe how many we've done already, and we've got one coming up, we'll tell you at the end of December. So we've got one more before the year's out. So very warm welcome from myself, David Allen and Ben, who will introduce themselves shortly. Uh so David, I'll just pass over to you on behalf of CECA.
David Allen: Hi there, thank you for that, Glenn. Yeah, I'm David Allen. I'm the Executive Director for CECA Southern, which is just one part of the Civil Engineering Contractors Association, more commonly known as CECA. We are a member-led organization who represent and promote companies who work day-to-day to deliver, upgrade, and maintain the country's critical infrastructure, creating a window between our members and those that influence our industry. We deliver against our strategic core pillars that you can see on the screen right now, which include ones aligned to supporting skills and training. And this NEC4 webinar is just one aspect of that. You'll be able to learn more about our other wider skills and training initiatives and other core pillar activities on our website. However, back to today's topic, Scope Explained, where Glenn and Ben will lead us through a relatively straightforward explanation of how things should work. Whilst they have chosen an interesting project, as Glenn's already spoken about, I'm sure that they will deliver this in a clear and concise way.
However, our member feedback on scope suggests that this is not always felt to be the case. The suggestion being that sometimes the drafting of scope has simply been pulled together and cross-referenced, with cut and paste inclusions from previous projects, and is not project-specific. This can lead to ambiguity and potential conflict, obviously not ideal. In an industry where all parties face time and resource challenge, the development and drafting of the scope goes a long way in defining the contractor's perception of the obligations on them and the associated project risk. The use of early contractor engagement with an in with an appropriate focus on the terminology used, delivered in a clear and concise way will ensure that the actual client needs and obligations under the contract are both understood and suitably considered and will help unlock better outcomes for all. So I'll now hand you over to Ben, who can explain a bit more.
03:38 - A Sunday roast as a model Scope
Ben Walker: Thank you, David. Good afternoon, everyone. So, scope, the origins of the word scope from the mid-1500s Italian scopo, meaning an aim, a purpose, or a target. And today, our aim is to walk ourselves through the writing of a scope for a perfect Sunday roast. The idea being that we have lots of different sectors in our industry, and you know, from nuclear to rail to water to airports to all sorts of different things. And so to save our minds from having to dart around for specific knowledge and appreciation of different technologies, we thought we would simplify things. And in no way this is intended to dumb down the topic or patronize anybody. So please take it in the spirit intended. But everyone knows what a good Yorkshire pudding looks like. And so our attention can be entirely on learning the structure of the scope, how the different parts of it interact with each other, what each part is for, and how it works with the conditions of contract, the pricing documents, and also the contract data and site information. So we hope we find the following informative, a bit fun, and therefore memorable. And so without further ado, we pass you to Glenn for a little bit on how the scope sits among the other contract documents.
04:59 - Where the Scope sits among the contract documents
Glenn Hide: Okay, exactly. So in the middle there, we've got the we've got the scope. So what is required and the limits on how. So in the scope, we've got two courses for six people. We've got the requirement for the beef to be at 52 to 55 degrees centigrade after resting. We've got 12 Yorkshire puddings that need to be greater than or equal to 60 millimetres at all, no gravy granules, no nuts. The dog has to be kept out of the kitchen and the oven free by the key date. So we've got someone else who needs the oven there. So written by the client and by the contractor for their elements of the design. Where does that scope sit in relation to anything else? Well, the contract data will say who's doing it, when, and how much the pricing document. So we've got what are the prices, if they're applicable, because it was a cost reimbursable, there wouldn't be prices there. How much does each item map and relate to the scope, the conditions of contract?
The actual rules are we're going to be following. And also we've got the programme here, how the contractors are planning to do things. Obviously, the beef takes a bit of time compared to, for example, the vegetables might be considerably quicker. And then also don't forget site information and site information, what's already there? So if this is whose kitchen are we using and what other facilities are already there, that would describe the existing site information. So as Ben said, this is kind of we're not it's a kind of lighthearted look, but with a very serious message because all we're looking to do is relate this to something we can all relate to, and then we can apply the rules of putting this scope together for a water treatment works or a road, whatever it may be, but we can relate it back to okay, in this case, how we're doing a roast dinner. I remember when I was doing programming exercise, it was about making a cup of tea.
And you just talk about, well, hang on, until you've boiled the water, well, you can't pour it. And so hang on, have you filled the kettle? Oh, hang on, we haven't filled the kettle yet. That takes time as well. So we can do some very simple things to learn the rules and then be able to apply them in our construction environments. So I think that's the plan, isn't it, Ben?
Ben Walker: Yeah, I've forgotten that. One I too had to do that, make a cup of tea. Go ahead, David.
David Allen: I think you've introduced an ambiguity already because you define the Yorkshire puddings being equal to or greater than 60 millimetres, and you spoke about height. What about the diameter?
Ben Walker: Well, you're right, actually, that perhaps should have been set because that's I think that's an ambiguity, isn't it? So we do a clause 17.1 notification for that. And I think you're right there, David. I can't argue that. Although one would think that if the client supplied the pudding tins, then that might be set. So we might be all right. Um Glenn, any reason why we shouldn't get a programme in contract data part two? Because I certainly can't think of one.
Glenn Hide: No, we've we've discussed this, we've had this on a CECA bulletin always recommending that you always have a programme. It it kind of sets out that you can produce a programme in decent software, you've understood the requirements. You also, in an NEC world, hit the ground running because that in effect becomes the first accepted programme. So I haven't got a good reason why not.
Ben Walker: And it's useful to think of the programme alongside the scope because the scope is what I want as a client, and the programme is how the contractor is going to provide it, except for the ways I say they can't. So the two things we'll see in a second are gonna interface quite a lot. Now, in terms of the structure of this, uh, this is not the full structure suggested by NEC4's user guides. We're not going to attempt to go into every subsection of detail. It's quite a big document, the the full guidance on this. And so some entries are specific to secondary options as well. So we haven't gone into those. We couldn't think of any sensible secondary options for a roast dinner, apart from X5. So everyone is encouraged to refer to the user guide, uh, the NEC4 user guide, volume two, preparing, in this case, an engineering construction contract. There is one of these chapter threes for each of the main forms and short forms as well.
So absolutely well worth doing. A lot of what we're going to learn here obviously is transferable to the subcontracts as well. So there's a there's a chapter on how to tweak things for the subcontracts in the same guidance. So definitely refer to that guidance. This webinar obviously is not replacing that guidance, so you really worthwhile going and having a look at that. But maybe this whets your appetite to go and go and look further. And if you're still operating on NEC3, why? But if you are, then there is a how to write works information guide, which is also available through neccontracts.com and may well be part of your digital license if you if you have one of those. So once you've mapped and understood how this fits together, it'll serve you well. NEC is very consistent no matter what form you're looking at. So whilst we're doing something a bit silly today, you in your real projects, you should be able to map the same principles across. So, Glenn, the one place perhaps where we might enable ourselves to be a little a little subjective.
Glenn Hide: Yeah, absolutely. And just going back to the numbering, obviously, yeah, and numbering is unique today. But what I think is encouraging is that a lot of people are using clearly the index that the NEC has set, because a lot of people talk about, oh yeah, S500 for programme or S700 for whatever it may be. So that's the other thing because the NEC is kind of set a sort of standard, if you like, not compulsory, but most people, most a lot, let's say, do follow that. So then we get a bit of consistency across projects, across even sectors where everyone kind of knows that, yeah, oh S500, yeah, we know what that is, or in NEC3 it was WI500 for that guide. So our numbering is quite unique today, but in the industry, the numbering is quite consistent because most people will take that
10:48 - Objectives versus measurable requirements
Glenn Hide: Same numbering. So, yeah, this is the one place, the description of the works where we can, as Ben said, be a little bit more aspirational. So the client's objectives might be that the client is being visited by their in laws for a few hours and wants to impress them with a beautiful traditional Sunday roast. They want the in laws to leave feeling full, happy, and satisfied. So that is not too measurable, though. So that could be subjective, so very difficult. A requirement we've got there is the beef core temperature, which needs to be 52 to 55 degrees at the thickest part of the resting before carving. So that is a measurable test between the two there. So why state subjectives at all? Well, they give the contractor a bit of context, especially where it requires the gratin should serve the objective. They help everyone read the rest of the scope in the way it was intended. So they've kind of got that in the back of their mind, everything else they're reading with that.
A bit of a drafting tip, keep objectives short, clearly label as objectives, and make sure every requirement that matters is stated measurably further down the list there. So we're setting the scene here with the description of the works.
Ben Walker: Yeah. But I guess if this was a business plan, this is your north star, isn't it? It's the bit that helps you if certain things don't work and pan out to be impossible or fall short, then if you've both got that north star, then it makes the changes that are necessary, the early morning meetings or whatever else, a little bit easier because you've all got the same context as to what the ultimately you're trying to achieve. This slide's quite a quick one. Essentially, you want to fairly briefly at the top say what's in, of what's in what's to be designed by the contractor, and by difference what's out. And when I was putting this together, it occurred to me there are two kinds of out, really. There's on the right hand side there, there's not what's not in the works. So putting the sibling of the client is gonna serve, is gonna create, what's the word, provide or make the apple pie. So they would be an other with a capital O.
They're gonna bake it and serve it in the same kitchen. And then we've got washing up, which nobody under this contract is to do. Obviously, others aren't under this contract as well, but those kinds of things, if it's vague as to whether they may or may not form part of the works, it's better to perhaps exclude them in an explicit way so that no one's confused. And yeah, whereas the others bit that's not in this contract, but it might be the broader project, as indeed it is here. And that's useful because that we might need to make a link over to section nine later for the for the work of others. Equally, you can see on the vegetable gratin bit, this is identified very early on as being contracted design. So that will have a link to section three. So yeah, section three, section nine, things are starting to already interrelate a little bit. And then we're on to the sort of main event, really, Glenn, drawings and specification.
13:52 - Performance or prescriptive specification
Glenn Hide: Yeah, so it's getting into the detail, so where we can actually be a bit more specific. So it would be an opinion, wouldn't it, if it was nice and pink? What does that mean? Where a requirement, more specifically, is that 52 to 55 degrees at the core after resting. That's quite nice and precise there. The gravy, we want it smooth. Well, smooth. A different person smooth would mean different things to different people. So a more specific requirement, as all of it passes through a fine sieve. Maybe we need to be more specific than fine, uh, but nothing left, nothing left in it. Again, the puddings, uh, well written. Well, we want at least 60 millimeter high, hollow centre, no raw batter. And again, the plates nice and warm, a requirement to have 45 to 60 degrees at the centre when put on the table. Personally, it's a pet hate of mine having them too hot. Yes, cold and it makes the dinner goes, but then when you pick it up and it's too hot, that's that's a problem in itself.
So, in terms of the outcome, we've got performance related and prescriptive related. So the beef at 52 to 55 degrees after resting, and how to get there is up to the contractor to make sure it's there. A prescriptive one will be stated in the recipe. So we've got four eggs, a specific amount of flour, milk, and how much fat goes in as well, prescribe the recipe and the outcome, and then any gap is the is the client. So if the recipe is followed and the puddings don't reach the 60 millimeter high, then the gap sits in the client's document. That's the consequence of prescribing, because they've been specific on how to achieve it. And if it doesn't reach, well, as long as the chef does follow the prescriptive method, well, that would now be the client's problem because, well, we did what we told you, and it's not achieved the required outcome. So consider using performance specification by default, perhaps only describe where you have a reason, things like nuclear safety, rail possessions, regulations back in our obviously our real construction world.
Ben Walker: Yeah, absolutely. I wonder how many people actually think that through as being a risk allocation, because it can be quite an unconscious risk allocation. This we might spend loads of time and money debating every Z clause and you know, compensation event and you know, liabilities in and out, and maybe not look at all at whether or not we've used performance specifications or descriptive details. So, you know, you can do a lot of risk allocation in making a haphazard choice of that, uh, whilst also perhaps unnecessary restricting the contractor's freedoms and innovation, stifling innovation. So, yeah, we've got to be very I think it's healthy to always have a reason if you're going to put more in rather than draw on the contractor's expertise. Good stuff. I think I think the other thing that we're really saying then, Glenn, is that as you're doing your drawings and specification and you're writing detailed specification for anything that you want built, you've also got one eye on section 700.
It reminds me a bit of software, actually. When when we're designing a new bit of software, we would write the test plans alongside it so that we can objectively test each thing. And like we said at the very start, probably the only thing you wouldn't objectively test is that everybody leaves full, happy, and content with a meal because that might be a little bit difficult to do. But certainly, I'd be almost as a little audit of the document as we're drafting it, which bits have I not got an objective test for? Where have I slipped into subjective language like well-risen or you know, nice and warm? Good stuff. If you look at the chapter three, there's actually some drafting advice which talks about the use of adjectives and adverbs. And you know, it's the same advice that the drafters of NEC actually get to draft the clauses and amendments. And it's it's an interesting little document to read. So do have a little look at that.
17:40 - Constraints and controlling the method
Ben Walker: And and kind of sometimes it's a bit difficult to know whether or not a constraint for something, particularly if it's a prescriptive method, lives in section 100 or section 200. But let's have a quick look at constraints under section 200. So they don't typically describe the work, but they limit how the contractor provides them. So maybe if the contractor was doing it in their own kitchen, you might say, Yeah, you can cook me a cake, but I don't want you to use a gas-fired oven because I'm I've got green credentials and I'm not going to specify an electric oven. I'm just saying you can't use a natural gas oven. So it's about constraining. And there's a there's a few different items you can constrain. If you look at the user guide for this under chapter three of volume two, there's quite a few different subsections to this. We've just chosen a few of them here, so we can see our works example extends to general security, protection, tidiness, waste.
But do have a look at that full guide for all the different suggested subsections. Now, the dog, the pudding thief, and guarding the beef are kind of silly examples, but each is a real site constraint, an exclusion zone, somewhere to store or not store materials or staging areas, access and egress. Quite often you might see a link here to a general arrangement of the of the site, maybe a general arrangement of site information so that you can see and visualize where these conditions take effect. Also, you've got again constraints kind of in line with what we were saying before around performance or prescriptive. We've got kind of prohibitions or prohibitive sort of methods or prescriptive methods. So don't set off a smoke alarm is one kind of constraint, but boil, steam, dry, roughened, then roast your potatoes might be another. And you can see how one is like prohibitive, but the other is a bit more of a constraint as to the how, and it's more prescriptive.
No, it doesn't matter which you use, they both take one freedom away from the contractor. So again, and Glenn will cover this on the next slide, but really do think about why am I writing this? You know, is it necessary? Why is there a particular reason and some of those typical reasons, as I say, Glenn will look at in the next slide. So each constraint may cost money or narrow options. So the contractor will be considering it when pricing and planning the works. Add or change one of these constraints after the contract date, and that will be a change to the Scope. So it's good that it's possible as the project manager's core, one of the core powers under clause 14.3 to instruct to change the scope, uh, which would of course be a compensation event, but at least you can. So just pausing there for a second, let's be mindful of our option Z clauses, which say things like the contractor shall not make noise after before 9 a.m.
on a Sunday, or shan't access the site through this gate with this size truck, or shan't come through this village. These are all constraints that you may well actually want to write in your scope rather than having them in Z clauses for the very reason that if you want to relax them or change them, you'd be able to. Again, some industries, some sectors consider perhaps some constraints to be so important that they perhaps don't want the project manager to be able to change them, and which is the very reason they do put them in as option Z. But you know, something to think about. Don't sleepwalk into putting them into option Z. Scope is much more than drawings and specifications, it's also constraints. And we're gonna find out in a minute, it's about 24 or 25 other things as well. So we're gonna have a look at those. So the other thing is test for every constraint. So this really takes us on to the next slide.
Can the client say why it's there? If you can't say why it's there, it might simply be taking away from the contractor's freedom, stifling their innovation, and ultimately perhaps costing you a bit more money. So let's think as a default, perhaps what we want to achieve and maybe leave some of the methodology where we can.
Glenn Hide: Yeah, so it's thinking about what the what the client feels they need to control. So method typically is the contractors by default, and so observed as part of the programme. programme will be showing how they're planning to do things. But at the end of the day, as long as the objectives are met, then the client may be not too worried about how they achieve it. If the if the beef is perfect, tastes good and meets their requirements, then how it's cooked in some ways is up to is up to the contractor in that regard. So the question the client needs to ask themselves do they have a reason to control the method? If the answer is no, then they're going to observe it through the contractors programme. The method and the risk stay with the contractor because if they don't achieve it, well then that will be a defect under the under the contract. So that risk will sit with the contractor and for the roast, it's the cook's running order in that regard.
If there is a reason the client wants to control the method, well then we can do it through the scope. And then we've got procedural where we've got method statements, acceptance, hold point, a duty to follow them. And that content stays for the contractors. So carving method accepted before carving there might be an illustration there. Substantive is the method itself sequence a prohib prohibition there, a technique, the client is taking back the risk. So roast, boil, steam dry, roughen, then roast the potatoes. So they specifically said how that needs to happen. If the Contractor followed those methods and it doesn't work out, well then that will be the client is taking back the risk there. The contract did everything that was told of them and the results are not what the client wanted but if the contract has followed them then that would be the client's problem there. So reasons why the client might state they might typically require a certain state so a regulatory duty so a nuclear site license a safety case the methods it must be available to evidence.
Its own operations that they got privately as rail possessions or live water assets or third party constraints there. So you know really for the client do consider observing through the programme by default and control only when there is an absolute necessity to do so because otherwise the client is then taking back some of that risk.
Ben Walker: Yeah and as we said before that sometimes some of those constraints aren't even put in a scope they might actually put Z clauses so that there could be a couple of places where in theory the contractor is limited. And of course this chapter again sometimes I'm I have to stop and think where best to put stuff because there's actually a health and safety section as well proposed by the guidance there on on what where you put some of these things.
24:35 - Contractor's design and acceptance
Ben Walker: Okay good stuff so Contractor's design so this is a section in itself and now we've already introduced right at the start that these bits included in the works of those the Contractor is to design certain elements the client has designed the whole meal except the gratin and of course the pudding is being provided by siblings so they're another the beef is the client's scope it talks about sorry the brief is the client's scope so we still we still give some scope for the gratin and the client scope here is specifying the maximum dish, a minimum cooked weight and that at least two vegetables must be used, no potatoes, a double cream sauce and no nuts. So the outcomes and limits it does not have a recipe and that's the same principle as the method on the last slide state what you need or what you want limit only where you have a necessary reason. So then the contractor designs that and submits the particulars for acceptance with its first programme perhaps and we can see the different particulars there that we're expecting so we want which is which ties back in with clause 21 which sets which makes that point that the particulars of the design what's to be submitted in what format that's ought to be stated in the scope.
So it would be easy wouldn't it to miss that and then have to go back and put those requirements into the scope and that would be a change to scope. So there's a good chance that the contractor might consider well actually coming and saying now that you want me to specify some of this stuff as part of my design submission is more onerous whatever. So it could it could result in a compensation event. Once accepted those particulars are sort of scoped from the contractor to authors you've now got kind of information provided by the contractor for their scope and and obviously the client scope now acceptance doesn't make the design the client's so clause 14.1 is relevant here one of the reasons that in one of our previous webinars on communicating correctly we were saying you know let's not interchange these verbs by accident we don't want to approve designs or agree them the verb in NEC is to accept them and acceptance carries that car value in clause 14.1 contractor remains responsible for it albeit clause X15 is probably also taken to limit the contractors liability to reasonable skill and care for their design.
If the contractor then wants to change their own design maybe they can't get hold of celeriac and they want to substitute it for I don't know leaks or something then they can they can sort of propose that it's changed and that actually is caught by one of the exceptions under clause 60.1(1) and therefore would generally not be a compensation event. But if the client on the other hand suddenly decides that they want the contractor to make a slightly bigger one then of course that is changing the client's scope for this particular dish and that would that would of course be a compensation event. So yeah it may also be that the other parts of X sorry the other parts of clause 21.2 are relevant here let's say that the contractor complied perfectly with this with what the scope stated they proposed two vegetables one was a bit off the wall unless I don't know maybe beetroot or something and the client said oh I might have a beetroot in my gratin so I can't believe I'm saying he swears anyway I'll carry on though I started so if the if they don't want beetroot in their gratin well that's withholding acceptance to design for a reason not in the contract clause 13.8 says they can do that but it'll be a compensation event under 60.1(9) so you know there's common sense prevails clients got the money they're holding a dinner party they can have what they want but there are these consequences and rather common sense it sort of picks up in there in the in a different compensation events.
Now also very important is that you state how the design may be used in the scope and here the client said that the client may use and copy the design for meals it creates in its own house but not sell the design or cook from it for sale. So that maybe the Contractor's price may have been a bit more expensive if the client had said that they want to use this for commercial purposes outside of this particular meal. So you know useful points of clarity there as well and the scope as you can see covers quite a lot of areas and we're going to cover quite a few more of them now.
29:04 - Defining Completion without subjectivity
Ben Walker: What about completion Glenn this is an important one to get objectified isn't it
Glenn Hide: Yeah absolutely so completion what does good look like and what what would actually determine that we are we are done we are finished here. Obviously completion in our NEC contracts most people will know the definition is defined within the contract and it's basically doing that all the works that the scope requires and it's free of defects that would prevent the client from actually using the work so scope says what done what done looks like and here for each section we've got it split so we've got the starter the two sections and the main course each with its own completion date held in the contract data not in the scope to remember dates for the project are in contract data the work that needs to be done that is we're going to find within the scope for each the scope is exactly what must be in place for these two elements notice the scope has the scope has no dates in it at all they will only be in contract data put them in both places and sooner or later they will start to disagree and then you've got a problem with ambiguities and such like so we want to keep the dates in contract data rather than in the scope.
The pudding isn't either section it belongs to others being another party if the scope doesn't say what done looks like nobody could say when it's done so very important so that everyone's under no illusions as to what does completion mean? You know if what does it look like in order for us to be happy that yes we have achieved these objectives we've got sorry that listed out there we've got everything there for the starter and the main course all listed in terms of what we want done.
Ben Walker: Yeah quite different from other forms of contract that might give more of a subjective test like practical completion or substantial completion which can be quite subjective kind of glad I think yeah and you know this is important right because if you didn't follow the how to write scope guide it might not be immediately obvious that the scope should contain the statement about what completion is and actually you know it's not too late. It's brilliant if you've already got that pre-contract but because the project manager can change a scope it's not too late to do a little audit best time to do this pre-contract second best time to do it is today. So do a little audit of your scope see if you can find the definition of completion. Now there is a backup there is a kind of like a default interpretation of it but again it's a little bit subjective what we'd rather I think do is have an objective statement scope. So if it's do all of the work that's required on the highway to get the cars running on it except for I don't know the soft landscape into the verge on the roundabout or whatever it might be then it's clear and objective and it means then that the completion certificate is not held up that means takeover happens which means you can start to off risk certain things.
If you've got a wishy-washy completion definition those things can't happen succinctly you may also miss time when to do your defect corrections which under option C, D, E, or F may well become disallowed costs because correcting defects before completion is typically not a disallow cost. So these things matter at small points but they can have a big a big impact what's the programme what's the scope asked to see so the programme would show planned completion
32:30 - What the Scope can ask the programme to show
Ben Walker: Dates all that sort of things the original is coming as Glenn just said from contract data part one for those contractual deadlines and obviously the realities of planned completion we update as we go. And this is the kind of observed route that we're talking about before so we're not over controlling the how we're getting a way of observing it and going through an acceptance gateway but acceptance is not a precondition for getting on with the works. So we don't hold up the programme by not accepting things. We might not get an accepted programme but at least the contractor's still got the right to carry on with the works it's ultimately their plan. But acceptance does of course give us certainty also helps us inform what's going on helps us with all sorts of other sort of reporting and other bits and pieces so the conditions for contracts already say what a programme must show but the scope can ask for more and you can see here in our example we also want to ask for steps of no more than 15 minutes.
So we've got that granularity anticip expectation of granularity defined in this in the scope when each item goes in and out of the oven the oven temperatures at each stage which self we're going to use for each item the resting period so you can see we've asked for these extra things. So in accordance with clause 31 which shows you what a programme must include that I think it's rather the last or the penultimate statement says and anything else the scope says and this is where we get an opportunity to inject those things in along potentially also with of course the shape the programme as Glenn was saying what package we're going to use and you know if we want to print it in triplicate then say so. So it's all those things. So other than that though everything on the left hand side there contractors times temperatures shelves that's you know that's that's for the contractor to plan as long as it's compliant with the scope.
So it has the potential to fail two of those tests remember the four tests for reply to a programme you accept it if it's reasonable practicable shows the information a contract requires and complies with the scope so it's those that's not the order they put them in I can't remember the exact order but it's those last two I just mentioned it's does it show the information required? That's the test in itself and that will include anything that's been put in the scope and secondly does it comply with the scope so if the programme's very obviously sequencing or something that doesn't adhere to the scope then hopefully the project manager spots that and points it out.
Glenn Hide: Anything to add on that other than to say we need to get the vegetable gratin design accepted way in advance obviously so that's going to be there's stuff leading up to this the big event is obviously the cooking but there's things that need to happen before fancy that we need design accepted before we order stuff on site.
Ben Walker: Yeah and you just triggered something else in my mind as well you're absolutely right and and not that far down the list we talk about order and timing of the contractor's operations to deliver the works that's pretty common sense isn't it you'd expect that on a programme but the next one the order and timing of the of the work of the client and others so really important there that we've got the pie on there more important than it looks because we know the scope requires certain procedure as we'll find out in a minute in making the oven ready for that key date that condition stated for the key date. So important to have those sorts of things on your programme as well and of course provision of the beef right at the very start there we'll see in a moment that's something the client is to provide they're going to provide the beef so we want we want that on our programme because without showing that on our programme we lose the ability maybe to enact compensation number three of the list which is about the client not providing something in accordance with the accepted programme.
So there's really important we fully understand how the programme and the scope kind of interact and how we show those programme scope contract data different elements come together. And this is a good place to another reason Glenn I think we'd said before to get your programme submitted contract data part two before you start. Yeah and then you know you can refine things if they're not quite what you expect. Yeah.
36:26 - Tests, inspections and the quality plan
Glenn Hide: Excellent we've rolled the next two elements in together so section 600 quality 700 tests and inspections. So each requirement on specification has a test behind it. Each test has four parts what's tested what counts as a part who does it and when so we've got here the prawn cocktail temperature eight degrees or less at the centre of one portion who is it done by the contractor when as it goes to the table the beef colour pink through the centre grey edge no more than five millimeters who's going to do that the supervisor when is it done on carving the Yorkshire pudding height at least 60 millimeters high supervisor's going to do that as they leave the oven potato craft etc gravy temperature so each test passes when who's it done by and when is it actually done. So we're being nice and prescriptive here on the test inspections that are expected. Round each test the quality plan says who tests it, how it's recorded and what happens on a fail calibrate.
So we've got calibration to do the thermometer we've got to make sure each thermometer reads between 0 and 1 degree in ice water to make sure that the temperature or the thermometer the recording is actually going to be correct. Notice the supervisor gets 10 minutes notice before each test and one record each every result with timing and reading one on one sheet for the supervisor. So we're confirming those elements the contractor provides the kit and also where a test just draw destroys the thing tested tearing open the pudding tasting a portion well we needed to have ordered a few extra to account for that otherwise someone is going to go hungry. So the scope adds extra ones to the count so you've still got it right going out onto the dinner. So test and hold points are also procedural controller method usually sits if the client needs it again if they need it. If you can't write the pass is when column then you probably haven't specified the works properly. So it may you may need to think about being a bit more prescriptive on what does this mean for you as the client.
Ben Walker: Yeah I think and I think there's a natural connection here between 100 which is where we talked about specifying what we want drawing specifications and 700 which is about objectively testing that it's what we want. So it's really empowering the supervisor to be able to objectively establish supervisors tests. And remember what contract says is tests this those set of clauses only apply where the scope or the applicable law applies. So if some test inspections it might be law to do them others you're gonna need to list them out. Otherwise you can't assume that you've got rights to just do them you can of course you could add this in later because you'd forgot to do it at the start much better much more efficient and it's going to avoid a compensation event if you do that at the beginning and making sure as Glenn said that we know who's going to provide the different materials.
39:31 - Managing the works day to day
Ben Walker: So quick on this managing the works so how are we going to approach it? What's our rhythm of business? What tools and systems are we going to have to help us what's the record management system what's the communication system how are we going to do things so they've chosen the kitchen whiteboard here as the communication system under clause 13.2 we've got our meetings at 11 and 12 of course there may be additional ones instructed under early warnings. We've got the records being captured on the gather system of course we have test record sheets stays in the kitchen until the main course is completed and yeah notice the detail here we've got extra tins so that we can make sure we can create enough Yorkshire puddings to test them. I've definitely got people in my family that want to test them before they go to the table so there we go. But yeah this is your opportunity again to collaborate with the other party before you actually sign the contract and work through how you're gonna manage it.
Now this will have a big a big impact on whether or not it's option A, B, C, D, E, or F, will have a dramatic impact on how we're gonna approach things what's the format of our payment applications is it is it fairly simple because it's option A or actually are we going to be operating option D and we want we want to really agree on how we're mapping to the scheduled cost components, what records we're keeping how we're keeping them how often we're going to review them and how we're gonna go about finalizing parts of the works in a course of course 50.9 so it's it's a fairly you know you can put as much or as little as you want in this bit. I fear that people quite often underdevelop this part of the scope and they kind of see how we go. Whereas a huge amount of preparation can be done for the contrast bear in mind that copy and paste is the enemy because it does look very different from project to project it very much flows down from what strategy you take, what systems you're going to use to sort of meet the needs of the clauses that you're signing. Anything to add there guys?
Glenn Hide: No pretty comprehensive there.
David Allen: So yeah no I think you've you need to reinforce that point the collaborative development of the scope with those that are really going to be influenced by it and can influence it is is key because if you get it right at the beginning and you do get the detail in there then it's going to flow a lot easier. It's gonna work a lot better. Everybody will know what their obligations are and really where the their exposure to risk is under the contract and making sure that is fairly balanced. Yeah. Yeah.
42:03 - Working with Others and Key Dates
Glenn Hide: Good section 900 working with the clients and others so we already know that the client is providing the beef the oven has to be ready for the pudding so we've got the main course cooking the contract's used in the oven then everything out nothing left in the oven wiped and set the floors and the and the shelves clean of fat and then back on ready for the pie to go in. So not easy cleaning a warm oven but that's the requirement. So the key date is for the pie going in. So we've got to have enough time ready to clean the oven get it back up to temperature ready for that pie to go in. So in terms of others we've got the sibling and the they all bring in their own pie, the dish and the ingredients the pie is to go on the top fridge of the shelf the contractor does not touch or move the pie there. So who says what? Well the contract data will state the key date and the condition to be met.
So that's the oven ready at that time for it to be met. The scope says how the contractor shares the working area with others what work and by whom and when and for how long the key date and when the contractor expects to meet the condition. So the key date will be identified in contract data as we said and then on the programme we're going to show the that milestone on the programme as well and when the contractor is expecting to meet the condition. So hopefully the pie will be the oven will be ready in plenty of time probably in advance so we've got a little bit of float there before the pie is ready to go to go in. Tell them at once if the time the oven will be free changes the contractor tells the siblings straight away so they've got the opportunity of putting it in early if they want to and then yep they might want to make sure that it's it's cooked and a few minutes early might suit them.
A key date isn't completion it's a condition they've been met by a date so others can do what they need. So these will always be stated In contract data and they need to be prescribed as a key date. So don't get hung up on everything that sounds key is a key date. No, only a key date is a key date. And the consequences are quite different. So with sectional completions and completion date, we're well aware of delay damages under X7 and the fixed known cost that you're going to be liable for key dates. In very simple terms, the client can recover the costs that it's incurred as a result of that key date failing to be achieved. We've read several bulletins around key dates, what is claimable and what isn't. But potentially it's undefined cost hanging over the contractor's head rather than no cost. So don't be under any false illusions that key dates are there's no damages against the key date. Well, it's unascertained cost could be coming your way if you fail to achieve a key date.
Ben Walker: So equally it's another whole webinar that one, isn't it? And you've got a very good article on your website, Glenn, which I think you co-wrote with Rob Horn on key dates. That's that's my sort of reference for people to then have a look at a bit more detail of that. Well, just we're gonna have to move on because of the time, but just to say that whilst clause 25 is very important here, so is clause 60.1(5). Really important link here to compensation events. Big omission for a client to not describe in a section nine or equivalent what work they'll be doing on site and the work of others. Because if people are just turning up left, right, and centre, the contract can say, well, I don't know. Who are these people? They don't get possession of the site, they get access to it, but you they are supposed to be informed within the scope as to who else is working on the site with them.
So do be mindful of compensation event number five. So I'm gonna scoot over this slide just to say that you'll be clear what you're providing. So here you can see the kitchen equipment that we're providing, providing a 12-hole and a four-hole tin. So I guess that answers David's opening question on the diameter. But it's not quite as explicit as actually saying it, is it? So there we go. And yes, we know about the beef. The beef, perhaps it should say it says raw, but perhaps we'll just say at room temperature, because frozen's no good, is it? So there's a there's a bigger omission there in the scope. Reminds me of a of a of a couple of engineering projects in the aviation sector where they didn't prescribe that. It might be a it might be a bit of an urban legend, but something about testing windscreen on aeroplanes and they were using turkeys, but they might have been using frozen ones. I can't remember now, but anyway, we digress.
Uh there's one of food-related topics in this. So, yeah, and you can see there that the client is clear that they had to provide the utilities, the table, dining service, and other bits and pieces. So all this stuff is important, and working through this carefully also helps you tease out some entries that you might want to make in the other sections. Glenn, you've got a slide kind of combining just a few other things together here.
46:49 - Health and safety, subcontracting and title
Glenn Hide: Yeah, just whizzing through. So thinking about health and safety. So we could be prescriptive here, wash hands before handling food, after raw beef or fish, one board for the raw beef, another for everything else, prawns and the sauce at five degrees or less until the starter's put together, pan handles turned in, oven gloves for anything in or out of the oven. So sometimes this will be a legal requirement, sometimes it'll be a client-specific requirement, maybe being it over not over cautious, but just extra elements that they want to make sure that the contractor is going to be complying with. Uh subcontracting. So anyone subcontracting is to handle food holds a level two award in food safety and catering, regulated by Ofqual, awarded no one three years before the starting date. Copy the certificate comes with a proposal for acceptance. So reasons to refute stated up front, not that it's probably much time to subcontract too much here, but title to leftovers. Oh, this is important.
Who has a title to leftovers? Because someone you might be thinking, oh, I'm looking forward to this, but no, maybe they've got another idea on who they want the leftovers. Maybe they're going to take it to a local food bank. I don't know how much they're really thinking of cooking here, but you may not have title. So at half past two, the contractor has a title to the leftover food, including what the client provided. That includes the beef bone, the dripping, not the pudding. That belongs to others. Leftovers to be taken by three o'clock. So at least it sets out here the expectations are clear. Each of these clauses refer to the scope. Some might be subject to the law, as we said. So think about what is already a legal requirement and what is sort of preferential, in which case they need to be included within the scope. Anything that's subject to the law obviously is already a requirement for them to comply with.
Ben Walker: Yeah, always read that title one because from NEC two to three to four, I think it changed, didn't it? I think the default position changed. So I haven't got all three in front of me to double check that, but really look after check that, particularly if you're doing a big demolition of a plant room or something, because you may not be, you might be tendering on the assumption you're going to get that copper and you might not be. Quick slide there. All these slides and webinars are all available afterwards. So part of what we want to do is provide you a bit of reference material. But again, the user guide has a whole chapter on this where the clauses, where the conditions of contract relate to the to and are drawn upon from the scope, or around the other way, where the where the scope is drawn upon. Statements in the scope are drawn upon by certain conditions of contract. So here's a quick example of some of the things we've been talking about.
You can see the different multitude of things that scope actually carries a statement on, right? It's not as simple as a scope being drawn to specifications. We then learn, oh, it's also constraints, it's how we can't do things, but actually it's even more than that. And you know, there's about I've encountered them recently, but NEC4, probably at least two dozen plus, depending on what secondary options you choose. So do go and have a look at the designated chapter on this because it's a really, again, it's a really good way of just spotting that you've made all those statements that you're supposed to make.
49:55 - Scope versus Contract Data and pricing documents
Ben Walker: A little bit on scope and contract data, Glenn. They're different things, aren't they?
Glenn Hide: Yeah, just picking up that they are different. Data in the contract data, requirements in the scope. So in contract data, okay, it states where the scope is. So it'll describe which of the contract documents actually form the scope. The starting date, well, that's going to be Sunday, 10 o'clock. Well, they're live. There's bits that come before then, like agreeing the design for the gratin. The completion date, uh, section one, 12:30 for the starter, and then one o'clock for the main course. A key date for the pie is quarter past one there. Uh condition, oven empty, wiped clean, of the fat and set 180 degrees. That's the condition for the key date. And the contract's design is in, well, the accepted gratin in particular, so they're the elements that the contractor has to design. The scope will be defining what done looks like for each section, how the work in areas are shared with others, and when what the client provides, what the programme shows, there's no dates in the scope and common slip-ups that we see dates repeated in the scope, and then they're only changed in one place.
So keep it in the right place, don't feel you need to double up, that just causes ambiguity, so confusion. Describing the work in the contract data, not in the scope, and a scope that says by lunchtime instead of leaving it to the date. So again, that could cause at the very least ambiguity between the two there.
Ben Walker: Yeah, absolutely. Don't add new conditions into the scope because it won't work. Quick one on the pricing documents. Information in the pricing documents is not scope. So it's no good relying on a slightly described description of an activity in the activity schedule to sort of top up what you meant in the scope. They are completely, you know, not for that purpose. Pricing is for pricing, pricing, documents for pricing, scope is for defining what you want. Very useful to have easy linkage, easy synergy between the two. On option A, it makes payment much easier. In option C, it you can do your own value analysis a bit easier, perhaps. And I won't spend quite a long time spreading that bill of quantities over the programme as well for a similar reason. But they are different things for different purposes. So yeah, don't rely on items in your pricing document to specify things.
52:17 - Changing the Scope, ambiguity and compensation events
Glenn Hide: Yeah, and then last bit to finish, so changing the scope. Well, any change to what's in the scope is obviously going to be a compensation event. So really important that we try and make the scope as comprehensive as we possibly can. If each pudding, if the project manager decides, oh no, I want them 80 millimetres, not 60, well, first of all, when's that been instructed? It needs to be early enough so we can make the change, and that will be a compensation event. Skip testing, resting the batter. We're running late. So what is it? An instruction change at a constraint, so it's a change of the scope. The result, there will be a compensation event, and the client now owns the risk to put it right, because they've told the contractor to skip a particular test. The beef is at 58 degrees. We'll take it as it is. Well, accepting a defect means changing the scope to match what was delivered. The scope changes, usually with a change of the prices in the client's favour.
So if the beef isn't to the scope, then the client could accept it. But that in itself, normally any acceptance of a defect will come at a cost saving that the contractor will put forward. Why else would a client accept not what they originally allowed for? And again, we're making these fit, obviously, our example today. How many serving dishes? Well, the scope doesn't say. Well, that's an ambiguity. Either side notifies it, the project manager says how to resolve it. If that changes the scope, it's assessed in favour of the side that didn't write it. So if there's an ambiguity, then it goes in favour of the one who didn't create the ambiguity. The other thing is obviously this is everything is assuming those Z clauses, because sometimes Z clauses might change that in the first place. Um can I swap the gratin vegetables? Well, the contractor's changing its own accepted design at its own request. It's a change of the scope, but that would not be a compensation because they're changing it for a reason that suits themselves. They want to change it for sprouts. Who wants sprouts? No one wants sprouts, surely.
54:16 - Seven drafting traps to avoid
Ben Walker: So a clear scope. They'd have to say not sprouts, wouldn't they? They'd have to list sprouts next potatoes in the constraints if they wanted to exclude that, because otherwise it would be a perfectly valid design to submit as a as a as a different type of vegetable. So we've got to think through the possibilities if and any that we want to avoid by constraining them. Good stuff. Okay, here's seven ways, because that's what fit on the screen to make your scope taste off. So conditions of contracts written into the scope, don't do that. There's no way of calling them. So if you're trying to allocate risk and things like that inside the scope, that's that's a pretty sort of non-starter, really. You need to think about Z clauses, your conditions of contract, your compensation events, your client liabilities, those kinds of things. Subjective standards called to the satisfaction of the project manager. Okay, but then we've got a load of procedures and rest of it.
Why not just state the past value? So what is that objectify things we talked about already? Dates repeated in the scope to Glenn's point. You know, let's try and keep dates out of the scope. Let's talk about conditions and tests in this in the scope. Specification in the pricing documents, we just said that as well. We don't want to try and augment or supplement what we're expecting in the pricing documents. We might describe things in sufficient detail to be able to map them to the scope so we can see what an activity item comprises in terms of is it complete? That's very useful, but we wouldn't rely upon it to specify other things. No exclusions, so silent on the pudding and the washing up. Okay, you know, we're there to describe what we want, but it is helpful perhaps to sort of stop any ambiguities or misunderstandings to say what we don't want as well, uh, to kind of really successfully frame what the product what this contract is to deliver in terms of the works.
Requirements with no test, smooth gravy is no good, right? We can actually answer that question about the type of sieve because the sieve is gonna be provided, I think, by the client, wasn't it? And to be calibrated in a certain way before we start. And and that final one, you know, if we're gonna prescribe a method or a constraint, ask ourselves why. Because if you can't, as a client, say why we're doing this, then is the question, well, why we why are we taking unnecessary risk in prescribing the how or limiting or stifling the contractors' freedoms and innovation? Why would we do that? So again, being kind of over-prescriptive unnecessarily carries with it a bit of a risk. Which clause does it is it for? Is it what or a limit on the how? How would we test it and is it in the right document? So I think that's one little audit we can do as well on our scopes to make sure that things are in the right place. And if we get all that right, then hopefully we'll have clean plates. Four things to take away, Glenn, David, I can talk soon.
57:10 - Four takeaways and the next webinar
Glenn Hide: So four things to take away, what and the limits on how. So the scope says what's required, the method stays the contractors within the limits. Observe by default, see the how through the programme, control it only with a reason that you can state every line earns its place, it observes a clause, it can be tested, and it's in the right document. It's there for a reason. And words that usually mean nobody can test it shall ensure appropriate to the satisfaction of as required, etc. So we need to be more prescriptive because if all subjectivity does is create dispute. So that's not, it shouldn't be in anyone's interests to allow dispute to be arisen. So we want to avoid subjective phrases. NEC tries to do that, but even you know, you can't say that there's no subjectivity anywhere in the NEC, but it tries to do that. Z clause is obviously not so, and obviously scope may also be not so because they're written by obviously the clients. So there's not the same policing, if you like, over those dog those documents as well.
Ben Walker: Good stuff. Glenn, David, I think we'd better propose that we push Q&A into maybe the NEC people chat group or some somewhere on this one. I think, yeah. So it's a packed session that has so much to cover in scope. I spent a whole day on it the other day on a training session. So there is a lot to say. But we hope you found that useful.
Ben Walker: As I say, the slides and these webinars are available to rewatch, or at least the webinars are available to re-watch, and obviously you can pause and and speed through the slides as well on there. Next time we're looking at Monday, the 14th of December, 4:30, and we're hoping to do one on site information. So it won't be quite such a big session. There should hopefully certainly be some time for questions and answers on that, although we say that every time and they're always packed with info. But closure remarks, guys.
David Allen: From my perspective, I think that it just shows you how important it is to get the scope right. One of the things I was going to pick up on is the terminology, you know, not allowing the use of things like ensure that instead of being you know, applying the reasonableness of things which should be in there because otherwise you can design in obligations that you maybe weren't looking for, you know, the fitness for purpose, absolute obligations, you might inadvertently move the parties into that space. But the bottom line is through all of this, really, it's having a scope that it's just clear on who will do or provide what and in what form and under what conditions. And that's basically what you've gone through today. So that's what we need to get right.
Glenn Hide: Yeah, it's important, isn't it? And I think what we've done is we've taken a very important topic and we present it in a way that everyone can relate to. So that's it's not it's a it's a light-hearted look at a very serious, important topic, and everyone can relate to what we've talked through today, and we can apply these same rules, these same principles to whatever our construction project is, whether it's a viaduct, whether it's a railway, whether it's a water treatment works, then everything we've learned today, at the end of the day, scope is scope. Just like a programme is a programme. If you're making a cup of tea or building a bridge, it's a series of activities with durations and logic link between them, and it's exactly the same. So our scope for is is typical and we can apply that to any kind of our construction environments.
Ben Walker: Well, I hopefully we've presented it in a digestible way, but our I think overall advice now is if that's whet your appetite, go. I don't know where these puns are coming from, go and go and get yourself the official user group user guide, volume two, I think it's chapter three, go and have a look through that because you know this has been a bit of an intro to that document, really, and hopefully you know the real details in there and yeah, go and have a good look and do some audits on your scopes before and pre-and-post contract, you know. No time like the present.
Glenn Hide: Thank you very much, everyone. Look forward to seeing you on the next one. Good about you, Ben. I'm hungry. Very good.
Ben Walker: Cheers, everyone. Cheers, thank you. Bye.
