Kimo Crossman wrote:
> Google, the the SOTF staff (a government entity) has the documents
locally
too no permission was given to allow them to delete the local copies.  

Its unclear to me whether you are saying that the record copy resides
with the SOTF staff, or with Google, or if Google is being used simply
as an "access copy".

> Who cares, storage is cheap.  Also what about the staff time to index
and
sort through what should be kept or not and then later incremental
destruction.

The "storage is cheap" statement is a very big red flag to me, generally
indicating potential problems down the road, particularly with migration
and maintenance. Note also that disposition is generally applied on a
record series basis, not necessarily an individual document basis. In
addition, there are already automated solutions - just not with Google
(and especially not with a "free and immediate" service). Nor would I
assume Google will develop any. Finally, what is the risk exposure for
SOTF? Are you sure you really want all of this stuff to be sitting
around for 100 years?

> None - but this is a free and immediate solution good for at least ten
years which is longer than the 90 day (clean mailbox) or even two (State
min
retention) or five year (DVD dies) currently

If the state minimum retention is 2 years, why are you keeping it
permanently? I would suggest sticking with the minimum 2 year retention,
then many of my concerns go away. Also, in building a program, one
common mistake I see is a tendency to understate the potential costs of
choices - such as 100 year retentions. This lets management off the hook
in the long term, and may come back to haunt you.

> Native formatw/metadata is included with PDF/A version but deal with
this
with automated fashion for next format refresh in 10 or so years.
Either
SOTF staff or Google will handle address at that time.

Again, I would not expect a free service to handle this. In addition, if
SOTF cannot handle it now, what assurance do you have that they will
handle in 10 years? We've been waiting for the "technical solutions" you
have such confidence in for several decades. I'm not sure I would assume
they are coming any time soon. Finally, how many users really want to
see this stuff? Again, a lot of my concerns have much to do with "100
year retention".

Note that I am a consistent advocate for transparent and open
government. One of the barriers I have seen to that is a reliance on a
quick and cheap technical fix to solve immediate access issues to the
detriment of basic long term records keeping issues, which are either
not important because "storage is cheap", or "someone else will take
care of it". In essence, it's a cop-out that justifies a lack of current
investment in real long term solutions, facilitated by the fact that
much of the damage that occurs in records occurs years down the road,
not immediately. Note that the only real long term solution is "current
investment". 

I can say without reservation that every system I have seen implemented
with such an approach has crashed and burned within 5 - 10 years,
causing significant damage to records preservation, and even significant
and (in my opinion) unnecessary costs. "Current investment" gets sucked
up resolving past problems, instead of meeting future challenges.

If the records are truly 100 year records, I would suggest you address
that issue as a separate subject, and don't imply that somehow Google is
going to solve this problem for you in a quick and cheap manner, in
particular if there is an expectation that whatever problems will occur
within the next 10 years will somehow be "solved". My experience,
unfortunately, has been the exact opposite.

Dwight Wallis, CRM
Records Administrator
Multnomah County Fleet, Records, Electronics, Distribution and Stores
(FREDS)
1620 S.E. 190th Avenue
Portland, OR 97233
Phone: (503)988-3741
Fax: (503)988-3754
[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]