A landmark protocol …

Go to www.eotprotocol.com please. Download the Delay & Disruption Protocol; it's yours free. Two years of work and one year of consultation have gone into this splendid work. It is the first major policy document in the Society of Construction Law's development. And it's a landmark. The only mistake is to call it a protocol. In truth, it is just a guide. Oh, it's a very good guide for managing change on a construction project, change that threatens the programme and the completion date and claims for lateness. The aim is that, in time, most contract documents will adopt this "guide", as the best way to deal with delay and disruption issues. The trouble with that remark is that it carries the implication that what lurks in the plethora of standard forms right now is not quite ticketyboo; that the protocol is a better bet. Ruffled feathers, eh? But, believe me, what the industry really cries out for is one set of clear rules for managing change on a project. Clear enough to be understood by builders, rather than lawyers.

So, what does the "guide" guide us to? First, it demands not just a building programme showing manner and sequence, it demands a record of actual progress. This is the tool for managing change. The benefit for the employer is to establish a revised, later date from which damages will run.

Then the idea is to deal with extensions of time soon after the delay event. A shift of thinking is needed here. The employer is inclined to want to wait to see what the effect of a delay event really is. The contractor, in this guide, will be entitled to require the architect/engineer/contract administrator to predict the effect of the event and add time immediately. Then any later knock-on delays that are traceable back to the root event will be given more time.

Float at the back end of the programme is tackled head on. It is daft to have a programme that hasn't got an actual finish at least a few weeks before the formal contract completion date. If a delay occurs that eats into that float and that delay would ordinarily extend time, the protocol says no to an extension; but it says yes to compensation because the contractor's work has been disrupted. A lot of current contract documents would suggest an extension of time is appropriate, but there is an air of reality about the protocol's stance.

What the industry really cries out for is one set of clear rules for managing change – clear enough to be understood by builders, not lawyers

There will be arguments about all this. Concurrent delays – that is, delay events warranting a time extension that occur simultaneously – entitle the contractor to an extension of time. But the extension may not therefore carry money compensation since the contractor has suffered no loss. So, there you are ready to put the roof on today but the architect has indicated a change to the wall plate design. The job stops. True, the builder can do bits and bobs here and there but what's the predicted effect? Whatever it is, he gets an extension of time now. And if later because of the roof delay a subcontractor can't get back as and when wanted and that delays the job some more, another extension is given.

Then what of mitigation? The protocol makes plain that mitigation does not extend to requiring the contractor to add extra resources or work outside planned working hours. And what of financial consequence of delay? The reminder is that extensions of time are often neutral events for which neither builder nor employer pays. They are best thought of quite separately from money. Those events that do have financial consequences, however, are costed to a system. Come to think of it, the effect can be pre-priced. Interest, global claims, overheads, disruption, acceleration are all here, even a guide to software.