>  I know this will sound rather flippant, but what is the
> point of an email "archive" if one does not apply retention rules to it?
>  It
> would seem to me to be an expensive, glorified backup system.  We should be
> to the point of understanding that email in and of itself is not a record
> type or series, but just the delivery mechanism of various records, with
> varying informational/retention values.  It has been my concern for years
> that we deploy expensive tools such as these and document imaging systems
> without first contextualizing them within a records management framework.
> OK, I'll step down from my soapbox now.


Dan is exactly right- this was the subject of a presentation I just made
last week to a group of IT and RM staffers from the DOE and NNSA in New
Orleans.

A lot of the risk here depends on what business your business is in... if
you are subject to litigation for any reason and evidence potentially exists
within your e-mail, then minimizing the volume of e-mail you retain is to
your advantage.

One of the first steps is to develop a POLICY... an e-mail policy that is
based on, and consistent with, your RM Policy that employs the same
definition of a record.  Further, this policy needs to clearly state who is
to use e-mail for what purposes, and what should and should not be
accomplished through the use of e-mail.

Once you clearly identify your non-record e-mail, and your transitory
e-mail, that which has a limited business value and can be deleted in 180
days or less, cio.energy.gov/*Email*Records.pdf  your problem is 90+%
solved.  In my case, 12-15% of my e-mail on a weekly basis is directly
business related; of that half is either non-record or transitory.  My
e-mail that has a retention period of greater than 2 years amounts to 7-8%
of what I receive, and I think you may find that number to be consistent
with most users.

Next, is to link the retention of e-mail to the organization's existing
retention schedule.  But not necessarily in a message by message manner, in
more of an aggregated manner.  In any case, if the numbers above track for
you, you would be looking at assigning a retention period to 7-8% of what is
received instead of 100%.

So I fully agree that regardless of how inexpensive HSM products have
become, retaining everything in a system incorrectly identified as an
"archive" or even in "backups"  is NOT a solution, nor is it the proper use
of a tool.  Doing this results in useless volumes of information, including
copies of e-mail set throughout an organization by cc, bcc, or 'reply to
all' that were intended as informational or for reference use only

This where WE.. the RMs come into the picture.  Education and training is
where we can interject ourselves, by providing data and direct examples
within our organizations of this "7-8% versus 100%" representing a serious
savings in storage and a limiting in the risk of retaining all of the e-mail
when it serves no purpose.

Another place we come into play is explaining that not only do backups not
serve as a means of properly storing e-mail, but as a great risk to
e-discovery in the event of a legal action.  Cases over time have shown when
there is an RM policy that includes retention and rules for applying them to
information, but there is also a conflicting IT practice that not only
allows for retention of information longer than these periods state, but
actually ENCOURAGES it, companies are made to spend whatever it costs to
search and produce records from these sources.

I could go on, but I won't.. suffice to say, organizations need to start
seriously evaluating what they're doing with e-mail and look at methods to
reduce the overall volume and focusing solely on the records.  Leveraging
these techniques will assist in turning RM from a cost to a benefit in your
organization.

Larry

-- 
Larry Medina
Danville, CA
RIM Professional since 1972

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]