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]>
Mime-version:
1.0
Date:
Sat, 29 Oct 2005 20:34:22 +1300
Reply-To:
Records Management Program <[log in to unmask]>
Content-type:
text/plain; charset="US-ASCII"
Subject:
From:
"A.F. Cossham" <[log in to unmask]>
In-Reply-To:
Content-transfer-encoding:
7bit
Parts/Attachments:
text/plain (72 lines)
> "Bean, Bernadette (HEALTH)" wrote:
>
> Most folks (even IT) seem to agree that
> we can't destroy everything.  So, we're left with two options
>
> Option 1) Disposal program - involving humans who are well trained to make
> decisions...it's labour intensive and therefore expensive and subject to
> both human error and Monday-morning quarterbacking of the worst kind)
>
> Option 2) Keep everything - no human intervention at the transaction level
> required, no nasty "what-if" arguments with lawyers or historians,


I'd like to suggest Option 3 - don't create the damn stuff in the first
place! (or at least, don't create so much of it)

Now, I know this may seem a little naive, but hear me out. Leaving aside the
unwanted, unsolicited stuff for them moment (because there's no disagreement
about getting shot of that quickly):

Email is a very useful business tool. It exists with ready-made metadata:
who from, who to (multiple individuals), subject, date, time etc. You can
have multiple messages with the same title (can't do that with documents),
you can store it in your inbox in a variety of ways (by date, by sender
etc), and you can pass things on easily. It provides a proof of what you've
done, and more importantly,  a quick way to go back to find that thing
you're looking for, a complete record, in many cases, of a working
day/week/year. Not just a paper trail, but a complete map.

The "oh, what was it Xxx was telling me about - they sent me that link ...
about two months ago ..." approach to relocating information is common.
It's a security blanket, one way of coping with information overload, and
information anxiety.

Personally, I use it to track my work and interests because I can locate
what and where easily by taking a date OR a subject OR a person OR a
listserv etc approach. Sometimes it's even something I knew would be of
interest to a friend, and so the sent items become as important as the
received.

So, I suspect there's huge resistance to deleting any of it, because then it
would not be complete, and there would be gaps. Whether you would need what
you might usefully delete isn't the point - the fact is, you'd KNOW there
were gaps.

How many emails do you send which simply buffer communication? "Thanks".
"Ok". "See you then". Do you email instead of ringing? (of course, we all
do). Do you put expiry times on those messages? (I work with a colleague
whose mundane messages regularly expire). There are messages which don't
really need to exist.

People aren't necessarily the best placed to make R&D decisions about their
email, but like anything else, there's ignorance which can be overcome.
Option 1 - I agree it's pretty much a non-starter. However, creating them in
the first place is labour intensive, so why should deleting them be any less
labour intensive, and is that really a problem? If you could (dream dream)
enforce as much responsibility on people for disposition as for creation,
that'd be a good start. (And policies including things like: Keep the last
in an email conversation as long as includes all previous comments - will
help too)

Option 2 - quite possible with the massive improvement in IT - but remember
that an increase in quantity provides a decrease in quality in almost every
case. We will be swamped with information, and it will be unusable in any
practical way. Where DOES it end?

Regards,
Amanda Cossham

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

ATOM RSS1 RSS2