Delay attribution : Opportunity for cost savings?

[PG]

In layman's terms, NR will fine Southern for all the minutes of delay they caused, and Southeastern will claim from NR for all the minutes of delay they experienced

I suspect the majority of people within the rail industry also have no idea. The blame just goes round the staff similar to pass the parcel, and whoever is holding the package when the music stops gets allocated the blame

No worries. There's also a similar internal fight, so Southern will argue with itself between departments who's budget the delay comes out of.

And there are whole departments of staff within companies who are just paid to sit there and argue with each other via email

These posts got me thinking, now that all franchised TOC's are basically fixed fee management contracts could the delay attribution merry-go-round be slimmed down since it is money from the same source (government) just being passed around?

I can see that DA would still have a place due to the FOC's and Open Access operators but perhaps now there is less need for it concerning NR - TOC's moving the same money from one pot to the other and thus an opportunity to reduce the costs of running the railway.

As an outsider maybe I am being naive, what are your thoughts?

 

[lineclear]

Delay attribution could be useful to work out where delays can be reduced in future, but ending practices/games such as disputing delays after twelve days would probably be a good thing.

 

[JamesT]

These posts got me thinking, now that all franchised TOC's are basically fixed fee management contracts could the delay attribution merry-go-round be slimmed down since it is money from the same source (government) just being passed around?

I can see that DA would still have a place due to the FOC's and Open Access operators but perhaps now there is less need for it concerning NR - TOC's moving the same money from one pot to the other and thus an opportunity to reduce the costs of running the railway.

As an outsider maybe I am being naive, what are your thoughts?

My understanding from previous posts on this subject is the Delay Attribution setup dates from the BR days. You still need to have some idea of what's causing issues in order to manage them.
For example with this derailment; was it driver error in which case you may need to improve training, or was it a track fault that requires maintenance? You might not need to move money from pot to pot, but you still need the people working it out which is where the cost is.

 

[PG]

You might not need to move money from pot to pot, but you still need the people working it out which is where the cost is.

That is true, so I guess not much (if any) opportunity to reduce costs.

 

[tbtc]

What are you going to do with the staff who collect/review the data? Fire them, assuming that we don't go back to "franchises" and keep a fully nationalised railway?

For me, delay attribution is a small price to pay to asses problems, check how cost effective they are to fix, improve the service going forward.

e.g. if one delay costs the railway £10.000 in refunds to passengers then you can assess the root cause of fixing this against the frequency of it happening - does this happen weekly or once in a blue moon?

If we are compensating passengers delayed at Edinburgh at tea time but the root cause of the problem was two services pathed too closely at Plymouth in the morning rush hour then you\d be able to review whether it's worth tweaking one of the services in Devon to avoid the "delay repay" costs you are shelling out to Scottish passengers (due to the impact upon a Cross Country service, which might leave Plymouth thirty seconds late but be over an hour late by arrival at Waverley due to missing its paths through various bottle necks en route.

Don't look at the attributors as just a "cost", look at them as a way of fixing where the genuine problems are on a complicated network (where we are handing money back to passengers for any serious delays) - to use the old cliche about chaos theory, we need to try to stop that butterfly flapping its wings so that we can stop hurricanes from happening (becuase hurricanes cost us a lot of money)

 

[The Planner]

We have done this before, attribution is here to stay. You need to find root causes of delay, simple as.

 

[IanXC]

I'm lead to believe that there are significantly fewer people actually doing this work than everyone seems to assume.

TPE apparently have a role in Control who does this alongside a whole raft of other work, and about 4 9-5 office jobs...

 

[PG]

Thank you all for your input in answering the question.

I'll accept my naivety and leave the running of the railway to those who know what they are doing.

 

[tbtc]

Thank you all for your input in answering the question.

I'll accept my naivety and leave the running of the railway to those who know what they are doing.

