Credit: VTT Studio/Adobe Stock

Damian Morris
MOSO Consulting, Brisbane

Donald Charrett
Expert Determination Chambers, Melbourne

This article provides an overview of some of the key problems associated with addressing risk in technology contracts for construction and infrastructure projects. These issues are often rooted in the different risk profiles for technology versus construction projects and the tendency of construction contractors to disregard these differences and contract technology projects as though they were typical construction projects.

Introduction

The delivery and integration of technology systems is a key element of the scope of modern infrastructure and large construction projects. A toll road requires a tolling system, a railway requires a signalling system, a football stadium requires a communication system, an office building requires a building management system, and so on.

As these technology systems form an integral part of the overall infrastructure being constructed, they are generally included in the scope of the head construction contractor responsible for the design and construction of the infrastructure and are therefore procured and delivered by that head contractor. In addition to these reasons of ‘natural’ scope boundaries, there are usually compelling commercial and contractual reasons for including critical technology components of a larger infrastructure project within the scope of the overall head contractor for the project. These reasons usually boil down to ensuring that the customer has ‘a single throat to choke’. To be sure – and to stretch further our linguistic flourish – there are usually many ‘hairs’ on such an approach, but it is often also the best compromise available to the customer procuring the overall project, and is a common approach as a result.

Many of the technology systems included within the scope of a construction head contractor are commodities, available from the open market on a competitive basis, and so the associated design, implementation, commissioning, and support activities are similarly themselves commoditised. There are therefore many structural similarities between such technology systems and traditional markets for construction goods and services, and as a result they can generally be treated similarly. Experienced infrastructure head contractors are familiar with the delivery of such systems as part of their design and construction scope.

A much greater challenge is posed by those technology systems procured and delivered by an infrastructure or construction head contractor as part of a large construction project that are proprietary to a single supplier rather than commoditised, for which there is no competitive market for the complete technology system life cycle of design, implementation, and operational support services, and consequently for which suppliers, once appointed, are not easily substitutable. Many, if not most, modern infrastructure and large construction projects have a number of these specialist systems. They frequently present risks to the success of the overall project that are out of all proportion to their size relative to the overall project. Even highly experienced infrastructure and construction head contractors frequently procure and deliver these specialist systems as though they were fully commoditised technology components or even standard construction goods and services and run into myriad avoidable problems as a direct result.

By way of contrast, we are not referring to technology projects, whether specialist or commoditised, that are procured directly by their ultimate customer, other than to contrast these standalone projects with the scenarios where similar technology projects are procured by a construction head contractor as part of a larger design and construction scope of work. Direct procurement by the end customer is the normal method of delivery for a standalone technology project, and there are a myriad of great articles, books and every other type of resource available on how to procure and deliver these projects successfully (even if these principles are often ignored). It is useful, however, to explore the differences between standalone technology projects and infrastructure technology projects, what works well in both cases and what needs to be changed for construction head contractors to deliver project-critical technology projects successfully.

It is also important to differentiate between commoditised markets, where comparable products compete on price and quality and it is possible to procure functionally equivalent products competitively from multiple capable suppliers, and commoditised products, where it is possible to procure the same products competitively from multiple capable suppliers. The former includes markets for proprietary technology systems where the procurement activity is competitive but once a particular product has been selected there is only a single supplier that is capable of delivering it – and, crucially, of supporting and maintaining it once it is delivered. The global market for electronic tolling systems is a classic example of such a market. Commoditised products include markets for proprietary systems where not only the procurement activity is competitive but also once a particular product has been selected there are multiple suppliers capable of delivering it. The global market for communications networks design and implementation is a very common example of this type of market. The risks involved in successfully delivering a technology project in a commoditised market are significantly different from the delivery of a technology project comprising commoditised products; not only is the balance of bargaining power between the contracting parties fundamentally different on execution of a contract but so are the parties’ options for recovering the delivery project if it runs into serious difficulties. Similarly, the customer’s options for continuing to reliably operate a technology system for its full design life if its original supplier is no longer willing or able to support or maintain it are fundamentally different when there is only a single supplier that has the necessary expertise, not to mention the proprietary intellectual property rights that are required to actually carry out the necessary support and maintenance activities to operate the system successfully for the duration of its intended life.

