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:
Chris Flynn <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Wed, 9 Nov 2011 06:34:15 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (113 lines)
The typical scenario I have seen is based on ownership within an
orgainzation. In the "old" days the IT had the electronic records and
RM/archives had everuthing else. Function based scheduling might have
scheduled the records regardless of format, but IT would ignore this based
on their needs. An example would be time out on emails retained. We have
discussed this issue for years. Attachments are another one. The cost
factor is almost always thrown up as the issue for not maintaining long
term or permanent records. Resources required to maintain any permanent
records are substantial and as you point out only grow with time rather
than decrease as is the case with temp records. The Archivist/RM needs to
be aware these issues, but the retention period of these records cannot be
determined on cost. Cost needs to be planned for but the retention needs to
be maintained. The cooperation of RM, IT, and Archives is critical to the
success. It requires all parties understand the relevant issues and address
them prior to retenion. In an Ideal world decisions around these records
happen as soon after creation as possible.

The opportunity here is to get into the conversation. Archivists move out
of the shadows and closer to the line of business. IT moves from simply
implementing based on a "can do" philosophy, business driven decion making
to understanding the larger issues of Information managment. RM can move to
the strategic level of decision making, lessening the negative impact of
progress.

The tru dilemma is the inherited problems. We can, hopefully, develop and
implement solutions date forward. The legacy records present the highest
resource impact. It is our understaning of all the iussues realted to this
that is most critical. If we have not mastered the priciples of IT and
Archives we risk marginalization. We must present solutions and bridge the
gap.

Chris Flynn

On Tue, Nov 8, 2011 at 8:08 AM, Larry Medina <[log in to unmask]> wrote:

> On Tue, Nov 8, 2011 at 7:31 AM, Nancy Ur <[log in to unmask]> wrote:
>
> > I've found
> > redundancy in both paper based and electronic records collections,
> > sometimes with disparate retentions (for the same record type) or the
> > dreaded "perm" tag.
> >
>
> Differing retention periods assigned to identical record series can be a
> real problem... and should be resolved as soon as possible.
>
> The primary issue is it calls into question all retention periods because
> you can't show the basis utilized for establishing them.
>
> In business, as long as you satisfy the MINIMUM required retention set by
> any statute, regulation or law, anything beyond that is completely up to
> the organization... and if you elect to retain them for a shorter period,
> well... so is that... but as discussed last week, either case involves a
> 'risk based decision'.
>
> Is there any potential risk in keeping things longer than you have to?
> Sure... if the records contain potentially harmful information, in
> discovery there is the requirement to produce them if you have them.
>
> Is there a risk to discarding them early? A similar risk... requiring the
> organization to explain why they discarded them, and potentially having to
> face fines, sanctions or penalties associated with not being able to prove
> their position on an issue.
>
> As for the 'dreaded permanent', again it's a risk based thing.  If the
> decision is it's less expensive to just keep everything forever "just in
> case" or because establishing and policing a retention schedule is too much
> effort then someone has to weigh the cost of finding a needle in a haystack
> and/or responding to a data request if one is received.  And again, the
> potential damage of having to produce records that could have been disposed
> of "in the normal course of business".  And there's the cost of space,
> equipment, labor, storage, etc.
>
> Permanent should require a justification- not just from the individual who
> wants to keep it, but at a corporate or organizational level.  In the
> Federal Government, there is a clear definition of what records should be
> kept permanently... in business, much of it is subjective. And because it
> is generally an individual that makes a unilateral decision to apply the
> requirement, when that individual is either no longer in the role they were
> in, or no longer with the organization- how will anyone else know what the
> basis for the decision was?
>
> The worst case is applying permanent to electronic forms of records.  The
> cost of periodic migration and conversion to avoid obsolescence of
> software, hardware and media to ensure persistent access over even 10-20
> years can be staggering, depending on the format it resides in, volume of
> information, access patterns and other issues.  A failure to adequately
> scope the cost and effort to maintain any electronic content 'permanently'
> and not ensuring funds are budgeted annually for curation will almost
> always result in loss.
>
> Larry
> [log in to unmask]
>
>
> --
> *Lawrence J. 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]
>

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