I think it's a perfectly reasonable question that you've asked - there's certainly a common refrain amongst enthusiasts along the lines of "privatisation has pushed up costs by requiring all of these pen pushers, and we could save a lot of money if only they were abolished", but the number of staff involved is pretty small compared to the overall railway and the work done is intended to save the railway money (by identifying where problems actually occur and assessing whether the costs involved justify resolving them).

For example, the only late service at Sheffield recently was the Liverpool - Norwich train - a long distance route with reliability issues that will soon be chopped at Nottingham - https://www.realtimetrains.co.uk/train/W88354/2020-08-25/detailed - it was on time leaving Lime Street at 10:51 and survived Castlefield unscathed to be on time at Chinley (as it approaches the tunnel that takes it under the Pennines/ Peak District).

It was scheduled to get into Grantham at 14:05, at which point the 90mph 158 (which might be substituted for or include a 75mph 153/156) has to find a path on the fast ECML to Peterborough - if it can't get to Grantham in time then it might be waiting for a while to join the busy ECML (obviously things are a bit thinned out at the moment). So if the service arrived in Norwich late enough that compensation was due to passengers, where would the blame lie? Was it due to Network Rail infrastructure (signalling, tracks, engineering)? Due to train staff decisions? Passenger at fault? Badly maintained train? Waiting on another service? (I can't see that there was a delayed train ahead of it, but that's often the case in the Hope Valley).

How do we stop this happening again? If a dodgy signal at Chinley (*) causes hundreds of pounds of "delay repayment" for passengers at Norwich then I understand that the cost would be allocated to Network Rail, and they'd then have to assess whether the cost of improving/replacing this signal was good value for money compared to the cost that they were shelling out to inconvenienced passengers.

* - I'm making an assumption here - it could be that the fault lay with another TOC/FOC or with EMR themselves - e.g. if the reliability problems of their 1980s train is causing them thousands of pounds in compensation then that's an incentive to improve their maintenance to minimise similar issues in future - if a badly pathed freight train or an unreliable Northern stopper is at fault then the cost should be apportioned there for them to shape up.

I think that the important thing to remember is that this kind of "attribution" happens at all large companies - public sector too - if you nationalise the railways then you'd still have people trying to assess root causes, since it matters if you want to improve things - e.g. if weak electrification is costing millions of pounds of delays then you'd need to know those costs to compare to the bill for fixing the problem. This wouldn't go away under any kind of "New British Rail" (it happened under the old British Rail too) - if you want to run things better then you need to know the root cause of what is currently going wrong.

 

[Tomnick]

As others have said, I think there’ll always be a place for delay attribution. Now, though, the focus seems to be solely on money being passed around the industry. If that element’s removed, the industry might save some money by effectively eliminating any justification for the higher levels of the dispute process, but more importantly it might incentivise all parties to co-operate to actually correctly identify the root cause of a delay rather than just trying to shift the blame somewhere else even if it doesn’t belong there!

 

[Dr Hoo]

As others have said, I think there’ll always be a place for delay attribution. Now, though, the focus seems to be solely on money being passed around the industry. If that element’s removed, the industry might save some money by effectively eliminating any justification for the higher levels of the dispute process, but more importantly it might incentivise all parties to co-operate to actually correctly identify the root cause of a delay rather than just trying to shift the blame somewhere else even if it doesn’t belong there!