Many standard approaches to dealing with the risk of technology projects involve bringing the customer and its technology contractor closer together, to establish the appropriate scope, to minimise misunderstandings and mismatched expectations, improve communication and joint ownership of the project and its intended outcomes, and ultimately speed up identification of risks and issues and optimise their resolution. This greater level of engagement and collaboration is a direct consequence of the increased level of complexity that is typical of a technology project relative to a construction or infrastructure project of similar size and value.

However, it is frequently not possible to deploy these approaches fully in an infrastructure project, and often it is not practically possible to deploy some of them at all. When contracting parties for an infrastructure project enter into a technology delivery subcontract expecting to deliver the project as they would for a standard procurement, where the technology subcontractor is directly engaged by the ultimate customer, they very quickly run into problems for which they are unprepared and often ill equipped to resolve.

As there are many different threads to this very tangled ball of twine, and exploring them all would take a book, not an article, these problems, and how to avoid them, are the subject of a forthcoming book, Technology Contracts for Infrastructure and Construction Projects, to be published by Routledge in 2024. The book explores the nature and sources of these problems, and how current approaches to the delivery of complex technology sub-projects in infrastructure and construction projects exacerbate the risks faced by their overall infrastructure projects, and consequently the risks to every stakeholder in these projects. The authors’ experience covers the complete infrastructure project lifecycle of procurement, contracting, design, delivery, operation – and dispute avoidance and ultimately resolution – of complex technology systems in very large infrastructure environments.

The good news is that, in contrast to the usual zero-sum outcomes which are so common in large construction projects, these risks can frequently be improved for all parties, without resorting to the normal construction contracting approach to risk of simply attempting to transfer it to another party. Often this requires coordination between two or even all of the affected parties, but because it frequently produces benefits for all parties the typical zero-sum commercial calculus need not apply and the largest challenges are ones of awareness, timing, and coordination, rather than raw commercial leverage. The solutions generally involve changes in the approach to the delivery of technology sub-projects when there is a construction head contractor involved, including but not limited to changes to the way these sub-projects are contracted.

This article is an overview of some of the key problems, and what you can start doing about them in your infrastructure project.

The contract: necessary, but not sufficient

The challenges facing the infrastructure sector worldwide are well known. When discussing them, a refrain to be increasingly heard from infrastructure and major projects lawyers in recent times goes something like, ‘I’m starting to think that the contract isn’t the solution!’. The almost inevitable response from construction and technology professionals that don’t make their living by preparing ever more sophisticated contracts is usually, ‘Who on Earth thought that it ever was?’

As always, reality is somewhere in between.

Modern infrastructure projects are incredibly complicated commercial, logistical, and engineering undertakings that comprise many disparate parties with similarly disparate – and frequently conflicting – objectives and constraints. Attempting to deliver such an undertaking without some form of common agreement between each party that has a significant interface with each other would be the height of folly, of each of the commercial, the logistical and the engineering kinds. As modern projects grow increasingly complex, suitably sophisticated contracts are an absolute necessity to help ensure that each party has a common, and enforceable, understanding of their mutual obligations and their expectations to and from each other.

Sophisticated and experienced project delivery experts understand, however, that there is no level of contract sophistication that will actually solve complex project delivery challenges, and to expect, or worse, rely on a contract suite as a substitute for project delivery expertise working constructively to address these challenges is to doom a project to early and likely catastrophic failure. This is only one step down from the common approach to construction contracting globally, which is to rely on construction contract suites to resolve the complex disputes which arise when the complex project delivery challenges are not successfully solved.

Suitably sophisticated contract documents are necessary, but not sufficient, for the successful procurement, delivery, and operation of complex infrastructure projects.

By the same logic, inappropriate contracting regimes can, and do, introduce unnecessary risk at all levels: technical, delivery, schedule, and cost. Addressing the mismatches between the construction contract suites commonly used to deliver complex technology sub-projects in large infrastructure projects and the actual, intrinsic risks and requirements of their underlying technology projects can directly reduce the technical, delivery, schedule, and cost risks of those projects.

