Hi Deb, thanks for the additional information.

As I'm sure you know, there are at least two requirements documents that
need to be developed - business requirements and functional requirements.
Be sure you know which kind of requirements they are asking you to
identify, if not both.  I am not clear on which, and there are still a
zillion things I could ask you, so I'll offer these principles I've picked
up over the years that span both business and functional issues in lieu:

1. If the entity is private (not subject to FOI laws in particular, or
heavily regulated on communications, like broker-dealers), then the vast
majority of email traffic is either 1) complete junk, or 2) tranistory,
neither of which require long retention periods.  The amount of content
that represents "official records" should be small; but if not, that can
often be addressed through proper and regular training on why not to use
email for certain tasks, and what processes/systems to use instead so
capturing records is easier.

2. Email users do not want to leave their email interface in order to
manage email so make sure any "profiling" tasks can be done within
Outlook (if you ask them to manage it at all ... see #3).

3. Application of retention and disposition rules should be transparent to
the end user whenever and wherever possible.  Strive to automate
classification, retention and disposition.  It will add a ton of
defensibility to your email mgmt program, too, as a result of consistent
application of rules.

4. *If* you *must* rely on end-users to classify email, the less
choices the better.  More than 3-5 in a list of choices and they will just
pick the top one or the one that gives them the longest retention period
regardless of content ...which results in mis-filing and inappropriate
application of retention rules.

5. This is the important one ... if end users feel that the rules/process
is either 1) too onerous, or 2) gets in their way of actually getting their
job done, they will create a "black market" and squirrel email away
somewhere ... which just moves the problem, it doesn't solve it (and may
create new problems).  Make sure that your requirements focus on the
business first - creating an environment in which the job can get done, not
just on creating an ideal governance environment.

Others have noted standards (like DoD 5015.2) that you can use for
functional requirements (and don't forget to check product vendor
information as well).  On the business requirements side there are numerous
books, whitepapers, research papers and so on (I believe the ARMA
International Educational Foundation has a research paper on email mgmt -
for free: www.armaedfoundation.org).

Again, it will be very important for you to understand what kind of
requirements they are asking you to provide.  That will help point you in
one direction or another.

Good luck!
Julie


-- 
Julie J. Colgan, CRM

[log in to unmask]
http://twitter.com/juliecolgan
http://www.linkedin.com/in/juliejcolgan

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]