There is no doubt that technology has been and will continue to transform construction. Technology is a wide term, but it is enough to mention concepts such as BIM and Digital Twins or look at the emphasis on modern methods of construction (MMC) in the Construction Playbook to get a feel for where construction is heading. This is coupled by a growing start up sector, which focuses on better materials (for example, sustainable concrete), better methods such as modular construction, and better project and contract management that rely on project software systems.
This is good news and technology will play a key role in delivering the net zero agenda. But cutting edge technology is procured on different terms from those typically used in the construction industry. This is to be expected, as the risks, and risk allocation, are quite different. However, it does raise some challenges for traditional construction contracting models.
With this in mind, this blog takes a look at what the construction industry may be able to learn from the approach of contracts for the procurement of technology (commonly termed “tech contracts”). It showcases a few recurrent themes we see in the tech contracts we negotiate for our clients, where these may be different from the issues you commonly find when procuring the more traditional elements of a construction project. This includes, for example, data protection, cyber threats, confidentiality, access rights, licence scope, maintenance, and software development, all of which may need to be dealt with in the construction contracts.
JCT has produced an excellent guide which includes suggested drafting for BIM and has also set up a working committee and NEC includes Option X10 (information modelling), and also published a practice note on offsite modular construction in 2018. But in most cases, parties procuring tech will do so on a bespoke basis or indeed have to accept the supplier’s standard terms and conditions. For example, see our previous blog on modular construction where we discussed the type of amendments that modular projects typically require.
What can go wrong?
Disputes about technology projects tend to raise similar issues to construction disputes (such as delay, failure to meet a contractual specification, failure to complete a project at all) and it is not surprising that the Supreme Court decision in Triple Point, which received a lot of attention from construction lawyers due to the interpretation of its liquidated damages provisions, was in fact a dispute about a software system.
In a construction context, Bennett (Construction) Ltd v CIMC MBS Ltd (formerly Verbus Systems Ltd) is a good example of the problems that can arise when shoe horning modular payment provisions into a JCT payment regime (discussed in our blog on modular construction mentioned above).
Trant Engineering Ltd v Mott MacDonald Ltd led to the first guidance from the courts about the use of BIM as part of a construction dispute. In this case, the claimant contractor applied for an interim injunction requiring the defendant design consultant to provide the claimant with access to certain design data. The TCC (O’Farrell J) granted the mandatory interim injunction requiring the professional consultant to allow its client access to information held on the building information model.
Disputes in the tech context will also often concern the limits of use of a licensed technology solution. As the use of software systems in construction projects continues to grow, so the need for parties to understand how licensed software is procured and used.
SAP UK Ltd v Diageo Great Britain Ltd illustrated how allowing third party licensed software to inter-operate with other licensed software meant the licensee defendant acted outside the scope of the licence. The defendant allowed unauthorised third party access to the software, which resulted in a claim for £54m in additional licence fees. It is easy to see how this could arise in a construction project where an entire (and extensive) supply chain is encouraged, for good reason, to use a single software system.
Finally, it is important to remember that the technology itself is not free from risk, especially when it comes to developing bespoke systems. CIS General Insurance Ltd v IBM United Kingdom Ltd was a claim for wrongful termination and wasted costs following an unsuccessful technology project that was abandoned before completion. The judge commented that:
“…Project Cobalt [the transformation project] was a failure. The parties abandoned unfinished a project that had consumed costs in excess of £120 million, leaving them with a system offering little or no value and substantial financial losses…”.
All of this suggests that construction lawyers need a better understanding of the technology sector and to understand on what terms technology suppliers will usually provide their services and products.
How are technology contracts different?
In many ways technology contracts are similar to construction contracts, in that they need to allow for a design period, employer changes and a mechanism for allowing more time for delivery where appropriate. But there are also some key differences.
- The contract: In construction, it is common to use a construction standard form, such as FIDIC or NEC, usually with negotiated amendments. In technology contracts, for relatively standard “off the shelf” solutions with little customisation or configuration, you will usually have to contract on supplier standard terms. If you are looking for some systems integration or a bespoke tool, it is more likely that you may get movement away from the supplier’s standard terms, but will usually still contract on supplier terms.
- Cyber security: Critical where entrusting significant, important, proprietary and/or personal data to a third party tech supplier. It is standard to require a supplier to meet certain security standards (also required as part of your data protection responsibilities as a data controller). So, for example, if you use a third party to supply an HR tool, you need to ensure appropriate technical and organisational security measures are applied to the relevant personal data by the supplier, who is acting as your processor, as the supplier may be handling sensitive personal data about your employees. The risk of a data breach could have profound consequences for your employees. You would need to show the regulator that the measures in place were appropriate relative to the personal data that was handled by your processor. These requirements would not be found in a standard construction contract.
- Payment: Because a contract will prescribe the process for release of a tool, typically released as test or beta version and go through phases of user acceptance testing to check it works as set out in the specification or the supplier’s tender document, payment is usually tied to milestones that have to be completed within certain time frames. While insolvency may not be so much of a commercial risk where dealing with one of the larger tech companies, if procuring something bespoke from a smaller tech company consider what sort of safeguards might you be looking for, for example, a parent company guarantee? It is important to consider the payment model carefully and not to advance too much funding upfront.
- Ownership: In construction, title will usually pass as items are incorporated into the works. This is different from technology contracts, where most tech solutions are not “sold” to a customer. The software product is either licensed or made available as a service (SaaS), sometimes being made available through the cloud.
- Supplier insolvency: This is a common issue for construction but in a technology context the issues include continued access to source code and object code and the ability to replace the supplier (usually coupled with an exit assistance/business continuity plan). Often parties will include provisions relating to the development of exit assistance plans but will not in fact prepare these. This creates difficulties then when there is a need to exit, as the supplier has no continued incentive to cooperate to ensure a smooth transition or on supplier insolvency. This may not be an issue for the larger tech companies but needs to be considered for smaller start-up companies.
- Design standard: As with construction, any implied term that the solution will be “fit for purpose” is usually expressly excluded by suppliers. However, rather than simply refer to reasonable skill and care, it is common to provide a warranty that the solution will comply with the specification for a specified period.
Other points to consider
The points outlined above are just some of the key differences. Other points to consider include:
- Upgrades: whether there is a right to receive upgrades and for how long and where data is stored (in data centres or at supplier site or hosted in the cloud) consider how you will get access to it (and access to back-ups in the event of data loss).
- User acceptance testing: This involves agreeing the customer’s requirements or specification and the tests (known as acceptance tests) that will be carried out to ensure that the system meets the customer’s requirements or specification (as applicable). It is key to agree in advance a timetable and a process, and the elements that are to be tested (such as functionality and performance). Parties should also agree how any differences as to the contents and format of the tests are to be determined so that failure to agree the tests does not put the project timetable at risk. A supplier who fails the acceptance tests will usually have an obligation to remedy the defects and re-submit the system for testing. Continued failure gives rise to remedies on the part of the customer.
- Service levels: For tech procured as a service, it is necessary to consider and agree in advance for complex bespoke products the metrics the service must meet over the contract term (for example, service availability, responsiveness of customer support services and so on).
- Design life: It is common to specify a lengthy design life for construction assets. In technology, obsolescence and innovation create tension between lifespan of some smart products and lifespan of a construction project. For example, a power plant might have a design life of 25 years, but the technology would require several updates within that time and would not be expected to perform unchanged during that full period. It is also necessary to consider if the tech provider will be able to support a tech product over this sort of longer lifespan.
- Right to repair: Another key issue is the EU’s proposed right to repair. New EU eco-design standards for certain products (servers, data storage products, washing machines, electronic displays) require spare parts to be available for certain number of years after being placed on market.
- Cybersecurity and connectivity: the Department for Digital, Culture, Media and Sport consulted on the cybersecurity of connected devices (looking at the Internet of Things and increasing use of connected devices at both industry and consumer level) and is currently considering responses to separate consultations on the security of data centres and app stores. Following the connected devices consultation, a policy paper was produced in April 2021.
Final thoughts
Technology is already presenting significant opportunities in the construction sector, which is why it is a key element in the Construction Playbook. This will only develop and while the talk of smart construction contracts may be premature at this stage, the Walmart experience with its supply chain and using block chain to reduce disputed invoices provides a glimpse of the potential for construction.
The points above, however, highlight the need to understand the different risks in procuring technology and the way this affects risk allocation. All the more so for areas where risk allocation is approached differently in the tech sector.