Contractual frameworks, and mandatory flow-downs

Technology projects usually involve delivery of a system: a set of things (hardware and software) working together as parts of a mechanism or an interconnecting (and often variable) network, which is a complex whole. By contrast, physical infrastructure is often delivered as a set of components that only interact with each other in more limited, static and generally well-understood ways.

The technology systems we are discussing are fundamentally important to the success of their overall infrastructure project. This is most obvious where the technology system delivers the revenue stream to the infrastructure project Customer, such as in a toll road. Although less obvious, it is equally relevant for the cashflow on a social infrastructure project, such as a prison or hospital, where ProjectCo will only be entitled to full payment for services rendered if the technology system is available, fit for purpose and achieving its contractually required performance levels.

In an infrastructure project, the Customer generally enters into a design and construct contract with a construction Head Contractor that includes a requirement to build the physical infrastructure including the Technology System. Construction Head Contractors rarely have the specialist expertise and technology licences necessary to be able to deliver the Technology Systems themselves, and the intention of all the parties is that this aspect of the scope will be subcontracted to a Technology Subcontractor.

Although the Head Contractor has the task of negotiating and entering into technology subcontracts for the delivery of the required Technology Systems, the Head Contractor must work within the framework imposed by the Customer. That is because the Head Contractor’s design and construct contract with the Customer often nominates certain technology subcontracts as Key Subcontracts, meaning the Customer imposes mandatory requirements for various terms and conditions that must appear in such technology subcontracts. Such mandatory terms may also be driven by other project stakeholders, such as the Project financiers. The consent of the Customer (and the Project financiers) to proposed technology subcontracts is often also required; indeed, a tripartite agreement with financiers is sometimes a mandatory requirement. It is important for Technology Subcontractors to be aware that infrastructure Head Contractors generally do not have discretion regarding mandatory terms and must work within the framework imposed by the Customer – that is, the Head Contract and any subcontracts entered into by the Head Contractor must comply with the mandatory flow down requirements, which are often driven by the Customer’s internal and external sources of finance.

Such Technology System Subcontracts sit within a wider framework of project contracts, including long-term support agreements for the Technology Systems during the infrastructure assets’ operations phase, which may stretch decades into the future. The interaction with these other contracts is relevant to understanding the likely restrictions to a Technology Subcontractor’s ability to negotiate changes to the mandatory flow down requirements in a draft Technology System Subcontract.

Bankability

Technology Subcontractors also need to be aware of the commercial drivers at play in any infrastructure or construction project, and particularly in projects which are delivered via Public Private Partnerships (PPPs). These commercial drivers can often be traced back to bankability. They involve the fundamentally different perspectives of the project’s financiers relative to all the project’s other stakeholders with respect to risk and opportunity.

In this context, bankability refers to the infrastructure Project’s ability to support – in other words, to repay – the use of project financing to fund the build and operational phases of the Project. That is, having regard to the Project’s cashflow forecasts and the risks attaching to the Project, whether financiers can reasonably expect the Project to be able to repay the full amount of the finance it requires to construct the infrastructure, on a limited recourse basis and before the Project has any assets beyond its foundational contractual agreements. Limited recourse means the financier’s recourse is limited to the Project revenues and assets and (possibly) a capped equity contribution from the ProjectCo’s equity investors. During the design and construction phase of the Project financiers will focus on risk which may influence the start of cash flow and how a delay to the start of cash flow will affect the Project’s ability to service debt. Financiers will also want to understand how delay and poor performance may affect underlying agreements. For example, financiers will be focused on mitigation of any risk that delay may trigger termination of the agreement granting ProjectCo a 50-year concession to operate the toll road and earn a reliable revenue stream as a result.

