Credit: Кирилл Рыжов/Adobe Stock

Rupert Sydenham*
Hogan Lovells International, London

Annie Lund
Hogan Lovells International, London

Emma Ball
Hogan Lovells International, London

Over the past decade, we have all seen an increase in the presence of digital technology in and around construction sites. Contractors are increasingly using digital technology to carry out their works, for example through the use of online platforms to manage contracts, robots to monitor progress and digital twins to model and record the as-built works.

But there is a more significant technological change on the horizon for the construction sector. Industry commentators are heralding the arrival of so-called ‘Smart Infrastructure’. Examples include a recent University of Cambridge report titled Smart Infrastructure: getting more from strategic assets, in which the term ‘Smart Infrastructure’ is defined as ‘the result of combining physical infrastructure with digital infrastructure, providing improved information to enable better decision making, faster and cheaper’.

If these commentators are correct, Smart Infrastructure will mean more digital technology not just in and around construction sites, but within the as-built works themselves. Contractors will not only be constructing physical infrastructure, but digital infrastructure as well: sensors and other pieces of digital technology will be built into facilities, creating an internet of things whose data can be monitored to improve operation of the physical asset, all being monitored and controlled through software.

It therefore seems likely that in the years ahead, employers will increasingly be looking to contractors to engineer, procure and construct both physical and digital infrastructure under the same contract, to build the Smart Infrastructure (both the hardware and software) of the future.

This raises the question: are our current standard form construction contracts fit for the Smart Infrastructure of the future, and if not, how should they be adapted?

We are conscious that we are still in the foothills of this debate. The analysis in this article focuses primarily on how a small number of provisions of the FIDIC Yellow Book 2017 (FIDIC Yellow Book) may need to be adapted based on our review of a selection of large IT outsourcing contracts and IT systems implementation contracts, but it could apply equally, in whole or in part, to other standard form construction contracts. We therefore hope our analysis will spark further debate as to how construction contracts more generally should adapt to keep pace with the technological change in our industry and become fit for the future.

Are current standard form construction contracts fit for Smart Infrastructure?

In our view, the answer is no. As we see it, including digital infrastructure within physical infrastructure to build a piece of Smart Infrastructure is likely to enhance the risk profile of the project in three respects. We will look at each of these respects, which we refer to as: (1) enhanced collaboration risk; (2) enhanced time and cost risk; and (3) enhanced business continuity risk.

Enhanced collaboration risk

We believe that a Smart Infrastructure project has enhanced collaboration risk because, in essence, it is likely to require more collaboration between the employer and the contractor than a physical infrastructure-only project.

Physical infrastructure projects already involve a significant degree of collaboration between employers and contractors, in particular at the beginning and end of the project. Employers spend time developing their requirements and collaborating with potential bidders to explain their requirements to them. Bidders and the eventual contractor then spend time producing increasingly detailed design drawings to meet those requirements and collaborating with the employer or its consultants to have them approved. Both the employer or its consultants and the contractor also collaborate considerably during the handover, testing and acceptance process.

Even despite these processes being in place, collaboration risk of course still manifests itself in physical infrastructure projects. The employer’s requirements may prove to be incomplete, or the contractor’s designs inadequate.

However, adding digital infrastructure arguably heightens the collaboration risk further.

In a project involving both physical and digital infrastructure, both have to be specified and designed. While it may seem that these two processes could be combined and the associated risks could be managed together, it may not be that simple.

In our observation, the development of digital infrastructure, both hardware and software, is often more iterative than the development of physical infrastructure. It is therefore likely to require more hands-on involvement from the employer consistently throughout the course of the project than a physical infrastructure project. The employer’s end users of the infrastructure are likely to need to be in frequent communication with the contractor’s team not only at the outset of the project to specify their requirements and during the testing and acceptance process, as is normal for a physical infrastructure project, but also for longer periods during the design development process, to ensure the functionality of the digital infrastructure develops in accordance with their requirements. The collaboration involved in capturing and designing software requirements are notoriously difficult to manage. Many large-scale software-only contracts go wrong and suffer from significant delay, and there is no reason to suppose that this would be less likely to happen if a large-scale software project was proceeding as an integral part of a Smart Infrastructure project. The added complexity is more likely to exacerbate the usual difficulties.

Accordingly, there is an enhanced risk that a failure to communicate and collaborate adequately between the employer and contractor leads to changes to the contractor’s scope of work when building Smart Infrastructure as compared to physical infrastructure-only projects and enhanced risk of delay or derailment owing to the software elements of a Smart Infrastructure project.

Enhanced cost/time risk

Estimating the effort and time required for software projects is notoriously difficult. We therefore understand that, when the construction industry is at the ‘bleeding edge’ of implementing Smart Infrastructure projects, estimating the costs and time implications of any proposed changes to the contractor’s scope of works will be similarly difficult.

