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:
Larry Medina <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Tue, 6 Oct 2009 14:40:50 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (70 lines)
>
>I've never been a fan of the big bucket approach because you throw
>classification out the window.  Sure it makes it easy for the user to
>store, but classification is one of the backbone components of records
>management.  How do you get around this?
>

John-

I'll take a stab at this one, because I've presented on it to large groups
who were willing to say "Well, I CAN DO THAT!" when the presentation was over.

First, I prefer to use 'categorization' to 'classification' because in some
instances you are actually working with classified information, and that
confuses some people.  

As to it being a backbone of RIM, I think when you're talking about some
organizations, the proper application of a record series to content may be
more crucial than in others... and the application of "retention buckets" is
in no way intended to diminish that.  In fact, in the situation I work in,
we don't change anything when it comes to placing an identifier on a record
in its metadata, its still assigned a specific record series and if it's
going into an RMA, it gets a hard schedule associated with it because it
inherits the properties of the folder its placed in.

Few organizations are taking e-mail to this level (yet) but they're still
trying to get a handle on minimizing volume and appropriate retention, which
in many cases means ensuring you keep it at least as long as the *minimum
required* retention period (which is what most retention schedules are based
on), but if you evaluate the potential risk (as opposed to any perceived
benefits) of retaining it a short period longer, you make the decision to
retain it for that time frame.

As I said in the example earlier, if you can perform a role based review of
what the content of e-mail sent/received relates to and can determine what
the associated retention periods (based on record series) would be, you may
have "bands" of time that are common to these.  The bands may encompass 2-5
years, 6-10 years, and 10-25 years.  But rather than separating them out to
the periods related to the individual record series, 2y, 3y, 3y6m, 5y, 6y3m,
7y, etc and requiring users to understand the relationship of the series to
the retention and the purpose for this level of granularity, you limit their
actions to choosing from one of 3 or 4 periods.

The benefit?  You seriously reduce the volume being retained and you get
buy-in from the users who will do the work up front.  The risk?  Some e-mail
may be retained a year or 6 months, or even 5 years longer than required
(depending on HOW BIG you make your buckets)... and if the content isn't
anything that could prove damaging to the organization if it turns up in a
legal proceeding, then the risk is minimal.  

I realize this isn't the classic application of hard line records management
practices in a "Records Management Perfect World" but it's a lot better than
30, 60, 90, 120 days or establishing a volume limit after which the oldest
content gets automatically purged.  And if you look at what's happening in
many organizations, this is how decisions are being made simply because no
one is willing to take the time to do the hard work.   AND IT SURE BEATS
keep everything.

This doesn't work in all situations and I don't advocate the use of "big
bucket" retention across the board for all content, but I can see the
benefits outweighing the risk in a lot of instances.  

Larry
[log in to unmask] 

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]

ATOM RSS1 RSS2