I'll reintroduce myself briefly before I write further.  I'm a systems analyst in the IT department of the University of Texas System.  I work with the day to day operation of two document management systems, including application maintenance and architecture. I help manage a decentralized scanning and born digital storage environment. I'm also asked to do wider document management work, including researching document storage solutions with e-mail in mind.  Prior to taking on this role I worked for approximately 3 years as a records analyst for a Texas state agency. I came into records management as a geek with an interest (but no degree) in library science.  My bachelor's degree is actually in Psychology!

George wrote:  "I'm not sure an organization has to declare explicitly that they are using Second Life for business purposes for recordkeeping to be required.  Not much different from wikis and blogs used to discuss official business."

I've really enjoyed this topic so far! The list becomes invaluable when take the opportunity to bounce around ideas in a professional way, whether agreeing or not.  In this case, I agree with George. An organization shouldn't have to declare an intent to manage records with each and every new application that comes over the horizon.  I'm probably stating the obvious, but this is why records management documentation often breaks down into policies and procedures, something my organization is grappling with right now.  Policies often state that an organization will manage records, no matter the medium (maybe we need to add environment?), for this very reason.  Procedures define how this will occur.

With that said, records management is often the last thing on people's minds when a playing with a new piece of software.  Employees are encouraged to "think out of the box" and imagine the efficiencies gained with shiny new cloudware and virtual universes.  This old cliché works because people are LITERALLY thinking out of the box. There isn't a physical box to remind people about records management when there's no paper to manage!  

While an organization may not have to declare that it will manage the records created with a new piece of software, it doesn't hurt to remind employees that RIM is part of their duties.  My experience in IT shows that while RIM professionals understand that new technologies don't take away the need to create and maintain records, users aren't generally aware of this. IT staff and users get so caught up in the excitement of it all that testing rapidly becomes deployment without a formal plan, and creating/storing records falls by the wayside.  This may not happen in all environments, but I suspect this scenario isn't too far from the norm for a lot of IT shops.

This is why I wrestle with the notion that maybe records management shouldn't be COMPLETELY transparent on the desktop.  I like the idea that records management should be as easy as possible for the average Joe (or Jane), but if users don't understand basic RIM concepts there's a bigger risk that technologies will be fully implemented before RIM is taken into consideration. Then the records manager in the organization needs to fight uphill to put RIM in place after the fact. I've seen this unfortunate fight happen over and over again in my brief 6 years in the field. An employee who understands the importance of records management is far more likely to investigate new software with RIM in mind than someone who doesn't realize that records management is taking place behind the scenes.

This has probably been a soliloquy in RIM 101 for the most part, but I find it useful to state the obvious once in a while.  It gets me looking at the big picture again, and reminds me about why I do the things I sometimes instinctively do.


Alicia Shelton
Systems Analyst
The University of Texas System

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]