30 August 2022
By Kate Moncrieff & Thomas Britland

Our human factors team have experience of managing major Traffic Management System programmes in the UK, Norway and here in Australia. From our combined experience we have identified a number of challenges that were common to all the three countries which we have incorporated into a summary of lessons learned. We presented on this topic at the recent HFESA conference in November 2021 and have prepared this summary so we can share these lessons with a wider audience.

This article provides two examples from our work (Kate in the UK, Tom in Norway) including the reason for the methods selected and their benefits, then a summary of key challenges and the lessons learned for Human Factors Integration (HFI). But first, for those that don’t know, we should start by explaining what TMS is and what are some of the operational/business impacts associated with its introduction.

What is a Traffic Management System?

A Traffic Management System or TMS is a number of interconnected systems, that through continuous monitoring of rail traffic can identify potential future conflicts or delays within the train timetables and provide users with suggestions on how to manage the network, also providing the user with any impacts that suggestions may have on train performance once executed to aid them in their decision making. This can increase the performance of the network by allowing the users to resolve issues before they arise, while allowing them to optimise train running throughout the day through replanning activities. Because TMS helps to reduce the time it takes to recover from disruptions it will help to manage the increase in train services, which is the goal of most major TMS implementations.

So now we understand what TMS is, what are the impacts of its implementation?

There are a number of impacted roles and business functions as indicated by the diagram above, three of the key impacts are:

Changing Roles and Role Boundaries

Implementing a TMS system can result in new tasks for a particular role, it can also the result in the transfer of tasks between roles. An integrated digital solution can also mean that certain tasks are no longer required to be performed by the user as they are now performed by the system. For example, the role of the signaller moves away from regulation and controlling signals to planning and monitoring.

Managing Operational Performance 

 In legacy operations, responding to events and incidents is reactive because the issue has to be realised before it can be fixed. Whereas with TMS there is real-time proactive management of the railway where users can see and resolve issues and incidents ahead of time. This not only changes the way that people work but has far reaching implications on business processes.


TMS is a new and complex technology that has far-reaching impacts not just for operations but on many aspects and at several levels of the business. To identify the impacts relevant to each role requires a detailed knowledge of the new solution combined with a detailed knowledge of current tasks and processes. This creates some significant challenges for Human Factors, we will share a couple of examples we have worked on which highlight this.


Extract from the November 2021 HFESA presentation:

“The context of the UK project I worked on was that TMS hadn’t been implemented anywhere in the UK before, so I was working on one of the first TMS projects. As is happening in here Australia, the UK ended up having a number of separate TMS projects running in parallel. This meant there wasn’t the learning in the country, there wasn’t a full understanding of what it would mean for operations and maintenance, the scale and breath of the change was not anticipated or understood.

One of the challenges was that there was no defined operational requirements or future operating concept. Neither was there a documented ‘As Is’ process, which anyone who’s worked in Rail will have experienced, a lack of sufficiently detailed job descriptions or role definitions. I realised that I needed to find a risk-based approach for looking at the totality of the system, to understand the context and focus future work. It was also clear that the approach would need to be efficient as, given the project timescales, there simply wouldn’t be time to do a complete bottom-up analysis of everything that each of the roles currently did.

Given the scale and breadth of the change and number of different roles impacted within this distributed network it was obvious that there would be some key command and control type considerations, but where to start…

I began by mapping the system functions of each HMI to the relevant roles and aligning it as far as possible with their current role functions. Initially keeping the analysis at this highest level, then focusing in on the fact that by the very nature of the dynamic technical system (which would be used for both in advance planning of train services and real-time planning of train services) the actions of 1 role interacts with / impacts other roles. This role boundaries and role interactions analysis was key to identifying the key human factors risks and structuring our work to focus on priority areas.

This HF analysis was then used by operations to understand the system and define the future concept of operations. It was also used by engineering to develop the interfaces between systems to support the data flows. This was an example of how despite there being no inputs a Human Factors Specialists can follow a risk-based approach, really add value and embed their analysis within the activities of other disciplines within the project.”


Extract from the November 2021 HFESA presentation:

