NETWORK RAIL’S introduction of new technology

DAVID SHIRRES

In April 2022, the Railway Industry Association (RIA) published its Railway Innovation Strategy. This highlighted that the industry could, and should, be innovating faster, better, and sooner. It noted that innovations are often stalled as railway innovation is complex, difficult, fraught with challenges, and undersupported. Hence the supply chain, which is keen to build an even better railway, can find itself stifled from innovating.

RIA’s Railway Innovation Strategy is available here:

Furthermore, individual teams were making decisions which appeared perfectly reasonable in isolation. Yet despite this there were significant difficulties in adopting ‘new’ technology.

The report considered new technology to include all forms of software, tools, or materials which are different to that used previously. This included those proven in other industries but new for a particular team in Network Rail. Hence, this study was not concerned with research which involved exploring new, plausible ideas to determine whether they work in practice. The technologies considered were those that Network Rail felt to be workable and had a business case. Several years and large sums of money had been invested on their introduction. All the case studies concerned technologies that had been successfully used in other industries for many years.

In the same month, the Office of Rail and Road (ORR) published its report titled Targeted Assurance Case Studies – Targeted Assurance Review, which focused on the introduction of new technology within Network Rail. The report found that there were reasonable processes for each team, competent people and a motivation to improve.

The study team interviewed 50 people across 25 different teams in Network Rail and the supply chain on the introduction of new plant, materials, and software, particularly in the later stages with evidence collected to support statements made. Hence this investigation concentrated on behaviours and decisions, rather than ‘the process’ of development.

Misconceptions and silos

During its interviews, the ORR study team heard four common misconceptions: (i) innovation is always uncertain; (ii) it’s reasonable for some regions not to adopt a new technology; (iii) Network Rail is risk averse so does not innovate as it is safety-focussed; and (iv) there are some people who are ‘blockers.’

Its report explains that, whilst the comment about innovation being uncertain is true for research work, this is not the case for these case studies for which Network Rail had already considered the technology to be workable. Although there are different local challenges, the study team found that there were avoidable reasons why technology was not being adopted in the regions, such as incomplete information or lack of technical support. It was felt that considering safety to be a barrier to innovation showed a lack of understanding of risk as new technologies should reduce risk through safer working and reduction in asset failures.

The review found no evidence of individuals blocking innovation. Indeed, it found quite the opposite as: “…all of the Network Rail staff interviewed demonstrated that they are not satisfied with the way things are done now and that they are comfortable challenging existing methods. They appeared eager to make changes and they wanted to be associated with projects which bring in new technology.”

It was also found that users generally had a clear justification for not adopting technology whilst developers appeared to be making the right decisions with the technology. It was considered that this was due to “silo thinking” as teams made www.railuk.com decisions within their own area, independently from each other, even though they are trying to solve the same problem. other as there appeared to be a language barrier between them.

Hence, developers can produce the right product, yet users can still refuse to adopt as both teams are basing their decisions on different information. With Network Rail personnel receiving large amounts of information every day, it is easy for information that other teams see as a priority to be missed. Hence, often users and developers were looking at different sets of information. In every case this was considered to be the root cause of poor technology adoption.

Though all those interviewed demonstrated their professionalism and competence, it was found that differences with teams had a negative impact. Time pressures on users were also an issue. The study found examples where short-term priorities drove the decision not to adopt technology. It was also found that guidance documents left users to make subjective decisions as they did not promote objective, fact-based decisions. As a result, different teams took different decisions based on the same guidance. An example of this was the Scotland region’s decision not to use EPS (Case Study 2).

(Left) EPS blocks used for platform extensions on the East Grinstead line.

Learning lessons

Although there are lessons learnt from most new technology projects, the ORR study found that communicating these lessons within and beyond individual teams was not effective. Many of the lessons learned reports were extremely detailed and required readers to spend a long time digesting all the information, assessing similarities with their own project, and assessing how to apply recommendations in their slightly different situation.

Decisions and sponsorship

