RECMGMT-L Archives

Records Management

RECMGMT-L@LISTSERV.IGGURU.US

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Savage, Jimmie" <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Fri, 1 Jun 2007 11:30:29 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (62 lines)
This subject came up in a presentation Susan made at NAGARA's E-Records Forum in Austin last month. One of the points brought out in discussion was that a factor that might affect the granularity of a retention schedule is whether or not an organization/department has a formally defined taxonomy (file plan) - the "crosswalk document" Larry mentioned.

Taxonomies and retention schedules are complementary. It would seem easier for organizations with formal taxonomies to successfully use a big bucket approach to retention scheduling. Because the taxonomy handles the organization and classification issues you just need to map it to the record series on the retention schedule to effectively apply it. In an electronic environment this can extend to automatically applying retention and disposition rules.

However without a taxonomy you are left with the problem of someone - staff member, records liaison, etc. - having to decide how to apply the retention schedule to the records they maintain. The more generalized the retention schedule, the harder that is and the more inconsistent the results. Thus without taxonomies there is a tendency to create more detailed retention schedules, sometimes almost quasi file plans. 

So if your organization is seriously considering a big bucket approach to retention scheduling you should also look at whether you have the filing infrastructure (taxonomy, file plans, etc.) in place to support it.

Strictly my humble, personal opinion.

Jim

-----Original Message-----
From: Records Management Program [mailto:[log in to unmask]]On
Behalf Of Larry Medina
Sent: Friday, June 01, 2007 9:37 AM
To: [log in to unmask]
Subject: Re: [RM] Big Bucket Retention


On 6/1/07, Harris, Paula <[log in to unmask] > wrote:
>
>
> I attended the MER Conference last week and heard Susan Cisco talk about
> Big Bucket retention schedules.  I am currently looking at my schedule
> to see if I can consolidate some classifications but was wondering if
> any of you folks have done this in your organization.  If so, how did
> your organizations respond and were there any downsides?  Thanks for
> your help.


Paula-

I'm pretty sure this is the session you're speaking about.

 www.merconference.com/session151.html - 13k
>


Now, there is a move afoot again to consolidate the retention periods, or
combine record series that serve similar purposes and assign them like
retention periods.  This is largely being "pushed" by those in the IT realm
and others trying to find ways to simplify doing what RIMs have done for
years in the physical records side of the equation.  There has been some
discussion of trying to go as far as to limit it to as few as 4-5 retention
periods,  such as 3 years, 10 years, 25 years, 75 year, or Permanent.  The
problem seems to be the way they want to go about it... at this point, we're
hearing combine the record series (which is where all the descriptive,
identifying, and example type information exists) into more "logically
titled" components.  The problem is, if no one remembers what was where, and
there's no crosswalk document to get you back to how this was determined,
finding anything is going to be... well, let's say... difficult.

There are those of us that are proposing a more sane model, one which calls
for the maintaining of the record series, but combining and re-establishing
of the retention periods into fewer time periods. maybe 10-15, but not
sacrificing the significant information that tells users where to put (or
find) something.

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance

ATOM RSS1 RSS2