Summary: The Digital Railway Programme is addressing many of the technical and operational challenges that its national programme will need to overcome. In Parts 1 and 2 of this article we seek to contribute to this strategic dialogue by highlighting specific contractual challenges the programme will need to consider and putting forward our own solutions.
Our Digital Railway Series
In our last article, we considered some of the specific challenges, which are contractual in nature, which the Digital Railway Programme is likely to be considering. This included issues to do with the contract model to be used as the starting point, how to align goals and incentives between Delivery Owners (the preferred delivery model is to break down the systems integration work per route into a series of projects, each having its own Delivery Owner) and how to avoid supplier lock-in over the 40 year duration of the operating life of this technology.
How to avoid transactional contracts?
One of the stated goals of the Digital Railway Programme is to avoid the problems caused by taking a transactional approach to suppliers by taking a more collaborative approach with suppliers. The goal has already been put into practice through the Early Contractor Involvement (ECI) workstream, designed to engage the industry in as collaborative and effective a way as possible. The Digital Railway Programme’s stated aim of involving suppliers in writing a national digital railway specification indicates another step in this collaborative direction. At that point however, collaboration may need to give way to more transactional contracts in order to develop and deploy this critical infrastructure on time and to budget. True collaboration would involve an equal sharing of risk and reward which, given what is at stake, we do not think is realistic or workable. So downstream contracts for the development, deployment and maintenance of digital railway technology and infrastructure are likely to be quasi-collaborative / quasi-transactional.
NEC3 Contract Model
It is in the context of avoiding transactional contracts that the NEC3 suite of contracts has been referred to as the most appropriate starting point to reflect this principle of co-operation. All NEC3 contracts contain as a fundamental requirement that the parties agree to “act in a spirit of mutual trust and co-operation” (NEC3 clause 10.1). Where a Digital Railway project involves the deployment of technologies onto physical infrastructure e.g. track side detection systems, using this form of contract should be workable as this type of project can be documented using construction concepts. However for projects which are purely technology implementation projects with no (or limited) physical infrastructure elements e.g. the deployment of traffic management systems at rail operating centres, the case for using a construction contract as the starting point appears less credible.
Collaboration between Delivery Owners and Supply Chain
In Part 1 of How to best contract for the Digital Railway we explained that Delivery Owners within a route will have dependencies on multiple third parties (including its supply chain) AND also that Delivery Owners within a route will have dependencies on other Delivery Owners within the same route. The NEC3 contracts provide for the former situation by allowing Project Owners (or “Employers” in NEC3 language) to include optional “Alliancing” clauses in each contract it enters into with its contractors (or “Alliance Partners” in NEC3 language). These “Alliancing” clauses are designed to create shared outcomes between all contractors, through a shared governance structure, shared incentives and the sharing of risks.
However, these optional “Alliancing” clauses do not deal with the scenario where Delivery Owners have dependencies on other Delivery Owners within a route. In this scenario, there is more than one “Employer” (to use NEC3 language). What is likely to be needed in this scenario is an “Alliance Agreement” between each of the Delivery Owners where each one agrees to achieving the required outcome of successfully delivering digital railway technologies within that route, by successfully delivering its project and co-operating fully with other Delivery Owners to enable them to deliver their projects. These principles would then be backed up by a shared incentive and shared risk model. This could take the form of financial incentives for each Delivery Owner if digital railway technologies are all successfully delivered within a route and within budget. A shared risk model involving the sharing of budget overruns incurred by one or more Delivery Partners, although theoretically possible, is unlikely to be commercially viable without a cap on the level of risk a Delivery Partner is willing to take. Setting the right level of risk and reward will therefore be crucial if an Alliance Agreement is chosen as the mechanism for delivering inter-Delivery Owner collaboration.
Whole life risks
In Part 1 of How to best contract for the Digital Railway we explained that there will be a dependency on each supplier not only to maintain their technology but also to have the capabilities to upgrade their technology (i.e. from ETCS Level 2 to ETCS Level 3) over the operating life of the technology (estimated to be 40 years in some cases).
In technology contracts, supplier lock-in can be a serious challenge for customers. The inability to support and maintain a supplier’s proprietary intellectual property and the costs and disruption involved in migrating to another supplier are the typical barriers which create supplier-lock in. In technology contracts, the traditional way of overcoming this is by requiring a supplier to place the source code (the source code is the human readable version of the computer program) to its computer programmes into an escrow arrangement, with the source code continually updated as changes are made to the programme and the source code being made available to the customer on certain escrow release events.
However there are limits to how practical this is. Depending on the complexity of the programme, access to the source code is unlikely to enable continuity of service without potential disruption due to the time it would take for programmers to understand the source code. As Digital Railway technologies will be part of the country’s critical national infrastructure, the stakes could not be higher.
To overcome this, there should also be a continual process of knowledge transfer between suppliers and the Delivery Owner on operational matters relating to the technology, such as the technology infrastructure required to run the technology, critical or serious faults that occur in the computer programmes and how they were resolved. In addition to access to the source code on the occurrence of an escrow release event, a Delivery Owner should also have the ability to employ key staff who operated the computer programmes for the supplier, to ensure continuity of skills and capability. The stakes may be high enough to even consider creating a pooled set of resources, employed by the customer, but to whom the know-how required to support, maintain and upgrade this technology is transferred by each supplier, provided appropriate protections are given to each supplier that their intellectual property rights will not be exploited outside of that route. Suppliers will need to make substantial investments in infrastructure and capability to support their technology over its operating life so customer protections in this area must avoid tipping the scales away from a commercial viable model for suppliers.