Decisions to adopt new technology require effective communication about the technology with supportive individual behaviour and culture. The ORR team found key transfers of information were often through technical presentations or detailed emails rather than a collaborative discussion to unpick information and agree a shared set of priorities. Although development projects communicated regularly with users, in all the case studies developers and users were frustrated with each

Many users found processes were a significant barrier to adopting new technology. This was a particular issue for software and products that did not affect train operations (i.e., new technologies falling outside the product approval process). A particular issue is changing processes to stop using the old technology. Development teams did not appear to be supporting users in this respect.

The report highlighted the need for new technology projects to have an effective sponsor who understands the processes, incentives and cultures of the different teams involved. It noted that, although Network Rail has a community of dedicated sponsors for construction projects who are trained to understand a project’s commercial, technical, and managerial aspects of a project, there is no equivalent for new technology projects.

Those writing such reports had to determine who needs to read them but, as they cannot know of all other projects, they are unlikely to identify all the right people. Furthermore, as this is a one-time exercise, teams are reliant on word-of-mouth to find out about similar projects in the past. It was considered that Network Rail needed a better system to flag up the past projects of which teams needed to be aware.

The study team also found numerous examples where there had been no detailed review. Also, in some cases there was little attempt to collect user feedback. One such example was the purchase of 80 track measurement trollies to detect cyclic top. Despite more than 60 track maintenance engineers being trained on their use, their adoption was low. Yet user feedback was not compiled, so it was not clear who adopted these trollies and why others refused to adopt them.

Organisational issues

The report notes that for most industrial technology, developers and users are private companies whose relationship is the subject of market research, advertising, and sales. In some cases, companies have spotted a market and used Network Rail’s data to provide an innovative product to Network Rail and others in the industry. Yet when users and developers are within Network Rail, the ORR team considered that it cannot be assumed that they are working to the same goals. Hence these teams need to internally “advertise” and sell new technologies but do not have the resources or training to do this. This was the case with the little used Mobile Flash Butt Welding machines (Case Study 3) which were described in a Rail Engineer video report.

The report notes many positive examples of new technologies being adopted by Network Rail though these are often due to individuals going beyond the call of duty to overcome obstacles, convince stakeholders through force of will, or work with close friends in the user team. As an example, a supplier involved in the development of PLPR (Case Study 1) felt this was only adopted as they had enthusiastic close contacts in Network Rail.

As users in the regions and developers in route services or the technical authority, conflicting issues that cannot be resolved potentially have to be escalated to the chief executive. This would only be done in exceptional circumstances, one such example being the chief executive’s instruction to developers to make the development of the earthworks work-bank tool (Case Study 6) a top priority following the fatal Carmont derailment in 2020. At that time users had been awaiting this tool for nine years.

It was considered that the creation of the semi-autonomous regions is likely to have a positive impact on adoption as regional sponsors would more clearly communicate users’ needs to developers and technical details to user teams. Users stated that having a regional sponsor, even if not from their own region, reassured them that users were driving the project. Network Rail also has some horizontal integration between regions with Asset Technical Review meetings being held every four weeks to share technical issues.

Yet, between and within the regions, opinions varied about the region’s role in approving new technology. For example, track maintenance engineers in Scotland rely on the central technical authority to advise when new technologies are approved, whilst Scottish buildings engineers considered themselves authorised to approve new technologies. It was considered that if regions developed new technologies entirely independently from each other, this would have a negative impact on adoption.

Recommendations

The ORR report made three recommendations to improve technology adoption, by better supporting communication, culture, and lessons learned at the organisation level. These were that Network Rail should:

1. Establish a mechanism to support communication and resolve conflicts between teams of developers and users, specifically focussed on new technology. This should also include paths for escalating issues effectively, where those issues span different Network Rail groups.

2. Define Network Rail’s culture around technology adoption and effectively disseminate this. This should consider perceptions of other teams as a help, not a barrier; the impact of decisions about adoption; and the role new technologies play in delivering Network Rail’s objectives

