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:
John James O'Brien <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Wed, 20 Feb 2008 09:02:58 +0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (102 lines)
Further to the discussion,  some observations on "Big Bucket" versus  
the generally undefined alternatives ;-)

I agree that a Big Bucket approach makes the system simpler for users  
to grasp and that the approach may be less feasible with paper  
records.  So, not disagreeing with Brent but feel the discussion  
needs to go deeper (noting that a file plan that presents thousands  
of choices to users and contributes to the challenges inherent in  
managing records is often the result of applying one strategy over  
multiple needs).

Provocative inquiry:

When we say "big bucket", do we mean defining business functions at a  
level so high that retention is aggregated at the highest level so as  
to guarantee longer than necessary retention of record material?   
Probably not--but perhaps so depending on the specifics.  Specifics  
are not big bucket.  The user may be given a big bucket  
representation of the scheme, but the scheme itself may have smaller  
buckets.

Clearly, criteria to set the size of the bucket is critical--it needs  
to be just right, but for whose purposes?

An area of confusion can be in the different viewpoints of users and  
managers of the information resource.  An enterprise does need a  
comprehensive understanding of what it knows and holds in order to  
manage liability, compliance, quality, etc.  An individual user does  
not need to be presented with a comprehensive picture that may  
overwhelm, seem irrelevant or otherwise get in the way of RIM  
compliance and utility.

Random, user generated tagging has value to individual users and tag  
use can be tracked and aggregated/measured so as to discern common  
language for greater utility within an enterprise. Still, this is  
more access than management.  Meta tagging for management purposes  
still requires an understanding of the purpose served by information  
content - and whatever the bucket size that is advisable for end  
users, it seems to me that an accountable organization needs to  
understand its holdings beyond such an aggregation.

Again, users and accountable managers have different needs. Records  
managers must understand and meet the needs of both.

So at the risk of getting more technical, document tagging versus  
meta data within file plans implies consciousness of what meta data  
is required for a defined purpose served within the file plan and  
what metadata can be attached across multiple groupings of document  
types for defined purposes.  There is either an existing or required  
mapping of data to functions at some level. To accomplish this,  
somebody has gained a more granular understanding of  the total  
information resource (or rather, has developed capacity to grapple  
with more granular issues).

This comes back to deciding the size of the bucket for relative  
purpose (and these differ dramatically among users relative to their  
own purpose within an organization). I urge caution in the use of the  
term--it is so attractive as a concept (brings forth the "phew,  
that'll be easier!") that the work behind it may not get done.

I had the dubious pleasure of straightening out a system in the Parks  
service many years back in which they had perfected the easy filing  
big bucket approach with whole aspects of the service assigned one  
classification code--a nightmare.  I have also given my head a shake  
on discovering full implementation of a  comprehensive, enterprise- 
wide scheme in a unit of limited functions requiring only a subset of  
the scheme--thousands of categories implemented with artful  
interpretation (who says workplaces can't be creative?!) that made  
retrieval and management virtually impossible! In both cases, the  
organizations sought the "easy" way out by adopting an answer that  
worked for some other organisation, some other work culture, and  
slapped it over a workplace for which each was totally the wrong  
solution.

We can get around our responsibility to know what the needs are, the  
drivers both authoritative and social, the attributes of media and a  
host of details that inform our strategy, and its best chance for  
implementation.  Yes, that may mean fitting our tactics to how users  
actually use technology--with a behind the scenes logic that protects  
the corporate interests.

It's what makes RM fun, eh?!

Thoughts?

John James O'Brien, BA, CRM, MALT
[log in to unmask]

Partner & Managing Director
IRM Strategies
Hong Kong: +852 3101 7359
Bangkok: +66 2 207 2530
www.irmstrategies.com

Associate Partner, S4K Research
Stockholm www.s4k.com

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