Financiers lend against a certain project profile that has been subject to extensive due diligence and modelling. The due diligence and modelling are intended to check that the Project is sufficiently funded to ensure that in all the likely downside scenarios the Project can achieve completion and financier’s collateral will still have sufficient value, with a margin for safety. The size of the required margin for safety will directly depend on the projected risk profile of the Project. One of these likely downside scenarios involves the possibility that the Technology System is delivered late and this delays the start of the cash flow required to service the project’s debt.

It is important to bear in mind that none of the potential upsides of delivering a successful Project benefit its lenders beyond the repayment of their loans. That is, none of the benefits that result from a Project that is delivered early, or under budget, or that exceeds the contractual performance requirements accrue to its financiers. In stark contrast, the downside risk of a Project that is delivered late, or over budget, or that fails to achieve the required level of quality, can and usually does directly affect the Project’s ability to repay its financiers. As a result of this asymmetrical allocation of upside benefits versus downside risk, project financiers are focused entirely on the Project’s ability to repay its loan within their agreed terms, to the exclusion of everything else. This is a fundamentally different perspective from most of the Project’s other stakeholders, all of whom can generally benefit in some way from at least one of the potential upsides of a well-delivered project.

To secure a change to any mandatory flow down requirement (or any other requirement) in a draft Technology System Subcontract, it will be necessary for the Technology Subcontract procurement process to be entered into early enough that the prospective Technology Subcontractor(s) can review the proposed approach and put forward drafting that clearly identifies the change that is desired so the Head Contractor can seek consent from the Customer and the Customer can seek consent from the financiers.

Complexity

During the 2000s a number of significant road infrastructure projects in Australia, particularly those requiring extensive tunnels or particularly long stretches of motorway, were delivered as PPPs, often with ProjectCo taking the demand risk for traffic for the completed project. In many if not all of these projects, the development, integration and commissioning of the tolling system proved to be a substantial risk to the success of the overall project, out of all proportion to the size of the tolling system contracts relative to the overall cost of the project. As a result, tolling systems developed a well-deserved reputation for posing out-sized risk to road infrastructure projects, and in subsequent projects received extremely close attention from every major stakeholder in the project, from the state down and from the commencement of procurement all the way through until the point of successful project completion.

This additional and intense focus on tolling system risk resulted in significant improvements to the rate of success of tolling systems subcontracts through the 2010s, as each new project strove to procure recognised tolling systems, rather than ‘innovating’ (which itself became a dirty word), and then carefully avoided specifying functions or modes of operation that were outside existing, and therefore proven, functionality.

As a result, the level of development risk in most tolling systems projects in the 2010s was actively reduced to the absolute minimum necessary to deliver the project.

Software and hardware development risk is all too often not under the direct control of the project parties, as development usually takes place in specialist groups inside the vendor and usually according to a product roadmap already developed by the vendor. Although this roadmap takes into account the changing needs of the vendor’s markets, by definition it is also subject to the needs of multiple customers and projects at the same time, resulting in competition for attention that is usually solved by selecting either the loudest, nearest, or otherwise most important projects first. This is often not your project at the time when you really need it the most, and therefore adds to the risk factors for your project the risk factors for all the other projects it is currently behind in the vendor’s priority list as well.

The significant reduction of development risk, which is generally outside of the project parties’ control in any event, allowed the project parties to 2010s road infrastructure projects to focus on the integration and commissioning risks posed by their tolling systems sub-contracts, which generally are under the project parties’ control.

Several other factors which reduced the risk of tolling systems projects in the 2010s relative to the previous decade – not least being the commoditisation of computing power, data storage and communications networks’ bandwidth and latency, which resulted in the ability to solve complex software problems through the quick, simple and reliable means of simply throwing hardware at it. Nevertheless, the all-but-elimination of development risk also meant that these other improvements were less necessary to get the job done than they had previously been. This resulted in greater certainty of time and cost for all project parties, which results in improved margins for all the project contractors up the contracting chain and improved certainty of delivery for the customer that commissioned the project.

This approach to minimising or even eliminating development risk can almost always be applied more aggressively than first instincts suggest. As a customer, you are always faced with the choice of modifying the system that you’re procuring to meet the needs of your organisation or modifying your organisation to align with the way that system already operates. Sometimes this choice will be best served by modifying the system, especially if it’s core to the operation of your entire business and you have a very large business, but rarely do you not have the choice of choosing a more optimum point on this spectrum, at least from a risk perspective.

