Wednesday 7 April 2010

Case Histories and conclusions

The Track Record page here and on my website has turned out to be of the most consistently visited pages. To build on this, I’ve just gussied my website with some of the more interesting Selector case histories. If you’re at all interested in music scheduling in radio, there may be stuff to glean; feel free to help yourself. 

The case histories are, in chronological order:

BRMB-FM / Xtra-AM: the highs and lows of introducing computer scheduling. Very early 90s.
BBC Radio 2: putting in a multi-genre library, along with the BBC's very first digital playout rig.
Swedish Radio P4: developing client skills in hugely varied markets.
RTÉ lyric fm: working collaboratively with passionately involved production staff to build not so much a database as a knowledge base. The polar opposite of most implementations.
UTV Radio: upskilling staff and debugging inherited nightmare scheduling conflicts.
Coast 106: swimming successfully against the UK radio stream with a larger than normal library.

In this diverse range of situations, there are some common threads...
First : dialogue, up and down the chain of command,  is good. In fact, in my view it’s not so much good as essential. While many radio stations implement a rigid schedule from above, normally for ease and simplicity of management, some of the best ideas and approaches evolve from engaging with the staff who work with the system. Nobody is right all the time. If there is a conflict, either with content or with programming, it’s often very useful to examine that conflict in minute detail, so see if there is a better way to do things. Best to leave your ego at the door, though. I won’t name the middle manager who loved the idea of challenging his boss on music issues, but hated the idea of talking to his own staff about those same issues.

Second: We’re in the era of tiny databases. In the US, they’re now talking about cutting down from 150 to 50 songs. However, almost all the above case histories show ratings success allied to larger libraries. 

Third: A note to managers: large databases can be a pain to keep tidy. And talking to your staff about programming issues can be a hassle you could do without. Things can get emotive. It can eat into your time, and not everybody has that luxury. But I suggest that if you actually care about what you do, you’ll benefit from putting in that time. Radio is still full of passionate people. You’ll get the best out of those people if you meet them halfway, here and everywhere else where ideas can be shared and debated.

No comments: