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:
Thu, 9 Oct 2008 01:16:32 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (61 lines)
Some great posts and resources here, thanks for raising the question, Sandy!
Your question is essentially technical, but it sparks a concern from my own
experience helping organizations wrestle with ERM, both as an external
consultant and as an internal leader and resource. 

I have found that the biggest challenge rests the organization's grasp of
what it really wants, and its commitment to embark on a course to readiness
for the necessary change.  

Organizations tend to seek technology as a way to simplify or avoid the
difficulty of change (whatever other rationale may be publicly presented). A
Need may be a catalyst, but the technology is, overtly or not, thought to
answer questions that only knowledgeable people can answer. 

Sharepoint aside for the moment, all of the significant applications offer a
greater functionality than a given purchaser may require.  Aiming for DoD
5015 compliance, Sharepoint will similarly offer you more than you may
need--and the complexity lies in understanding the functionality that you
CAN have and that which PRACTICALLY supports your needs.  In this, it is
absolutely critical that your executive sponsors understand the choices that
they make in approving your recommendations (unless of course, you are
senior enough that you are prepared to wear future liabilities).

Over and over (and over) again I see corporations that have spent millions
on one product conclude that "it doesn't work" only to purchase another that
"doesn't seem to do the trick".  Somebody gets moved on and it starts over.

I recommend focusing your efforts on defining all required functionality,
THEN on all available functionality, THEN on the factors that determine
selection and priority. Critical considerations will include the state f
readiness of all affected staff (reception desk to CEO).  Your strategy for
getting support for implementation and use (!) must be in play.  If you do
not have a strategy, your project is at risk. 

In a recent role leading development of a pilot in a 100,000+ strong
organization, the internal team took about a year to figure out the
implications of what each functionality would mean in operation and examine
sync with policy. Typically, this work created knowledge that was far
removed from ultimate decision makers whose organizations would be affected
(and as such remains  vulnerable to other agendae). The sync with policy is
important: will the product drive your practice, or will the product support
your practice? Does it require task assignments that fit your authority, or
require support beyond that? Does it change the establish division of
accountabilities?

The key issue will be people. As RMgr, a solid grasp of the possible, the
necessary and the ideal is important.  But it is management of change that
will make the difference.

You likely have given thought to a lot of this, but I hope there may be
something helpful here. Good luck!

John
[log in to unmask]
IRM Strategies

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