Intellectual property

Because all modern Technology Systems comprise critical components and sub-systems that are provided by global third parties who are not willing to accept infrastructure-style risk allocations, it is unlikely that the standard intellectual property rights provisions that govern the rest of an infrastructure project will be effective if applied unchanged to its Technology Subcontracts. Ensuring that there is an intellectual property rights regime for key Technology Subcontracts, that is successfully and effectively aligned from the Project Deed all the way down to those key subcontracts, is an effective way of ensuring that the Project stakeholders really do receive both the rights and the obligations that they require to complete the asset and then operate it over its lifetime.

Time

Another powerful mitigant to technology delivery risk is simply time. It is employed by scheduling the project activities such that the delivery team has the greatest possible chance of uncovering issues as early as possible, so that they can be resolved in time to complete the Project by the contracted dates. Technology delivery teams understand this intimately, and a mature Technology Project delivery team’s schedule will invariably reflect it. Conversely, one of the greatest risks to the successful delivery of a Technology Subcontract in an infrastructure project is frequently the Head Construction Contractor’s disregard of that schedule, and the consequent creation of delay risk where none previously existed. Of all the risks discussed in this article, this is the easiest for the Head Contractor to solve. It is also the most difficult for the Technology Subcontractor to manage.

Market power

Construction Contractors inherently work with and deliver physical inputs and outputs, and consequently are almost always local, even when they form part of a much larger regional or global organisation. Technology Contractors, on the other hand, work largely with digital inputs and outputs, and as a result are able to deliver their goods and services to Customers worldwide; often, their only local resources, if any, are their sales teams. Technology Contractors and Subcontractors frequently have a correspondingly less parochial outlook than Construction Contractors.

One of the most fundamental differences to customers arising from these different postures is the need for Construction Contractors to work within the constraints of their local markets – that is, to be willing to accept market-standard contractual arrangements when they are not able to negotiate a better outcome.

By contrast, Technology Subcontractors are far more able and willing to mandate contractual arrangements on a largely ‘take it or leave it’ basis, as they are able to enter and leave local markets according to whether those markets align with the Technology Subcontractor’s preferred risk profile far more easily than Construction Contractors. The extent to which a Technology Subcontractor delivers a digital product that can be delivered remotely (eg, a cloud project management software service) as opposed to a human service that must be delivered locally (eg, the integration of such a project management system into a customer organisation) directly affects their power in this regard.

Today, almost every Technology System is itself built on complex third-party sub-systems, which are often themselves also provided by global suppliers. This results in limited opportunity to control the direction of feature development, not to mention the correction of defects, in the myriad third-party sub-systems that Technology Projects depend on. This similarly often limits the opportunity for customising those sub-systems to the extent necessary to fully meet the Customer’s specific requirements for any given Project, and it almost always completely eliminates any opportunity to pass down risk and/or liability to the third-party provider.

Integration

Technology Projects often involve the integration of multiple discrete systems, each of which has been designed and developed individually and without regard to the specific other systems with which the Project requires that they integrate. Usually, some of the systems are being delivered through the Project, and some are existing systems with which the new ones must integrate. This divide alone can create complicated interactions of responsibility (which sits with the parties responsible for delivering the Project) versus capability (which exists only in the third parties with the capability to make the necessary amendments to the existing systems), further complicating the overall project risk profile.

These factors lead to very high levels of interface points – and consequently requirements for integration – in Technology Projects, even before external interfaces are considered. By contrast, although the number of interfaces in a typical construction scope may be similarly large, they use standard interface specifications and protocols, such as those found in every construction project’s Issued for Construction drawings. The technology sphere innovates far too quickly, and product cycles are far too short, for more than a tiny subset of interface points to become industry-wide standards. Indeed, technology vendors often deliberately avoid standardising interface points, unless the standard that is accepted is that vendor’s own specification, as a key plank in the tech market’s infamous ‘vendor lock-in’ market acquisition and protection strategy.