“The second example relates to HMI design from a project I worked on in Norway, this project inherited a product that was designed in the 80s. So as part of the human factors work was to lead the HMI redesign of the system to make it more modern and more up to speed with what the client was expecting. It provided us with unique opportunities, like to be involved at the very onset of the project and get involved with multiple different stakeholders across the business. It also provided us with unique challenges since at the beginning of the project there was minimal understanding of the system capabilities, the user’s needs and desires or the business needs.

We decided to do more than take a traditional standards compliance approach and incorporated methods from UX and UI. We chose Google Ventures (GV) a design sprints methodology which requires you to focus on one aspect of the system design at a time, you dedicate one week to each aspect of the design and try to get from idea to minimum viable product by the end of the week. By using this approach, it allowed us to bring together people from all areas of the business from control room operators all the way through to project managers and in some instances even from the finance department, who were doing the budgeting for the project. This enabled us to understand how this system was going to work at every level of the business and what the needs of each individual user were going to be.

We would start very early on with a mind map of how a user would get through certain functions to achieve the end goal and understanding where the pain points would be, through various iterations of design. Including sketching and special programmes for dummy versions of our HMI to perform tests with our users, this was great because it helped not only to get feedback but also to close system knowledge gaps. We brought in people from different areas of the business to try out the prototypes and work through the scenarios. It educated a lot of different people, we were actually bringing our users on a journey with us, helping them to understand not only about the HMI that we were designing but more about TMS and how the future operations of their business were going to work. This was exceptionally valuable because it enabled them to go back to their peers in the control room or in the project management office and talk to them and pass on that knowledge.”


The key challenges have been common to all three countries that we’ve worked in were:

  • Future operations are not defined and documented
  • Current operations are not documented well enough
  • Lack of a complete understanding of the system behaviour and capability
  • Availability of end users and their level of knowledge

These challenges are magnified if TMS is introduced at the same time as a new System of Safeworking (e.g. moving from lineside to new in-cab signalling). What we think is interesting is that these challenges are common to all the countries and hence why we have incorporated them into a summary of lessons learned. The five key lessons learned are:

Users are key

Users provide critical insights, involving genuine end users as early as possible in the project is beneficial as is keeping consistency within our user groups. It’s very easy on complex projects to get lost between a variety of different users and not see the same people consistently this can dilute the benefit for design development and validation or delay the process. In contrast, working predominantly with a core group of users they are able to truly understand the system, providing educated insights, and championing the system whilst edifying colleagues. Working with a core group should not however preclude engagement with a wide range of end-users and stakeholders.


At the beginning of a project clients and stakeholders don’t necessarily fully understand the benefits and implications of the new technology so understandably do not have a clearly defined future concept of operations. We’ve learned that you have to bring people on a journey with you on these types of projects. In HF we’re very user and client-focused and our work can help educate people on how these systems work and the benefits they will bring.


Understanding the project and the technical scope in addition to potential business impacts whilst also recognising project barriers and constraints and the fact that different stakeholders can have competing priorities. Understanding these is necessary to identify and plan how best to navigate them, recognising that we can’t necessarily do HF the way we want to instead we have to plan our work in a way that will be most effective.


HF has great tools and the output of our analysis can inform different aspects of a project and ensure systems can be safely used by all users. However, there isn’t a golden bullet and not one approach fits all. We need to work with the inputs available and be flexible and adapt to the environment around us. Careful planning is required to ensure the HF works satisfy the HF requirements whilst providing the maximum value for the project as a whole.


HF is not necessarily recognised for the true integration role that we play. Where we have the flexibility of approach we can build on and integrate with the activities that are being undertaken by other disciplines on the project. As illustrated in both of our case study examples, good integration involves being in the right place to effect change and making sure that users are considered throughout the process.


On a recent project here in Australia we have embedded lessons that we learned from our past project experience, such as engaging with all levels of the business, involving end users from the start, and following a user centred design approach to HMI design. These activities have all reaped the rewards of positive feedback!

We are both informing the design to meet the needs of the business and supporting operational integration so that the business is designed and ready to make the most out of the technology. And within this context we are integrating with the work of other disciplines, identifying and filling the gaps, which is where the real value of Human Factors can be found.

Find out more

If you would like to know more about the Human Factors services that we offer at SYSTRA, visit the main page.

Latest news

Don't miss anything, follow us on social media !