wvmarle:
Put that timing information in the RFID card - and of course make sure you have a card that's doing a lot more than just providing an ID.
The reprogramming would then be done by changing the info on the RFID card rather than on the Arduino side.
That was where my thinking had been heading vwmarle, until lastchancename weighed in with the suggestion that the data should be kept on the device and accessed by the card.
This is more what I need, most likely, as the timing parameters are pre-defined by the rules of the sport and, aside from being added to for unusual events, will remain so for the foreseeable future.
In a competition, the settings can be expected to change a few times; qualifiers, knockouts, semi-finals and finals. Team events, of various flavours, would also often feature. This is why a card-based system appealed to me, and what prompted me to head down this route was watching a judge at one event struggle with deep menus as he attempted to set up what could have been a simple event.
I had originally conceived of the timing variables being on the card, pulling them off for a particular event as needed (card for qualifiers, followed in due course by the next card in line for the knockouts etc), which would allow me to add timing setups by no more than programming cards and distributing them to the clubs.
But what if the card is corrupted (likely?) or lost in the pocket of the previous user, or simply not the right cards for any of the current need? In this case a menu on board permitting the user to do the needed setup would come in to play. This, of course, implies that the data are contained on the system anyway.
So, lastchancename, I thank you for the input.
wvmarle:
Which is going to be easier to change? Program a new card with new information, or access the configuration and change it on the Arduino?
I do feel there's merit in this, albeit not as meant by vwmarle. 
If the timing systems are deployed and the needs change, then it would be far easier for me to alter a set of cards and deploy them than to the units than recall, reprogram and re-deploy.
Perhaps a combination of the two?
If I have a basic database of setups on the unit, accessed by a menu, and a reader which would ignore that database and setup the timer independently?
This could work, giving the best of both worlds.