It really isn't. The performance regimes are (a) largely automated, taking essentially aggregated data from operational delay attribution and (b) usually 'managed' by a small group of different people (with other jobs, often more in finance and commercial roles rather than front-line operations), on a 4-weekly period basis largely 'signing off' what the computer has spat out. (I accept that practice can very between operators.) The idea that every delay attribution clerk spends all day arguing with somebody else in the industry, incident-by-incident, on the basis of "that's another eighty quid that you owe me" or pretending/lying that a delay caused by (say) a TOC staffing issue is really an infrastructure fault is a complete myth.
I have often posted before about the ineffective shambles within BR before it developed delay attribution. Added up over the whole network many hundreds of local Area Operations Clerks (and equivalent roles) spent all day sifting through control logs, guards' delay slips, platform chargehands' tick sheets, train registers and so forth trying to piece together what had gone wrong and vainly sending out 'Please Explains' to staff who were by then probably either on leave, had forgotten or would never bother to reply. It was an 'after the event' process that made it almost impossible to nail things down. The vital ingredient of delay attribution is that it forces people to capture root cause whilst it is still fresh in everyone's mind.
Of course some incidents like wires down may still require more lengthy technical investigation but the effort saved in robust data capture can now be applied to actually developing schemes to prevent problems recurring.

 

[Bald Rick]

It really isn't. The performance regimes are (a) largely automated, taking essentially aggregated data from operational delay attribution and (b) usually 'managed' by a small group of different people (with other jobs, often more in finance and commercial roles rather than front-line operations, on a 4-weekly period basis largely 'signing off' what the computer has spat out. (I accept that practice can very between operators.) The idea that every delay attribution clerk spends all day arguing with somebody else in the industry, incident-by-incident, on the basis of "that's another eighty quid that you owe me" or pretending/lying that a delay caused by (say) a TOC staffing issue is really an infrastructure fault is a complete myth.
I have often posted before about the ineffective shambles within BR before it developed delay attribution. Added up over the whole network many hundreds of local Area Operations Clerks (and equivalent roles) spent all day sifting through control logs, guards' delay slips, platform chargehands' tick sheets, train registers and so forth trying to piece together what had gone wrong and vainly sending out 'Please Explains' to staff who were by then probably either on leave, had forgotten or would never bother to reply. It was an 'after the event' process that made it almost impossible to nail things down. The vital ingredient of delay attribution is that it forces people to capture root cause whilst it is still fresh in everyone's mind.
Of course some incidents like wires down may still require more lengthy technical investigation but the effort saved in robust data capture can now be applied to actually developing schemes to prevent problems recurring.

Brilliant post, go to the top of the class!

 

[Tomnick]

It really isn't. The performance regimes are (a) largely automated, taking essentially aggregated data from operational delay attribution and (b) usually 'managed' by a small group of different people (with other jobs, often more in finance and commercial roles rather than front-line operations), on a 4-weekly period basis largely 'signing off' what the computer has spat out. (I accept that practice can very between operators.) The idea that every delay attribution clerk spends all day arguing with somebody else in the industry, incident-by-incident, on the basis of "that's another eighty quid that you owe me" or pretending/lying that a delay caused by (say) a TOC staffing issue is really an infrastructure fault is a complete myth.
I have often posted before about the ineffective shambles within BR before it developed delay attribution. Added up over the whole network many hundreds of local Area Operations Clerks (and equivalent roles) spent all day sifting through control logs, guards' delay slips, platform chargehands' tick sheets, train registers and so forth trying to piece together what had gone wrong and vainly sending out 'Please Explains' to staff who were by then probably either on leave, had forgotten or would never bother to reply. It was an 'after the event' process that made it almost impossible to nail things down. The vital ingredient of delay attribution is that it forces people to capture root cause whilst it is still fresh in everyone's mind.
Of course some incidents like wires down may still require more lengthy technical investigation but the effort saved in robust data capture can now be applied to actually developing schemes to prevent problems recurring.

Excellent points, well made - thank you. Clearly I’ve overestimated the extent of the delay attribution machine above the level of the attribution and initial dispute! My perception is that it’s an excellent system for tracking reactionary delay and pinning it down to an initial cause, but often poorly implemented in practice. I’m often amazed to see a pretty obvious delay stuck to a virtually irrelevant cause - e.g. a train stood for ten minutes with engine problems and subsequently losing another six or seven minutes over the reporting section having the whole lot dumped onto the very slightly late train that it was previously (briefly) held for as it came off a single line. I concede that that’s absolutely not caused by a bloated staffing structure though, just initially dodgy attribution and no-one else picking up on it to dispute it. Ultimately, though, it’s exaggerating the impact of the root cause of that initial slight delay, and letting that second incident escape unnoticed!

 

