HomeIndustry NewsNetwork Rail’s introduction of new technology

Network Rail’s introduction of new technology

Listen to this article

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 under-supported. 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.

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. 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.

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 decisions within their own area, independently from each other, even though they are trying to solve the same problem.

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.

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 other as there appeared to be a language barrier between them.

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).

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.

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.

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 available here.

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:

  • 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.
  • 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.
  • 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

David Shirres BSc CEng MIMechE DEM
David Shirres BSc CEng MIMechE DEMhttp://therailengineer.com

SPECIALIST AREAS
Rolling stock, depots, Scottish and Russian railways


David Shirres joined British Rail in 1968 as a scholarship student and graduated in Mechanical Engineering from Sussex University. He has also been awarded a Diploma in Engineering Management by the Institution of Mechanical Engineers.

His roles in British Rail included Maintenance Assistant at Slade Green, Depot Engineer at Haymarket, Scottish DM&EE Training Engineer and ScotRail Safety Systems Manager.

In 1975, he took a three-year break as a volunteer to manage an irrigation project in Bangladesh.

He retired from Network Rail in 2009 after a 37-year railway career. At that time, he was working on the Airdrie to Bathgate project in a role that included the management of utilities and consents. Prior to that, his roles in the privatised railway included various quality, safety and environmental management posts.

David was appointed Editor of Rail Engineer in January 2017 and, since 2010, has written many articles for the magazine on a wide variety of topics including events in Scotland, rail innovation and Russian Railways. In 2013, the latter gave him an award for being its international journalist of the year.

He is also an active member of the IMechE’s Railway Division, having been Chair and Secretary of its Scottish Centre.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.