Well, a subject near and dear to my heart. 

Having been on committees who have had to prepare big bucket schedules for
review and approval by the "Schedule Gods at NARA" I can tell you that no
matter how many people develop it, if it gets reviewed by people that don't
have to apply it, they don't understand it.

Any of you familiar with this??  
http://www.wordinfo.info/Blind-Men-and-Elephant-crop.html

Godfrey Saxe wasn't an RIM AFAIK, but I can tell you he truly understood the
problems we face when attempting to communicate the need and purpose for an
agreed upon set of principles for developing organizational records
retention schedules.

The main push behind the desire for the buckets has been twofold-  One is to
come up with a simpler, more consolidated schedule that has more aggregated
retention periods, which results in shortening some, and lengthening others
and keep an eye on potential risks related to the early loss of some
information and the potential damage of retaining others longer than needed.
 The gist of this approach is when someone is unfamiliar with how to find
things in a well crafted organizational or functional retention schedule,
it's easier for them to toss something into a bucket and be relatively sure
they're keeping it "long enough".

Now the operative phrase here was "well crafted"... but the problem
typically is it's not well supported.  If there was a decent index to
support it that allowed users to search for record types, series, or titles
that they actually have and then it directed them to the formally titled
record series in the RRS, then they could easily apply the schedule that had
been researched to meet obligations and adjusted to include business needs
that may have exceeded those.  But few organizations take this into account.  

When a records inventory is performed to determine the "universe of records"
and organization generates and/or receives, part of the process is
identifying the records by title, either the formal title or the common name
that users apply to them.  If the extra step was taken at the completion of
the process to include these titles in an index (or crosswalk), users would
be able to find the series and would be more likely to use the schedule. 
AND if RIM was to hold training meetings following the inventory and
development/deployment of the RRS with key individuals in each part of the
organization they inventoried (train the trainer sessions), it would enhance
the usability of the schedule.

The second desire, and this is the one that sort of "chaps the hide" of most
seasoned RIMs is the argument made that applying a detailed retention
schedule "will never work with electronic records because it's too complex
and it takes too long to use".   Ummm... who cares?  

Okay, that's not a good way of approaching it, but it is the bottom line. 
Which came first, the need to retain information to meet obligations and
business needs, or the desire to produce more documents than Carter has
pills and not establish a methodology for dealing with them that was any
better than creating desktop folders for "Bill's Files" or "Budget Stuff"??

Similar to the functional schedule, there IS an easier way to address the
large volume of information being generated electronically and simplify how
end users apply the retention schedule to the records they generate or
receive. During a similar step to the inventory of physical records, a
determination needs to be made of "who generates and receives what" and IF
IT IS A RECORD, or simply a copy.   Similarly, you need to determine "who
needs access to what" and if they're entitled to have only access rights, or
if they can have more detailed rights to modify, etc the items.

Now, if you have an ERMS, EDMS, ERKS, or whatever alphabet variety you call
your electronic management tool, it's REAL simple to take the next step. 
Users shouldn't need to be concerned with the fact that the RRS has 20 or
200 buckets, because they are limited to seeing the categories that relate
to what they do.  When they finish working on something and they are going
to save it, they declare it as a record, go to a pull-down menu, and choose
the category for the record generated.  The end user shouldn't need to look
at any more than 5-10 categories (buckets) to put stuff in to. And when they
put it in that 'bucket' the retention is automagically applied, because it's
already been built into the table by RIM and the ERMS support team.

A lot of what happens with the application of retention to electronically
generated records can be done by a rules and role based approach once the
end user declares a record... and if the ERMS is properly deployed, it
should be done that way.   This takes all of the wind out of the sails of
the argument that "it's too difficult to do", because it simply happens.  

Larry

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]