Physical infrastructure-only projects are of course prone to delays and cost overruns as a result of the employer’s requirements changing over time, or the contractor not having taken into account all of the employer’s requirements in its designs.

However, in a physical infrastructure-only project, the employer (or its consultants) and the contractor are perhaps both likely to have experience of the parts of a physical infrastructure project liable to delay. They are therefore also likely to have a feel for the time and cost consequences associated with the engineering being deployed and any changes to the contractor’s scope of works made during the course of the project.

However, we consider that, in particular when parties are breaking new ground in the deployment of digital infrastructure within physical infrastructure, the employer and contractor may struggle to assess the extent of delay, disruption and cost overruns associated with making a particular change to the digital infrastructure. This may be an oversimplification but, to put it bluntly, parties may for a while yet be better at assessing the impact of reconfiguring a building or plant layout than adding extra functionality to a piece of hardware or software.

We therefore think that there is likely to be an enhanced risk of unforeseen cost and time overruns on projects to construct Smart Infrastructure.

Enhanced project continuity risk

We also think that Smart Infrastructure projects are more susceptible to project continuity risk, because of the nature of the infrastructure being developed.

A key project continuity risk associated with a physical infrastructure project is what happens after termination. In that scenario, the employer may find it difficult to engage a replacement contractor willing to pick up where the previous contractor left off, unless the employer pays a premium or takes the risk of the previous contractor’s work. Sometimes, it is not possible to find a replacement contractor at all.

However, we foresee added difficulties for employers trying to find a replacement contractor for a project involving the development of both physical and digital infrastructure.

Imagine if an employer were to terminate its contract with its contractor and find itself left with a half built piece of Smart Infrastructure. In that scenario, the employer might not be able to find a replacement contractor to complete its project not for the reasons outlined above, but because no contractor would be able or willing to continue developing a rival’s digital technology over its own. This could be because the potential replacement contractor is not permitted to access the rival contractor’s source code, is not given sufficient rights to use its rival’s intellectual property (IP), or refuses to implement any digital infrastructure except its own proprietary technology. Alternatively, it may be that no contractor is prepared to take on the risk of finishing another contractor’s partially documented and incomplete software work-in-progress.

While a replacement contractor may be reluctant to adopt an existing set of design drawings to complete a physical infrastructure-only project, the additional complexities associated with software development in particular create a comparatively greater project continuity risk for Smart Infrastructure projects.

In our view, therefore, an important reason why the current standard form construction contracts are probably not fit for the Smart Infrastructure of the future is that they do not take into account these changes to the contracting risk profile for such projects.

How should standard form construction contracts be adapted?

In light of the three areas of enhanced risk outlined above, it seems to us that there are three key areas in which the provisions of the standard form construction contracts may need to be adapted to deal with the increased presence of digital infrastructure in infrastructure projects. These are: (1) the role of the engineer; (2) the change control mechanism; and (3) the use of IP.

In the analysis below, we discuss our preliminary views as to the ways in which these provisions could be adapted. The starting point for our discussion in each case is a comparative analysis of the relevant provisions of the FIDIC Yellow Book and the equivalent provisions commonly found in large IT outsourcing contracts, or IT systems implementation contracts. In our analysis below
we use the term ‘IT contract’. As there are no standard forms for such contracts, this phrase is necessarily a generalisation.

The role of the engineer

In the FIDIC Yellow Book, it is the engineer, as the agent of the employer, who has the key role in the management and implementation of the contract. The role of the contractor’s representative exists pursuant to Sub-Clause 4.3, but its incumbent does not have powers equivalent to those of the engineer. While the engineer and the contractor’s representative can each require the other to attend a management meeting under Sub-Clause 3.8, this is the extent of the parties’ contractual obligations to be met.

By contrast, IT contracts tend not to have a role equivalent to the FIDIC Yellow Book engineer. Instead, they commonly prescribe a more detailed contract management system comprising a hierarchy of boards and committees, each made up of representatives from both parties. A common approach is to have a three-tier governance structure: an executive management board, a management board and then an operational board which is split into different sub-committees according to the specific needs of the project.

In addition, IT contracts often envisage both parties appointing a programme manager. These individuals’ primary purpose is to facilitate communication between the parties. While they may have some delegated authority to make decisions, more authority is held by the executive management board.

It therefore seems clear that IT contracts tend to provide for a more complicated and collaborative approach to project management. Contracts have a greater focus on the parties discussing progress and making decisions together rather than giving the ultimate decision-making authority to a third party engineer, who under the FIDIC Yellow Book either exercises his authority independently or neutrally (as eg, when seeking agreement or making a determination under Sub-Clause 3.7) or otherwise is deemed to act for the employer.