[Bald Rick]

Excellent points, well made - thank you. Clearly I’ve overestimated the extent of the delay attribution machine above the level of the attribution and initial dispute! My perception is that it’s an excellent system for tracking reactionary delay and pinning it down to an initial cause, but often poorly implemented in practice. I’m often amazed to see a pretty obvious delay stuck to a virtually irrelevant cause - e.g. a train stood for ten minutes with engine problems and subsequently losing another six or seven minutes over the reporting section having the whole lot dumped onto the very slightly late train that it was previously (briefly) held for as it came off a single line. I concede that that’s absolutely not caused by a bloated staffing structure though, just initially dodgy attribution and no-one else picking up on it to dispute it. Ultimately, though, it’s exaggerating the impact of the root cause of that initial slight delay, and letting that second incident escape unnoticed!

That is the problem with DA. As soon as something significant happens, all minor delay becomes less visible, and so gets lumped to the main incident.

 

[DorkingMain]

Like others have said, delay attribution has become a game for a lot of TOCs. That game tends to ultimately involve chasing traincrew and other staff for explanations of minimal or obvious delays. I don't hold delay attribution teams in very high regard.

One example, I had a member of traincrew complain to me that the delay attribution had called them and said "So we have an 13 min delay at [station] which is down on our logs as a police incident, log number [blah blah blah]" Can you explain what this delay was?". Said incident was the member of staff being assaulted, which evidently they hadn't bothered to check.

 

[Dr Hoo]

Like others have said, delay attribution has become a game for a lot of TOCs. That game tends to ultimately involve chasing traincrew and other staff for explanations of minimal or obvious delays. I don't hold delay attribution teams in very high regard.

One example, I had a member of traincrew complain to me that the delay attribution had called them and said "So we have an 13 min delay at [station] which is down on our logs as a police incident, log number [blah blah blah]" Can you explain what this delay was?". Said incident was the member of staff being assaulted, which evidently they hadn't bothered to check.

I am afraid that I must be missing your point here. The DA team's query was surely them actually being 'bothered to check'?

Staff on the front line often quite reasonably point out that nobody above them or in 'office' environments seems to take an interest in what they have to face in their roles. The whole purpose of DA is to establish root cause so that actions can be taken to prevent or reduce the likelihood of recurrence. In a case of staff assault for example this may revolve around security arrangements, CCTV download and review, training in conflict avoidance and what have you.

Delay attribution is the bedrock of performance improvement through incident prevention and mitigation.

 

[DorkingMain]

I am afraid that I must be missing your point here. The DA team's query was surely them actually being 'bothered to check'?

Staff on the front line often quite reasonably point out that nobody above them or in 'office' environments seems to take an interest in what they have to face in their roles. The whole purpose of DA is to establish root cause so that actions can be taken to prevent or reduce the likelihood of recurrence. In a case of staff assault for example this may revolve around security arrangements, CCTV download and review, training in conflict avoidance and what have you.

Delay attribution is the bedrock of performance improvement through incident prevention and mitigation.

The point is they had all the details, they had an incident log number they could have checked. Instead they went and pestered the member of staff about it, insensitively. They'd already had a discussion with their line manager and the reasons for the incident had been discussed.

I'm not denying there's some degree of value to delay attribution teams. The point it's become a game for them to try and find any tiny delay that they can palm off on someone and get the cash back for it. We're constantly told about which grade delays get attributed to, and made to feel under pressure to magically make those minutes disappear. And inevitably when you pressure people about 60 second delays they rush.

 

[Romsey]

As a train planner who used to catch please explain messages from delay attribution, can I add my own view?