As a result of these factors, design, delivery and integration of bespoke systems requires a level of verification, and subsequent defect identification, analysis and correction, which is not normal in well-delivered construction projects but common even in successful Technology Projects. The ‘V’-model of systems engineering is widely used in successful Technology Projects and is an approach that can also help tackle the increasing complexity of construction and infrastructure projects.

These differences in complexity result in dramatic differences in the respective risk profiles of technology and construction projects, and drive significant differences in how their risks are, or should be, treated. Risk mitigation strategies that are frequently used to manage construction risk effectively can be futile when applied to risks commonly encountered in the delivery of Technology Systems. Attempts to use traditional construction D&C contract risk allocations and mitigations to manage the technology risks in a construction project, often result not only in an inefficient risk allocation but also an ineffective one.

Practical completion and defects

In an infrastructure project Completion is binary. The infrastructure asset is either complete, in the sense that it meets the prescribed specifications, or it is not. In a Technology Project Completion can be much more elusive for a number of reasons. A first point of departure is that the specifications in an infrastructure project remain largely static, whereas in a Technology Project they can remain in flux and evolve considerably over time as the Technology System is developed to fit the Project, on the one hand, and the Customer understands the implications of its own requirements and adjusts them accordingly, on the other hand. Completion as it’s contemplated on signing of the contract is very likely not to be the same as Completion in its eventual form in a Technology Project.

Extensive use of globalised, third-party components contributes to both these challenges: the first, to correct defects in third-party components; the second, to respond to end-of-life and other major changes in direction in those third-party components which in turn necessitate updates to the primary first-party deliverables.

Bridging these very different sets of expectations requires a general understanding of the demands and limitations operating on each side and developing concepts of Completion which cater for the rigor required by infrastructure projects while maintaining the commercial and practical flexibility demanded by the technology component of the project.

Operations and maintenance versus support and maintenance

The ongoing operation and maintenance of a Technology System often requires more active maintenance than construction professionals anticipate, not least because it often requires many more specialised skills and external organisations, and because technology product and service obsolescence cycles are considerably shorter than for infrastructure assets. Accordingly, the support and maintenance of a Technology System has very different considerations from the operations and maintenance of physical infrastructure.

Although the operations and maintenance of infrastructure are often contracted separately, it is also common for them to be contracted as a combined scope to an Operations and Maintenance (O&M) Contractor. This is in large part because there is a large market of service providers offering both operations and maintenance capability and capacity, and there are efficiencies in both cost and quality of outcome to be had by contracting both to the same service provider. O&M Contractors are specialists in subcontracting the disparate skills (and capacity) to deliver the broad operations and maintenance scope for a large infrastructure asset.

In contrast, the operation of specialist technology systems is more commonly contracted separately from their support and maintenance, as the former can be contracted to more commodity suppliers whilst the latter often requires specialist expertise. The market for specialist expertise is both more limited in capacity and more expensive in offerings, and consequently better value for the Customer can often be obtained by contracting them separately. Indeed, the support and maintenance of specialist technology systems often requires proprietary knowledge and expertise that the supplier of the system does not licence to any other service provider, limiting the market for support and maintenance service providers for that system to only that supplier.

Conclusion

This article provides an outline of how to procure and successfully deliver complicated, project-critical Technology Systems from specialist Technology Sub-contractors, within the scope of infrastructure and construction projects. It explores common issues which contracting parties run into, and how to minimise or even avoid them. It is about how infrastructure customers, construction head contractors, and technology sub-contractors can reduce the risk on their projects and deliver the complex technology systems required by today’s infrastructure projects on time, with lower risk, higher quality, and lower overall cost.

Damian Morris is a specialist in the contracting and delivery of critical technology components of infrastructure projects, and Director of MOSO Consulting in Brisbane. Damian can be contacted at damian@moso.com.au. Donald Charrett is Arbitrator, Expert Determiner, Mediator and Dispute Board Member at Expert Determination Chambers in Melbourne and can be contacted at d.charrett@me.com.