The difference in approach between the FIDIC Yellow Book and IT contracts could simply reflect the historical origins of the two types of contract, including the fact that IT contracts are more likely to have been negotiated in a supplier friendly environment. And of course while there is no more than a suggestion, as opposed to an obligation, to have a planned timetable of meetings in Sub-Clause 3.8 of the FIDIC Yellow Book, parties to FIDIC Yellow Book contracts do of course typically meet to discuss progress.

However, another possible explanation for the difference is that the work done under IT contracts requires a more collaborative approach to project management and decision-making than that done under construction contracts. For example, the development of digital technology may be more iterative and therefore require more ongoing collaboration to ensure that the technology (and particularly software functionality) meets the employer’s requirements than a standard construction project suited to a FIDIC Yellow Book. Indeed, as described above, a key risk which faces parties when implementing an IT project is collaboration risk: the potential for a mismatch between the employer’s expectations and the contractor’s work product due to poor communication and collaboration between the parties.

Accordingly, it may be appropriate that IT contracts provide for more significant and structured cooperation between the parties than envisaged under the FIDIC Yellow Book, in order precisely to try to avoid or mitigate this risk.

This raises the question: should the management structures of IT contracts be incorporated into the FIDIC Yellow Book in the future?

It is hard to imagine that all employers would be willing to forgo having an engineer. Done well, the role of the engineer can help ensure that the contractor’s progress with the works does not get overly delayed by discussions and disagreement between the parties.

However, the role of the engineer as currently provided for in the FIDIC Yellow Book may not be so appropriate, as more and more digital infrastructure is incorporated into the contractor’s works. It may be that the parties need to have a more detailed discussion between themselves as to the employer’s requirements as solutions evolve through iteration, or it may be that the engineer simply lacks the technical expertise to make an appropriate determination. This latter problem could in principle be resolved by engaging a panel of engineers of different technical disciplines and/or specifying that the engineer should have certain IT qualifications. However, that in turn could cause governance difficulties and would in any event not resolve the question of whether the certifying engineer is an appropriate model for a software project.

Perhaps, therefore, the FIDIC Yellow Book of the future will provide for a hybrid system consisting of both the engineer and a hierarchy of management boards and committees, to facilitate collaborative working between the parties in the areas where it is required, while retaining a strong decision-making figure to administer the works overall.

Change control mechanisms

In Clause 13 of the FIDIC Yellow Book, the engineer holds the key role in the change control or variation mechanisms. It is usually only the engineer who can initiate the variation procedure. Under Sub-Clause 13.3, this can either be by direct instruction or by first requesting a proposal from the contractor describing the practical consequences of such a variation. The contractor is then only able to object on the basis of a few specified grounds in Sub-Clause 13.1 and through provision of a notice.

By contrast however, IT contracts tend to have more flexible change control provisions. The change control procedure can usually be initiated by either party and it may even provide that one party’s change can proceed only with the other party’s consent (even when initiated by the employer or purchaser), with occasional stipulations that this consent should not be unreasonably withheld. The hierarchy of management boards and committees described above enables changes to be discussed and approved at whichever level has the relevant specialist knowledge.

In addition, there is also usually scope for the change control process to be expedited. For example, in situations such as when a systemic weakness is identified or a data breach occurs, it is common for IT contracts to provide for there to be a fast-track system for changes.

Again, it is clear that IT contracts tend to favour a balanced and collaborative approach between the parties, as opposed to the more employer-friendly and engineer-led provisions of the FIDIC Yellow Book.

A possible explanation for this difference could again be IT contracts having developed in a more supplier-friendly market.

But again, the difference may instead reflect the specific needs of a digital technology implementation project. The approach adopted in IT contracts may be appropriate when contractors and employers are at the very forefront of deploying digital infrastructure within physical infrastructure. As referred to above, it may be that in these scenarios, both the employer and perhaps even the contractor may lack the experience or knowledge to analyse the feasibility and the disruption consequences of a specific change. Or it may prove to be the case that the employer’s requested change relates to part of the digital infrastructure which the contractor procures from a third party and which it is impossible or disproportionately costly and/or disruptive for the contractor to change.

A change instructed through the standard FIDIC Yellow Book approach in these circumstances, without giving the contractor the chance to discuss it in detail with the employer, may therefore lead to enhanced time and cost risk. As we all know from traditional infrastructure projects, poorly managed changes can lead to a rapid deterioration of the employer-contractor relationship or, in extreme scenarios, its permanent breakdown.

This, again raises the question: should the FIDIC Yellow Book incorporate the more collaborative and balanced change control provisions commonly seen in IT contracts?

