RECMGMT-L Archives

Records Management

RECMGMT-L@LISTSERV.IGGURU.US

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Sender:
Records Management Program <[log in to unmask]>
Date:
Fri, 1 Jun 2007 16:33:15 -0500
Reply-To:
Records Management Program <[log in to unmask]>
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
8bit
In-Reply-To:
<007b01c7a470$fee484f0$b2d8f845@DCHYS881>
Content-Type:
text/plain; charset="iso-8859-1"
From:
Brent Reid <[log in to unmask]>
Parts/Attachments:
text/plain (80 lines)
In a well designed Big Bucket approach, you have don't have to keep records
longer than necessary.

There should be enough buckets to accommodate all retention periods. 1 year,
3 year, 5 year, 7 year, etc. But no more.

The conditions will be handled separately from the buckets themselves, and
the other meta data can be used to identify the records when they are
needed.

Again in a PROPERLY DESIGNED Big Bucket approach, the advantages far
outweigh the disadvantages. (of which I don't believe there are any).

My opinion and that of my major clients and NARA who has blessed every
design I have implemented. (Clients include DoD, the NSA, and other Federal,
State and local government entities and commercial clients.)

If you are keeping records too long, then your Big Bucket design needs to be
revisited.

If you have the proper meta data assigned to your documents, you don't have
to divide your File Plan into categories - that would be redundant and THAT
would be the cause of extra work, difficult searches, etc. etc. The Big
Bucket approach itself is not the cause of the issues listed below, poor
design of the Big Bucket approach causes the problems.

Why include categories in your File Plan when it belongs in the meta data ?

-----Original Message-----
From: Records Management Program [mailto:[log in to unmask]] On Behalf
Of John Montaņa
Sent: Friday, June 01, 2007 12:19 PM
To: [log in to unmask]
Subject: Re: Big Bucket Retention - Or "Toward a Limited Set of Retention
Periods"

In my view, there's no fatal objection to big bucket retention.  The
problems are practical:  The bigger the bucket, the longer its retention
period must be, since the retention period must accommodate all required or
desirable retention periods for any single item within the bucket.  This in
turn means higher storage costs, larger and more difficult (and thereby more
costly) searches, more discovery and more of everything else associated with
having records around longer, which could wind up being very expensive
indeed, and perhaps impractical or impossible as well.  

If analysis reveals that this is a worthwhile tradeoff for administrative
convenience, then big bucket is fine; however, you have to do the analysis
to find out if this is true, and you still have to do all of the work to
make sure they're the right buckets with the right retention periods, so you
wind up creating a detailed schedule and then nesting it up into broad
categories.  And of course, you still need an index or file plan and all of
the rest.

I think that as a practical matter, once the bucket gets past a certain
size, the equation doesn't work for many records.  For example, an
"environmental" bucket would contain records with retention period ranging
from very long (50 years to indefinite) to very short (a couple of years).
In this case the simplicity of administration does not, in my view,
compensate for the very substantial downside of the big bucket.

Bottom line:  I don't think that it will work well for everything, and if
you use it, you have to optimize your bucket size to accommodate other
considerations.  That will mean retention of fairly granular record series
for at least some records.

John Montaņa, General Counsel
PelliGroup, Inc.
29 Parsons Road
Landenberg PA 19350
610-255-1588
484-832-3260 mobile
[log in to unmask]
www.pelligroup.com

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

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

ATOM RSS1 RSS2