3. Establish a mechanism to encourage teams to learn lessons from each other about good practice and issues on technology projects including improving the recording of lessons and making them more transferable. In particular, the focus should be on when and how teams read the lessons from previous projects.

The ORR’s Technology Adoption Case Studies report is essential reading for anyone who wishes to learn of the difficulties associated with introducing technology. It focusses on behaviours and decisions to understand what actually happens in the development of new technologies within Network Rail. It paints a picture of competent, committed teams who want to innovate but find it difficult to do so. Its solution is more cross-team support and guidance to aide communication between teams, establish a shared culture, and promote from previous projects.

The full report is available at: www.orr.gov.uk/media/23300

The ORR technology adoption report is available here:

ORR findings from its seven technology adaptation case studies

1. Plain Line Pattern Recognition (PLPR)

This uses train-mounted cameras and image analysis software to spot defects in rails, such as missing clips. It is widely considered to be technically brilliant with undeniable benefits and is considered to be a successful example of technology adoption within Network Rail. Yet its development took over five years before its introduction in 2012. Despite being promoted within Network Rail, less than 60% of the network is using PLPR.

2. Expanded Polystyrene (EPS) platforms

For new or extended station platforms, lightweight EPS blocks are quicker to install as they require less heavy equipment and materials and also do not require piled foundations. Their technical approval in 2012 took three years. Adoption was then very slow. By 2019, EPS had been used at 86 stations in all regions except for Scotland which had longterm performance concerns. Although EPS gained Network Rail standard design approval in 2012, it did not have a product acceptance certificate which is only given to technology that affects train operations.

3. Mobile Flash Butt Welding (MFBW)

MFBW machines produce factory-quality welds in 40 minutes, compared with four hours for a lower quality alumino-thermic weld.

Network Rail procured 10 such machines after eight years of development. It was found that their low usage was due to users not seeing their benefits. Moreover, booking these machines nationally for small maintenance jobs was problematic. At the time of the report Network Rail was selling all its 10 MFBW machines.

4. My Work App

This was one of many tools developed by ORBIS (Offering Rail Better Information Services). It allows information about drainage and fencing to be recorded on site and is connected to Network Rail’s asset database. The ORBIS team was disbanded after completion in 2019 with noone left to support users who found the app hard to use with no map. Hence the Northwest & Central Region rejected it and procured a different tool unconnected to the asset database. This created a major data handling problem. Elsewhere, Network Rail’s central Technical Authority trained over 1,300 staff, dealt with negative feedback, and improved the software. They were not trained or resourced to do this.

5. Switch rail wear coating

This factory-applied tungsten carbide coating is intended to minimise switch rail side-wear. It was trialled by technical experts who had no training to run such a research trial. The trial was continually extended over five years to cover six sites. With no clear outcome the trial was terminated without approving the product. This left users still urgently looking for a rail sidewear solution whilst the trial’s results remained unclear.

6. Earthworks work-bank management

In 2011, users requested a software tool to manage their work-bank of hundreds of constantly evolving jobs over a five-year period. After users built an Excel mock-up, it was decided that this should be part of the comprehensive Civils Strategic Asset Management Solution (CSAMS) database for all civil engineering assets. After six years, CSAMS was not ready, so the Excel mock-up was used to sub-optimally plan work during CP5 and CP6. In 2019, the Intelligent Infrastructure (II) programme started working on this tool but was unable to deliver it. During its review, ORR interviewed those concerned to specify user needs. This enabled an interim tool to be developed just in time for CP7.

7. Structures consolidated database tool

In 2011, users requested a tool to consolidate a dozen separate databases (e.g., structure condition, scour risk, traffic loading) so that only one was needed to determine the structures work required. This became part of the stalled CSAMS project. This tool was delivered as the first part of the II programme for which a further 12 components had still to be developed. Users were concerned that they would not see the full benefit until all 13 components were delivered. Hence there was a risk of repeating the mistakes with CSAMS which aimed for a single tool that was too big to deliver.