The current system in FIDIC Yellow Book enables the employer to drive forward their agenda with minimal scope for resistance from the contractor. Those on the employer side may therefore be hostile to amendments which weaken its position in this regard. They may also argue that contractors in physical infrastructure projects can also underestimate the time and cost implication of changes, but that is a risk borne by the contractor nevertheless and that should also remain the position for Smart Infrastructure projects.

Nevertheless, perhaps employers will have to retreat from this position somewhat for the purposes of Smart Infrastructure. First, it seems eminently sensible to permit a fast-track change management process in the kinds of emergency security issues referred to above. Second, in the short term at least, contractors who can build Smart Infrastructure may have good arguments to insist on a different approach to change management, one in which the employer and the contractor share the risk associated with the implementation of new technologies for the reasons set out above. Contractors may have the bargaining power too, due to the specialist nature of their services, to insist on a more collaborative and balanced approach to change control.

The use of IP

In the FIDIC Yellow Book, provisions relating to the use of IP are brief, with just a couple of general provisions relating to the matter, primarily in Sub-Clauses 1.10 and 1.11. While Sub-Clause 1.10 of the FIDIC Yellow Book describes the IP licence as being ‘transferable’, no restrictions on this transfer are given. The notes on special provisions for Sub-Clause 1.10 in the FIDIC Yellow Book acknowledge that additional assignment provisions could be required but no template wording is provided and the IP-related indemnities in Sub-Clause 17.3 are relatively uncomplicated. By contrast, but perhaps unsurprisingly, IT contracts contain a much more comprehensive set of provisions relating to IP.

The approach to the treatment of IP is more nuanced and there are frequent attempts to distinguish between different forms of IP such as between that held by the parties before the contract and that developed for the purposes of the project; and there is often a need to distinguish between contractor-owned IP and third party IP that has been licensed in, and a need to consider risks associated with IP infringement actions and open source software. Comprehensive clauses on assignment, transfer and sub-licensing of IP are also very common.

Control over IP in a termination scenario is further provided for by the existence of ‘deliver-up’ provisions in most IT contracts. These clauses compel the IT supplier to ‘deliver up’ its source code to its customer when leaving the project in certain conditions, enabling the employer to continue to use the source code after termination.

IP is clearly more rigorously provided for in IT contracts than in the FIDIC Yellow Book. However, it seems just as clear to us that the FIDIC Yellow Book of the future should contain a more comprehensive set of IP provisions similar to those found in IT contracts.

The light-touch IP provisions of the FIDIC Yellow Book may have been sufficient until
now. But the introduction of digital infrastructure surely necessitates consideration being given to their development.

Just as in IT contracts, it seems inevitable that Smart Infrastructure projects will involve the collaborative development of digital technologies and, consequently, blurred lines of ownership between the employer and contractor. Accordingly, without contractual provisions delineating which IP which belongs to the contractor and the employer respectively, the parties are likely to end up in a dispute over ownership and use.

Similarly, without appropriate ‘deliver-up’ provisions in the contract, an employer terminating a Smart Infrastructure contract could be left with a system which it is unable to understand, operate or salvage. As discussed above, this poses a considerable business continuity risk to the employer.

While an immediate and wholesale incorporation of the IP provisions commonly found in IT contracts into the FIDIC Yellow Book may be excessive, the size of the discrepancy between the provisions in the two contracts should surely be narrowed. Any lacuna could of course be filled by bespoke amendments, but it seems sensible to us that, at the very least, provisions relating to IP ownership and the delivery up of source code should be considered for the FIDIC Yellow Book of the future, to reduce the time and cost parties expend on negotiations.

Conclusion

This article set out to consider whether our current standard form construction contracts are fit for the Smart Infrastructure of the future, and if not, how they should be adapted. We have done this by reference to a relatively small subset of provisions within the FIDIC Yellow Book. In addition to the provisions discussed, there are many other provisions which are ripe for similar analysis, such as those relating to payment, termination, the standard of performance and warranties. As stated above, however, the analysis in this article is intended merely as the start, rather than the end, of discussion about how the construction industry’s contracts need to adapt to cope with ever increasing computer software and hardware content within our infrastructure.

In many circumstances, the standard form construction contracts may be adequate, especially with the addition of carefully considered particular conditions. However, as the technology content of infrastructure increases, that approach is unlikely to be the best solution, and perhaps not a satisfactory one. Even if historically the provisions of IT contracts and construction contracts have developed relatively independently, the increasing inclusion of technology, both software and hardware, in construction projects seems to be forcing these two worlds to collide. The approach that has evolved in one world is not optimised for the other. Therefore, to avoid fallout from the collision, compromise and assimilation seem advisable.

Note

* The authors would like to express our gratitude to Matthew Lavy of 4 Pump Court for casting his eye over a draft of this article.