Major incidents are normally one off events. It's when the delay is repeated frequently that the investigations need to start. I used to maintain that a three minute delay causing 30 minutes consequential delay five days per week was more significant than a one off incident causing 100 minutes consequential delay. Tracking down why a particular train always lost time was the interesting part. It took weeks to fathom why the North Walsham to Parkeston Quay tanks always used to loose time when the section running times over one section were correct. Eventually it came down to the Heavy Axle Weight restriction over one bridge hadn't been updated when the bridge was rebuilt and it was the only RA 10 train over the bridge.....

All years ago now and I doubt that anyone has the time to attend to such details anymore

 

[Tomnick]

I do find it perplexing how so many operational staff are strongly opposed to having TDA clerks phone to ask about a delay. Personally, being conscientious, I’d much rather be asked than have it lazily put down to something irrelevant, e.g. being checked or stopped in the middle of nowhere for no apparent reason, only to later see that the resulting delay has been dobbed to a late running freight train about half an hour in front!

@Romsey - we did have a passenger train that pretty consistently missed PPM but rarely picked up any attributable delay (as it was losing the time over the course of the journey, a minute or two in each reporting section). Eventually someone decided that it needed looking into. I don’t know what the outcome was, but clearly someone’s still interested! You’d think that the FOC in your example would have had a look at it themselves if they were routinely picking up a delay there?

 

[Horizon22]

There's two elements to delay attribution really.

A) Finding out the root cause of an incident. Very helpful (as others above have noted!) and useful to provide statistics, hotspots, trends etc. There's also a lot more emphasis on sub-threshold delays particularly at London terminals and other stations with conflicting in/out moves which is very useful to highlight where the timetable may work in paper, but more difficult in practice.

B) The costs going to the right place. This becomes a lot more of a washing machine of money spinning around and endless back and forth between TOCs, NR, Other TOCs etc. This is more about trying to pin it to an exact team when it's often multi-faceted and becomes a bit of a fudge or a weeks long ordeal.

I do find it perplexing how so many operational staff are strongly opposed to having TDA clerks phone to ask about a delay. Personally, being conscientious, I’d much rather be asked than have it lazily put down to something irrelevant, e.g. being checked or stopped in the middle of nowhere for no apparent reason, only to later see that the resulting delay has been dobbed to a late running freight train about half an hour in front!

To a point. When in a massive storm and a train arrived 200 minutes late and then TDA phones why the back working was late, when I stated "Are you serious?" I think I was justified. Many other such incidents, although other times are reasonable and you expect the call you receive one hour later.

 

[The Planner]

Major incidents are normally one off events. It's when the delay is repeated frequently that the investigations need to start. I used to maintain that a three minute delay causing 30 minutes consequential delay five days per week was more significant than a one off incident causing 100 minutes consequential delay.

This, in spades. People see the headline numbers and panic. One off delays can be down to all sort of random things, one that reoccurs is where there are clear problems that need to be fixed. Trouble is if it is in the LTP plan it isn't always a quick fix and you often have to wait for the next timetable. That one also doesn't always seem to register with people either!

 

[Romsey]

@Romsey - we did have a passenger train that pretty consistently missed PPM but rarely picked up any attributable delay (as it was losing the time over the course of the journey, a minute or two in each reporting section). Eventually someone decided that it needed looking into. I don’t know what the outcome was, but clearly someone’s still interested! You’d think that the FOC in your example would have had a look at it themselves if they were routinely picking up a delay there?
[/QUOTE]

Undoubtedly NO. It used to be that the freight companies worked on 15 minutes either way of contract time was OK. The train was running to its final destination and the drivers home depot so the delay didn't continue for that FOC.
It only really showed up because the initial consequential delay was a contra peak passenger service from a country stabling point into London and rolling up a couple of minutes late caused all sorts of problems.

It all comes down to is someone interested and understands the implications.