Last year's famous Delay and Disruption Protocol presents difficult and potentially painful problems for contract administrators. So what should they do?
The publication of the Society of Construction Law's Delay and Disruption Protocol raises some difficult questions for contract administrators. First: what is it, and what are they supposed to do with it? One problem is that it is not a protocol – it does not lay out rules of behaviour to which the team is expected to sign their names. Nor is it designed to be incorporated as a tender or contract document. What it does do is provide guidance to people dealing with claims, and it is a useful discussion of the whole topic of delays with suggestions as to how they should be dealt with.

What should a contract administrator do when putting together the tender documents? The protocol has some model clauses relating to programming and keeping of records but these cannot simply be grafted on to the contract as they are inconsistent with most standard forms. The protocol says it is not intended to take precedence over express terms of the contract or be a statement of the law, but it suggests that it should be adopted by the parties as the best way to deal with such claims. This leaves it unclear as to what status the protocol should have.

The safe thing to do is either to leave it outside the contract, to be consulted only if it is helpful to a particular dispute, or take the points in it that are to apply to the project and make the necessary amendments to the standard form so that they can work together. But beware: doing so could alter the balance of risks between the parties. Contractors in particular may vehemently resist the protocol's suggestion that a float should belong to the project and be allocated to whoever first needs it.

What if the contract administrator includes the model clauses and appropriate consequential amendments in the contract documents? The clause concerning programming requires the contract administrator to say that he or she accepts that the contractor's programme is properly prepared and shows the manner and sequence in which the contractor plans to carry out the works. What is the effect of acceptance? It is said this merely constitutes an acknowledgement by the contract administrator that the accepted programme represents a contractually compliant, realistic and achievable depiction of the contractor's intended sequence and timing of the works. How can such an acknowledgement be made? Often the contract administrator will have insufficient information to judge this. If accepted, the contract administrator could become jointly liable with the contractor if it is shown that the programme is not realistic.

Contractors may vehemently resist the view that float should belong to the project and go to whoever first needs it

Should the protocol affect the way that contract administrators deal with delay and disruption claims during the contract? Even as guidance, there must be some doubt about this. The contract administrator's duty is first and foremost to administer the contract in accordance with its terms. The way in which the protocol suggests dealing with delay and disruption is different from the requirements of the JCT and ICE forms – or current legal thinking.

The protocol recommends that an extension of time should be reviewed periodically as events unfold. This is not in line with the JCT, which envisages an initial assessment followed by a review after practical completion. In relation to concurrent delay the protocol suggests that the contractor should be entitled to an extension of time but only to any costs caused by the employer's delay over and above those caused by the contractor's concurrent delay. The textbooks suggest that "dominant cause" is the right approach, but some recent cases have taken a different view. The obligation to mitigate delay under the protocol is a lesser obligation than best endeavours under the JCT contracts.