NEC4 Scope and Project Requirements

Under the NEC4 Engineering and Construction Contract (ECC), Scope describes the works the Contractor must provide and the constraints on how they are provided. It also gives the contract its project-specific requirements. The Parties use it when pricing the work, preparing designs and programmes, and deciding whether the finished works meet the contract.

A requirement can appear clear to the person writing it while leaving important questions for the people carrying it out. On a water project, an instruction to maintain existing operations says little about how a new connection can be made, what interruption is permitted or who will operate the isolation valves. Those details affect both the price and the construction plan.

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 new system will supply recycled water from an existing treatment plant to an industrial estate. The plant must remain in operation while the works are constructed and connected.

What belongs in NEC4 Scope

Scope may comprise several documents, including specifications, drawings and requirements for managing the work. Those documents need to be identified properly in Contract Data. Placing a report in the tender folder does not, by itself, establish that everything in it is a requirement the Contractor must meet.

Where the contract includes Scope provided by the Contractor for its design, that information is identified separately in Contract Data part two. It needs to be read with the Client’s Scope. A design submitted for acceptance during delivery does not automatically change either set of requirements.

Site Information has a different purpose. For the fictional Ironbark project, a survey of the existing treatment plant would describe existing conditions, while Scope would state the connection the Contractor must provide and the restrictions on making it. A factual record and a requirement for new work should not be left indistinguishable in the same document pack.

The Activity Schedule also has a separate role. Ironbark’s Option C arrangement uses it to establish the target, not to pay for the work. Under neither A nor C is the Activity Schedule Scope, and an omission from the schedule does not, by itself, remove work which Scope requires.

Performance and operating constraints

Ironbark needs a functioning supply system. Scope would need to establish the required output and the conditions under which that output must be achieved, including the relevant flow, pressure and water-quality requirements. The designers and those reviewing the commissioning results need to be working to the same criteria.

The requirement to keep the treatment plant operating needs comparable detail. Tenderers need to know which assets must remain available and what interruptions, if any, are permitted. Where a connection requires an isolation, Scope should explain the restrictions on that work and the arrangements for coordinating it with the operator. These requirements need the operator’s input before tender.

A statement such as “coordinate all shutdowns with the operator” leaves much unresolved. The Contractor still needs to know how far ahead to request an isolation, what information to provide and who will carry out the operational steps. If the operator has work to do, the Client needs to establish that it can provide the required support. The Contractor cannot price and programme the connection reliably around an undefined future agreement.

Scope should distinguish a required outcome from a prescribed method. If the Client requires a particular sequence, it should say so. If the Contractor can choose how to maintain the required service, the documents should leave that choice open rather than prescribe a conflicting sequence elsewhere. A restriction which appears only on one drawing can materially change the work described in the specification.

Design responsibilities and interfaces

The Contractor designs the parts of the works which Scope says it is to design. Ironbark’s Scope would therefore need to identify the design responsibilities for the new assets and their connections to the existing plant.

For example, if the Contractor is to design the pumping installation while the Client provides the existing plant’s control requirements, the interface needs more than a line dividing two design packages. The Contractor needs usable information about the control system and a clear statement of what the new installation must do. The Client needs to identify who supplies that information and arrange for it to be available when the design requires it.

The same issue can arise where a pump supplier’s design depends on a foundation designed by someone else. The documents should establish who provides the equipment loads and who uses them to complete the foundation design. Describing each package separately does not resolve the connection between them.

Scope should also identify the design particulars to be submitted for acceptance. The submission needs to contain enough information for the required review, with preparation and review allowed for in the programme. Acceptance of a design does not transfer the Contractor’s design responsibility to the Project Manager or relieve it of the obligation to comply with Scope.

Testing commissioning and Completion

An installed pump may pass a factory test without demonstrating that the completed scheme operates correctly. On Ironbark, the commissioning requirements would need to cover the installed system and its connection to the existing plant, including the relevant controls and performance tests.

The test requirements should establish the conditions under which performance is measured, the results required and the records to be provided. If testing depends on the operator making the plant available, that contribution needs to be planned alongside the Contractor’s work. Otherwise, a completed installation may be waiting for a test that neither party has arranged.

Scope should identify the work which must be done by the Completion Date. If successful commissioning, operating instructions or particular records are required before Completion, state that expressly. Labels such as “mechanical completion” and “operational readiness” need definitions if they are used; they do not replace the ECC’s definition of Completion. A Key Date requires a stated Condition to be met by its date. Separate Completion of a section is addressed through Option X5, while an internal programme milestone need not be either. The intended obligation should determine which provision is used. Defects which prevent the Client using the works or Others doing their work also remain relevant to the Completion test.

For Ironbark, this means deciding what demonstrates that the new system is ready for its intended use, then recording the required work and evidence in Scope. The quality, testing and Defect provisions govern the checks during delivery and the contractual test for Completion.

Project information and reporting

Scope can state the project information the Contractor must provide, but each requirement creates work. A useful report should support a decision or help those managing delivery establish what needs attention.

On Ironbark, a forward schedule of connection activities could help the operator arrange attendance and prepare isolations. It would need to identify the proposed work and the decisions or information outstanding. Requiring the same details in several reports would add effort without necessarily improving that coordination.

The detail should suit the works and the people using it. Existing contractual requirements still apply, and necessary records must be retained. However, Scope should not become a collection of every reporting template the Client has used on other projects. Nor should it conceal changes to payment rights or liability. Those changes need to be addressed openly when considering amendments to the NEC4 contract.

Issuing and changing Scope

Before tender, the document list and revisions need to be reconciled. The person assembling the pack should be able to show which requirements apply and how referenced documents fit together. Conflicts should be resolved while the designers and operator can still explain the intended arrangements.

During delivery, an explanation of an existing requirement needs to be distinguished from a change to it. If Ironbark’s operator asks for an additional control function, the team should first establish whether Scope already requires it. The operator’s request alone would not change Scope. Where a change is needed, the Project Manager, or an appropriately notified delegate, must issue the relevant instruction.

The change should identify what is being replaced or added so that the site team can establish the current requirement. An updated drawing should not leave people comparing versions to guess which differences are instructions and which are corrections to presentation. The applicable compensation event provisions must then be considered, including their exceptions and any amendments to the signed contract.

A change in the Contractor’s proposed sequence is a different matter. A revised programme might show another way of constructing the connection while still complying with Scope. Accepting that programme would not, by itself, authorise a departure from an operating constraint or add a new requirement to Scope.

Reviewing Scope before tender

I would ask a planner and estimator who were not involved in drafting Ironbark’s Scope to explain how they would deliver and price the connection works. If their answers depend on assumptions about isolation periods, design information or the operator’s attendance, those assumptions need to be examined before tender. Some may reveal missing requirements; others may identify choices that can properly remain with the Contractor.

The operator should also review the requirements from the perspective of running the plant. A construction sequence may appear workable on paper while relying on support the operational team cannot provide. Resolving that issue before tender allows the parties to price and plan the same work.

This review is part of the wider preparation for using NEC4 in Australia. On Ironbark, it would leave tenderers with a defined connection to price and the delivery team with requirements it can use when preparing designs, reviewing programmes and planning commissioning.