Out-Law Analysis | 02 Mar 2020 | 12:55 pm | 5 min. read
Getting the approach right, and addressing concerns around cybersecurity, can help infrastructure owners, operators, developers and contractors overcome some of the barriers we have found are holding the sector back from embracing new technology at the moment.
Pinsent Masons' recent global infrastructure survey found that a lack of understanding of technology is the greatest barrier to the digital transformation in the infrastructure sector.
The survey, which gathered the views of consultants and contractors, as well as asset owners, developers, investors and funders, based in major infrastructure markets around the world, also identified that a traditional approach to technology that is not joined up is holding the infrastructure sector back.
A fifth of respondents also listed concerns about cybersecurity and other security concerns as a barrier to the adoption of technology in the infrastructure sector.
Embracing technology and navigating legal and regulatory issues around its use are topics that are addressed in a comprehensive new guide developed by Pinsent Masons. The 'Joint Ventures: Delivering Global Mega Infrastructure Projects' guide looks to help businesses deliver global mega infrastructure projects more efficiently and effectively through joint venture arrangements.
One major difference we have identified between the construction and technology sectors is in their approaches to project management. The construction sector generally uses a traditional 'waterfall' approach, whereas technology firms – particularly in the software space – are more accustomed to an 'agile' approach.
A 'waterfall' approach is instantly familiar to any construction or EPC project manager. A project is broken down into sequential stages, where output from one phase feeds into the next. For example, under an EPC project, the first stage will consist of the employer writing the requirements or specifications for the projects – which the contractor will take to the next stage and produce a design. Once a design is finalised, the third stage – construction – can commence. And once construction is completed, the fourth stage – testing – can then begin. Each stage is dependent on and influenced by the previous.
An agile approach, by contrast, is more familiar to the technology sector. Instead of organising a project by large, sequential stages, an agile approach seeks to break projects down into small, quick iterations which can usually be completed in weeks. These iterations contain a full loop of designing, constructing – or coding– and testing, and the 'loop' is completed over and over again during the course of a project. The benefits are that being iterative allows almost continuous testing and extremely quick feedback, so that any problems – or even necessary variations to the project specifications – are identified quickly and implemented as early as possible with minimal cost.
For example, an EPC contractor looking to subcontract some works to a technology company may consider using frequent testing not merely as a tool for enforcing contractual compliance but also as a tool for generating feedback and actionable information. Likewise, a technology company entering a construction site might note the priority of time and cost certainty in construction, leading to the more extensive use of Gantt charts and critical path analysis as well as a less iterative approach.
There is a sometimes spirited debate amongst technology lawyers on whether a software development agreement should be considered a sale of goods agreement or a services agreement. In our experience, this ambiguity can be a source of confusion for the infrastructure and technology sectors as they attempt to choose a form of contract. When, for example, a contractor attempts to engage a technology company for a project, it is not unheard of for contractors to treat the technology company as a subcontractor and reach for a familiar form of subcontract.
Whilst this approach is appropriate in some circumstances, it does not always work.
Technology offerings are diverse, and can, depending on what they are, be comparable to a sale of goods agreement, a services agreement, a consultancy agreement, a licensing agreement, or even a combination of the above. A technology offering that is software-based, for example, may be an awkward fit for a standard construction subcontract – not least because the provisions as to programme can become irrelevant, while the appropriate warranties for the software are missing.
The same is also true of hardware offerings. Some hardware – such as the supply and installation of pre-fab units – may fit into the framework of traditional construction subcontracts relatively well. However, hardware that is designed to collect site information – for example, sensors – sometimes do not rely heavily on the use of programmes as they are designed to function continuously, and require additional attention to service levels and uptime if they come with a cloud-based component for analysing the information collected.
The selection of an appropriate form of contract in the first place is therefore important for minimising transactional costs and ensuring a speedy and efficient negotiation. We recommend that parties consider this issue at the beginning of any collaboration between the infrastructure and technology sectors.
As our survey found, the issue of cybersecurity is a significant concern for businesses in the infrastructure sector that are looking to embrace new technology. This is prudent, as cybersecurity should undoubtedly be one of the top priorities of any organisation, regardless of what sector they operate in.
It can also be difficult to navigate the plethora of data protection laws around the world. Frameworks include the EU’s General Data Protection Regulation, Hong Kong’s Personal Data (Privacy) Ordinance and China’s Cybersecurity Law, and some of the laws have extraterritorial application.
Data protection laws are usually applicable where there is collection of personal data specifically – China's Cybersecurity Law could be an exception to this – and not just any information. Records that deal only with plant and material, for example, do not involve personal data if they do not identify any persons in the records. As such, subject to the specifics of each project and the data that is being collected, not all applications of data in the construction sector necessarily attracts the application of data protection laws.
Where personal data has the potential to be collected on a large-scale - for example in infrastructure operations and maintenance contracts – there may also be methods to anonymise and aggregate the personal data by design so that it is only processed minimally, if at all. This is good practice in any event and can contribute towards decreasing the likelihood and impact of a data breach.
Cybersecurity is a matter of risk allocation as well as compliance. A contractor may well wish to seek assistance from a technology company and allocate some responsibilities to them for dealing with cybersecurity matters – after all, the Abrahamson principles suggest that a party most able to manage a risk should be the party to bear it, and cybersecurity is often within the domain and expertise of technology companies. This can be done, for example, via the inclusion of detailed data processing provisions in a contract. Such provisions, whilst rarely seen in construction contracts, are reasonably common in technology contracts.
Cybersecurity and data protection are complex topics. How best to address them is dependant on the facts of each case. Solutions for each project can be tailored to ensure personal data is used minimally, sensibly and legally.
Although there remain barriers to the digital transformation of infrastructure, they are not as monolithic as they seem and solutions are within reach.
Innovation is not simply a matter of introducing new technologies. It also includes new ways of working and thinking, and writing contracts and managing projects too, which help us do things better.