Our Digital Railway Series
In our first article, we wrote about the momentum that the Digital Railway Programme (a cross-industry group) was creating, with £450 million of funding being made available by the Chancellor towards trialling the technology and big opportunities for the supply chain in expected work packages, and through involvement in the Early Contractor Involvement workstream.
Our last article also discussed the many challenges that such a national technology and infrastructure programme would need to take account of. Many of these challenges are technical and operational, and are being addressed by the Digital Railway Programme. As technology and infrastructure legal specialists, we are seeking to contribute to this ongoing strategic dialogue by highlighting in this article some of the contractual challenges that the Digital Railway Programme will need to navigate. In our next article, we will look more closely at these contractual challenges and put forward solutions to overcome them.
Creating a National Digital Rail Specification
The Digital Railway Programme aims to involve suppliers in writing a national digital railway specification, rather than developing a specification in-house which may be restrictive and costly to implement. The preferred model is to develop this specification on a cost plus basis. No doubt this part of the programme will involve engagement from many of the leading global suppliers in the relevant type(s) of technology.
The contractual challenge will involve ensuring those suppliers engaged to write this specification are appropriately incentivised to ensure their specification is easy to develop and deploy later on during the programme. This is more difficult to do financially in a cost plus model. The Digital Railway Programme will also need to manage the perceived advantage for organisations who might be involved in both writing the specifications and then bidding for work packages for developing and deploying technology based on these specifications – the success of the programme will require a high level of industry engagement and so this perception will need to be overcome.
Multiple Delivery Owners
Even though the Digital Railway Programme is intended to be implemented on a per route basis, the number of stakeholders involved will take some managing - there will be Digital Railway Contractors split between in-cab, trackside and rail operating centre technologies. There will also be other contractors in the supply chain. And then there are the Train Operating Companies (TOCs), Freight Operating Companies, Rail Stock Operating Companies (ROSCOs), Network Rail (and other infrastructure owners), the ORR, and the DfT.
The Digital Railway Programme’s preferred delivery model is to break down the systems integration work per route into a series of projects, each having its own Delivery Owner with each Delivery Owner being tasked to develop and deploy its project. An industry-wide Programme Management Office led by the Digital Railway Programme will provide overall coordination and quality assurance. Delivery Owners within a route will undoubtedly have dependencies on multiple third parties. For example, ROSCOs tasked with developing and deploying the relevant technologies onto rolling stock will be reliant on TOCs to make the rolling stock available for fitment.
Delivery Owners within a route will also have dependencies on other Delivery Owners within the same route. Assuming Network Rail is the Delivery Owner for deploying these technologies on tracks and within rail operating centres, it will have dependencies on the Delivery Owners for those parts of the rail infrastructure outside of its ownership e.g. stations and depots. The contractual challenge will involve ensuring there is some nexus (contractual or otherwise) between Delivery Owners on a per route basis to ensure their goals and incentives are aligned.
Whole life risks
The technologies comprised within the Digital Railway Programme are stated to have a typical operating life of 40 years. The Digital Railway Programme will need to ensure the technology can be run and maintained over this period of time and at an acceptable cost. The normal ways of mitigating this whole life risk in an infrastructure environment need to be re-thought given this programme relates first and foremost to technology.
Regardless of whether the technology is based on the common ETCS standard, each supplier will still be deploying proprietary technology onto a route. There will therefore 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 this 40 year period. The Digital Railway Programme will need to consider the contractual tools necessary to avoid the risks of supplier lock-in over this 40 year period.
There are also challenges to do with the duration of franchises and the remaining operating life of rolling stock, neither of which will align with the operating life of this technology. This raises the question as to who should be contracting as the customer for the support and maintenance of this technology, given TOCs and ROSCOs involved in deploying the technology on a route may not be involved in that route for the operating life of the technology.
The NEC3 contract model has been referred to as the most appropriate starting point for achieving the spirit of contractual collaboration which the Digital Railway Programme is seeking to engender with the supply chain. The NEC3 contract model is stated to put the collaborative “sharing of risk and reward at the heart of” a procurement and it has been used in many high profile infrastructure projects. However as it is a construction contract, not a technology contract, it will require material amendment to make it fit for purpose for the Digital Railway Programme.
In our next article, we will discuss the NEC3 contract in more detail and also put forward solutions to some of the challenges we have posed in this article. Please keep reading…..
Have you read our Introduction to the Digital Railway? Read it here: