Top result in Google if you type in BBC records management, so they're not exactly hard to find, but I thought I'd put in a link anyway.
I co-wrote these with a colleague back in 2003 and we did so with the stated aims that the standards should be necessary, understandable and accurate.
Necessary - we decided that the standards should not be over-burdensome. Correspondingly we eliminated anything that we saw as being less than strictly necessary to meet the requirements for records management at the time. There are probably still some elements that are more aspirational than practical, but there was an awful lot that we omitted.
Understandable - looking through a number of standards (both records management standards from other authorities and some of the BBC's own documents), we found it was more the rule than the exception that these are written in overly-technical language with dense blocks of text in a way that seems designed to make them as difficult to read as possible. Considering the subject matter is less than compelling to most potential readers, we thought we'd try for the opposite effect instead. Revolutionary thinking, eh?
I will say though that it takes a lot longer to write a simple, clear sentence than it does to write an overly-wordy, badly phrased one. Editing time was quite long - but hopefully worth it as the standards have needed very little alteration since they were written.
Accurate - probably goes without saying, but we did check our sources fairly carefully. Any mistakes are undoubtedly in my interpretation.
Tuesday 17 February 2009
Thursday 12 February 2009
Building a Better Retention Schedule (Part 2)
We've started work on how we think our new retention schedule should work. The diagram below (click on the image for a larger view) illustrates the relationship between data tables for the database which (budgets permitting) will run it.
It's similar to the data relationships in our current retention schedule database, however there are a number of tweaks that we've made:
State as part of the Retention Rule is new. Previously we've had fairly narrow retention instructions (e.g. Review after 3 Years). State allows us to be more specific about what that actually means. Our current thinking is that the values for State would be: Maximum (a record must be kept no longer than), Minimum (a record must be kept no less than), Required (a record must be kept for exactly) and Advisory (we don't really care, but here's some guidance just so you don't end up swamped in unnecessary records).
Genre is something I'm willing to bet wouldn't be found on most retention schedules. We certainly haven't had it on ours in the past. Previously our retention schedule only managed the BBC's written records. Now we're expanding it to manage elements created as part of the programme making function such as rushes, stock shots, finished programmes, reversions of programmes and so on. Different types of programmes in the BBC have different retention requirements (e.g. dramas would be considered more important than gameshows). The Genre field will allow us to be able to differentiate between these types of programmes. At least that's the current thinking - we're still deciding whether this is the most appropriate way to deal with the issue.
The Local Record Type and Local Retention Rule are not completely new, but we haven't managed them in this way before. However, the background to that will probably take me more than a paragraph to explain, so I'll save that for a later blog entry.
It's similar to the data relationships in our current retention schedule database, however there are a number of tweaks that we've made:
State as part of the Retention Rule is new. Previously we've had fairly narrow retention instructions (e.g. Review after 3 Years). State allows us to be more specific about what that actually means. Our current thinking is that the values for State would be: Maximum (a record must be kept no longer than), Minimum (a record must be kept no less than), Required (a record must be kept for exactly) and Advisory (we don't really care, but here's some guidance just so you don't end up swamped in unnecessary records).
Genre is something I'm willing to bet wouldn't be found on most retention schedules. We certainly haven't had it on ours in the past. Previously our retention schedule only managed the BBC's written records. Now we're expanding it to manage elements created as part of the programme making function such as rushes, stock shots, finished programmes, reversions of programmes and so on. Different types of programmes in the BBC have different retention requirements (e.g. dramas would be considered more important than gameshows). The Genre field will allow us to be able to differentiate between these types of programmes. At least that's the current thinking - we're still deciding whether this is the most appropriate way to deal with the issue.
The Local Record Type and Local Retention Rule are not completely new, but we haven't managed them in this way before. However, the background to that will probably take me more than a paragraph to explain, so I'll save that for a later blog entry.
Subscribe to:
Posts (Atom)
Posts
