Under the NEC4 Engineering and Construction Contract (ECC), a project decision needs to be communicated by the person authorised to make it and through the route required by the contract. A discussion can help the team agree a workable approach, but an instruction, notification or acceptance may still be needed before the relevant work can proceed.
The fictional Ironbark Recycled Water Scheme, introduced in NEC4 Explained, provides an example. A regional Australian water utility is procuring a pipeline, pumping station and balancing tank under ECC Option C. The works will supply recycled water from an existing treatment plant to an industrial estate. The plant must remain operational while the new works are constructed and connected.
Suppose the plant operator questions whether the Contractor’s proposed isolation arrangements will maintain the required service during the connection. The team needs to understand the concern and compare the proposal with Scope. It then needs to establish who must make any decision and how that decision is to be communicated.
NEC4 communications
A conversation with the operator can explain how the plant works and identify a practical difficulty. It may lead to a request for information, an early warning or a design submission. An instruction may be needed if the requirement is to change. Each communication performs a particular contractual function, even though they concern the same connection.
A notification tells the recipient about a matter which the contract requires to be notified and may initiate a procedure. An instruction directs an action within the authority given by the contract. A submission for acceptance presents information for a decision under the relevant provision. The response needs to communicate the decision required by that procedure.
At Ironbark, asking the Project Manager to confirm an operating restriction does not instruct a different isolation arrangement. Sending revised design particulars does not establish that they have been accepted. The sender should make clear what action is being taken and what response is needed.
Form and receipt of communications
Clause 13.1 requires contractual communications to be in a form that can be read, copied and recorded. Writing must be in the language of the contract, identified in Contract Data. Electronic communications can meet those requirements; an unrecorded conversation alone does not.
Clause 13.2 determines when a communication takes effect. Where Scope specifies a communication system, it takes effect when communicated through that system. If Scope specifies no system, it takes effect when received at the recipient’s last notified address for communications or, if none has been notified, the address stated in Contract Data.
Email can therefore be an appropriate route. If Scope specifies a particular platform, an email sent outside it should not be assumed to have the same contractual effect. Uploading a draft to a shared workspace may also be different from issuing it to the intended recipient through the specified process.
The team should establish the communication arrangements at the outset, including any forms required by the contract. Confirm who needs access and how issue and receipt will be recorded. Attachments must be readable, and linked documents should remain accessible at the revision issued. A software workflow should support those arrangements rather than introduce requirements which the contract does not contain.
The provisions described here are those of the June 2017 ECC incorporating the January 2023 amendments, without project amendments affecting these procedures. The communication requirements, delegations and response periods in the signed contract must be checked.
Separate notices and certificates
Clause 13.7 requires a notification or certificate required by the contract to be communicated separately from other communications. A required notice should not be left within a progress report or a bundle of meeting minutes for the recipient to find.
If Ironbark’s isolation concern requires an early warning, showing the difficulty on a revised programme does not also give that notification. The early warning needs to be communicated separately. If the matter also requires a compensation event notification, that is another contractual action. The relationship between the two is considered in Early Warning or Compensation Event.
This does not mean every subject discussed by the team needs a separate email. The requirement concerns contractual notifications and certificates. A specified platform may provide separate communications linked to the same issue, so that each action can be identified without losing the supporting discussion.
Minutes remain useful records of what was discussed and agreed. Whether they also communicate a contractual act depends on their content, the sender’s authority and compliance with the communication requirements, including separation where required. An action in the minutes to issue a notification is not the notification itself.
Contractual authority
The operator’s knowledge is essential to planning Ironbark’s connection. It does not, by itself, give the operator authority to change Scope or accept the Contractor’s design.
The Project Manager makes the decisions allocated to that role, including instructions changing Scope and responses to design and programme submissions. The Supervisor has its own inspection, testing and Defect functions and can issue instructions within that role. Appointment as Supervisor alone does not confer the Project Manager’s authority to change Scope.
The Client needs to arrange the internal decisions and operational support required for delivery. A request from a Client representative should not automatically be treated as a Project Manager’s instruction. The Contractor also needs clear arrangements for the people issuing communications on its behalf.
Under clause 14.2, the Project Manager and Supervisor may delegate actions after notifying the Contractor of the delegate’s name and the actions delegated. They may cancel a delegation and may still carry out an action they have delegated. The team should check the notified authority rather than rely on a job title or attendance at meetings.
Internal approvals need to allow the authorised person to respond within the contractual timescales. If Ironbark’s Project Manager needs the operator’s advice, that review should be arranged in time for the response. Internal approval problems are examined in When the Project Manager Lacks Authority.
Instructions and changes to Scope
The Project Manager needs to compare the operator’s concern with Ironbark’s existing Scope. If the proposed isolation fails to meet an operating constraint already stated there, the Contractor may need to revise its proposal to comply. Discussing another arrangement does not, by itself, change Scope or establish a compensation event.
If the Client requires a different operating constraint, the Project Manager can instruct a change to Scope under clause 14.3. The instruction should identify the requirement being added, removed or replaced. A revised drawing needs to make clear which changes alter the requirement and which merely correct its presentation.
Calling a communication a clarification does not determine its effect. That depends on what it requires when compared with the existing contract. The article on Scope and Project Requirements examines how requirements are defined and changed.
Clause 27.3 requires the Contractor to obey instructions given by the Project Manager or Supervisor which are in accordance with the contract. If the meaning or authority is unclear, the Contractor should raise that promptly with the appropriate person. Seeking clarification does not, by itself, suspend an instruction which the Contractor is required to obey.
Where either the Project Manager or Contractor becomes aware of an ambiguity or inconsistency in or between the contract documents, clause 17.1 requires it to notify the other. The Project Manager states how the matter should be resolved. If resolution requires a change to Scope, the relevant instruction must follow. This does not give the Project Manager a general power to rewrite the conditions of contract.
Submissions for acceptance
If Ironbark’s Scope makes the Contractor responsible for the connection design and requires design particulars for acceptance, a revised design must follow that process. The submission should identify its revision and explain what has changed. The operator can advise on the isolation arrangements, while acceptance comes from the Project Manager or a person with the relevant notified delegation.
Clause 13.4 requires the Project Manager to reply to submissions and resubmissions for acceptance. If the reply is not acceptance, the reasons must contain enough detail for the Contractor to correct the matter. The Contractor resubmits within the period for reply, taking those reasons into account. Needing more information to assess the submission fully is a stated reason for withholding acceptance.
An acknowledgement confirms receipt. Informal review comments may help the Contractor develop the proposal, but they do not necessarily communicate the required decision. A response marked ‘reviewed’ should not leave the team guessing whether the submission has been accepted or needs to be corrected and resubmitted.
For design submissions under clause 21.2, the Contractor does not proceed with the relevant work until the Project Manager has accepted its design. Acceptance does not remove the Contractor’s responsibility to provide the works or its design liability. Programme acceptance has a different purpose and does not itself change Scope or the Completion Date. NEC4 Acceptance explains those effects in more detail.
The Project Manager may withhold acceptance for a reason not stated in the contract. For the design and programme submissions considered here, that is a compensation event under clause 60.1(9). Clause 13.8 confirms that withholding acceptance for a reason stated in the conditions of contract is not a compensation event. Correctly communicating a decision does not establish that the reason given is one stated in the contract.
Response periods and missing decisions
Contract Data identifies the period for reply and can state different periods for specified communications. Under clause 13.3, the Project Manager, Supervisor or Contractor replies within that period where the contract requires a reply, unless the conditions of contract state otherwise. It is not a deadline for answering every message sent by the project team.
Some procedures have their own timescales. If Ironbark’s connection planning leads to a revised programme submission, clause 31.3 gives the Project Manager two weeks to notify acceptance or reasons for not accepting it. The correspondence system should track that deadline rather than substitute a general period for reply.
An extension also needs the correct contractual basis. Under clause 13.5, the Project Manager and Contractor must agree an extension to the period for reply before the reply is due. The Project Manager informs the Contractor of the agreed extension. Other procedure-specific periods need to be checked against their own provisions.
When a response is missing, check whether the communication took effect, what decision was required and when it became due. Contact the responsible person and identify the work waiting on that decision. If the response is unclear, establish what it means rather than let different interpretations pass into the construction plan.
Silence does not generally mean acceptance. Some procedures require a further notification and a further period before a specified consequence follows. An unanswered design submission should not be treated as permission to proceed with the relevant work. NEC4 Response Times examines the particular mechanisms and the consequences of missing responses.
Keeping usable records
A communication register should identify the matter, who issued and received the communication, when it took effect and any response due. Retain the communication and its attachments as issued, with subsequent revisions linked to them. The register is a management record; an entry in it does not replace a communication required by the contract.
Before Ironbark’s connection proceeds, I would ask the team to show which operating requirements apply and how the outstanding decisions are being dealt with. They should be able to identify any instruction changing the requirement and the current status of the relevant design and programme submissions. If those answers require a search through several personal inboxes, the record is not readily usable by the people planning the work.
The operator and construction team need to understand the arrangement they are to use. On Ironbark, effective NEC4 contract administration would leave them with the applicable requirements, the decisions on their proposals and a clear record of any changes. They can then plan the connection around decisions which have actually been made, rather than assumptions about what someone intended.
