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:
Jesse Wilkins <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Tue, 9 Feb 2010 12:45:49 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (43 lines)
I see much more agreement than disagreement in this thread. But I think we're fundamentally speaking past each other. Advance notice: long response, feel free to discard. 

1. Backups are backups and should be treated as backups. It is not a best practice to retain backup tapes for long periods of time for a dozen different reasons: cost, readability of backups over extended periods, possibility of having to produce at significant cost and potential liability, and others. Obviously backup tapes may need to be produced but the courts seem to be moving in the direction of Zubulake and the FRCP in looking for accessible sources rather than less- or in-accessible ones such as tapes, forensic imaging, etc. (absent spoliation). And backup tapes retained longer than primary retention is just indefensible absent a legal hold. 

2. Users who are not records managers will not go through 100-150-200 messages a day to determine whether or not they are records. Period. It doesn't happen except by great exception. Larry may do it, I may do it, everyone on this list may do it, but I don't believe anyone who tells me that all of their users manage their inboxes appropriately all or even most of the time. And of course this assumes that there is an ERMS, ECMS, email "archiving" "repository", or somewhere else to put them besides a file share (which is then just a case of pushing the balloon). 

To echo Larry's request, anyone want to document an organization they are at, of any size, where the entire organization manages their email records as records *and* keeps their inboxes clean? Managers, IT, sales staff, and users are included; no points if only the RM staff does it or if it's a tiny, tiny organization. 

3. Email is not a record series. :)

4. You're right that of 150 messages a day, not all are business-related. But they still have to be dealt with. 30 seconds per = 4500 seconds = 1.25 hours a day - no responses, only filing 5% of them (or 7-8 per day). Again, you're a RM professional and I'm sure are much faster than that. But most users aren't - and that's my point. 

5. Your response also only identifies record or not-record. That might work for a RM professional, but it doesn't work for a user. Messages going back & forth about a contract in draft: record or non-record? I say working files which should be retained while they have business value and then discarded absent any statutory or defined operational requirement to retain them. It's the same as a tickler file. Once something comes out of the tickler file, it is then either a record and saved appropriately or not and not; my point is that expecting users to make an immediate decision is just not that helpful in a significant number of cases. It would be ideal, but it's a gray world out there and if you force users to choose black or white you'll either discard stuff early or late.

6. I'm not using 1-2 years as a retention period in the same way as you are. I'm suggesting that there is a broad category of "stuff" which may or may not be records but which clearly has some business value for some amorphous period of time which will be heavily dependent on what the message relates to. That "retention" gives users 1-2 years to complete a project, contract, deliverable, etc.; by the time that decision point is reached, all of the other transitory, ephemeral, non-business stuff has been automatically deleted (training, legal hold, etc.) so now instead of wading through 150/day x 1 year, 2 years, more....the user is most likely wading through the contents of a folder, and even if it has tons of stuff in it, it's all related and easily declared & classified should it be warranted. If the user isn't using lots of folders, it's still likely that the 1-2 year retention container would have maybe 10-25% of the original volume to wade through. 

7. I don't jump off bridges, and I'm not scared to blaze a trail where relevant, but I also know that when lots of people do the same thing, not all of them are mistaken, negligent, evil, untrained, etc. They have found a way that works for them, that contains costs enough, and that doesn't allow perfect to be the enemy of the good. Their program works for them and is seen as a benefit to the company rather than a drawback or a cost center full of harbingers of doom. 

8. <snip>There are instances where thoughtful implementation of a "tool" can assist
an organization in gaining some control over their information assets, but
many organizations can and have done this with training, practice and policy
implementation with and/or without the addition of another tool.</snip>

True - though you said with and/or without, so since every org is either one or the other, it'd have to be, no? :) Anyway, my point is this: Email ain't a series. But email presents unique tactical challenges we don't see with paper and even most electronic records. On the one hand, we said the same thing when computers and word processors were introduced. The tactics of records management had to change with the advent of born-digital documents. We had to be much more concerned with internal metadata than we were with paper. We have to worry about different tactics for preservation over time, and the issue is more acute. I'm arguing the same thing has taken place with email: volume is an order of magnitude or more higher than with other types of electronic documents; the ease of creation, forwarding, and replying is different; the formality and combining of different topics and even personal/private topics is much worse; attachments present a much more significant problem; and the list goes on. Same strategies, to the extent they are applicable; different tactics. 

And we're now looking at another shift - or actually three: the shift from onsite implementation to offsite (Gmail, Google Docs, FB, etc.); the shift from records I create to streams that others can add to, respond to, comment on, outside our control (related to the first); and the increasing shift from records as individual items to record as indistinguishable from the system that created it. This last arguably is nothing new - this is the issue with records management of databases (and most of these systems are fundamentally databases + XMl or HTML-based templates). 

But the point is that while the strategies and concepts of Stephens, Robek, Penn, Saffady, etc. remain applicable, the tactics have to change. It does a records manager no good today to rail against Facebook, Twitter, and other tools because they aren't controllable (they are), they don't create records (they might), they DO create records (often secondary or tertiary copies at best), they're too hard to provide for FOIA or discovery (so is email, and databases, and text messages, etc.), etc. The fact is that lots of people are using them for business reasons and it is incumbent upon us as a discipline, as a profession, and as professionals to figure out how to apply those strategies and appropriate tactics. And we have to do it in the real world, where real, non-RM users are the ones using these tools at the office, at home, on their own laptops at Starbucks, and on their shiny new iPhones and iPads. 

Off my soapbox and back to records management policy development,

Respectfully submitted on behalf of myself and no other company, organization, association, entity, or board of directors,

Jesse Wilkins, CRM, CDIA+, ecmm, emmm, ermm
[log in to unmask] 
(303) 574-0749 direct
Twitter: http://www.twitter.com/jessewilkins 

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