LISTSERV mailing list manager LISTSERV 15.5

Help for RECMGMT-L Archives

RECMGMT-L Archives

RECMGMT-L Archives


Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font


Join or Leave RECMGMT-L
Reply | Post New Message
Search Archives

Subject: Re: Section of a Records Management Application
From: Larry Medina <[log in to unmask]>
Reply-To:Records Management Program <[log in to unmask]>
Date:Thu, 18 Jun 2009 10:52:45 -0400

text/plain (84 lines)

Another case of the 6 Blind Men and the Elephant

If you closely review the JITC web site, which
many of us have unfortunately HAD TO DO over the past years, they use the
terms "compliant"and "certified" almost interchangeably and in case anyone
wants to know, it's a Design Criteria Requirement, it is NOT a Standard. 
Simply putting the word standard in the title doesn't make it one.  Products
are tested to ensure they are COMPLIANT with the design criteria, then they
are placed on a list by JITC stating they are CERTIFIED as being compliant.

This was initially designed for the Department of Defense and all of its
Components- if they (or any of their Contractors) were going to purchase an
RMA for use, it was required to have been certified as compliant with the
design criteria established.  That doesn't mean every system on the list is
identical, simply that it has the listed capabilities and can perform all of
the functions required by JITC.

Following that, and absent of any other criteria, many other Federal
Agencies (and private entities) bought into this because the products on the
list had demonstrated their ability to meet certain minimum requirements and
basically, "if they were good enough for the DOD, they were good enough for

In late 2000, NARA issued guidance  they were
going to inform agencies they endorsed the JITC testing process, but they
also placed a strong caveat on that endorsement:

"In announcing NARA's endorsement of the JITC certification testing program,
we will also need to draw attention to the fact that the JITC functional
testing does not evaluate a broad range of other important technical and
business requirements that must be considered when automating records
management (e.g., human factors, ease of integration, scalability, system
performance, reliability, provider stability, etc.). We will therefore
encourage agencies to address these additional requirements separately,
should they choose to automate records management with a
JITC-5015.2-certified product."

Agencies have not been quick to move on developing their own criteria to
ensure applications meet their other needs that NARA identified were missing
in DOD 5015.2, evidenced by the CREW Report
issued last year, which is 8 years after NARA's original guidance.   And
yes, NARA has issued subsequent guidance endorsing later versions of DOD 5015.2

Similarly MoReq is NOT a Standard.  From following the original issuance of
MoReq and the subsequent entire re-writing and issuance of MoReq2, by their
own admission on their web site  it is a "Model
Requirements Specification" that is "intended for use throughout the
European Union" but can also be used elsewhere. It was developed on a for
pay basis by a consulting company, who also now tests for compliance with
the specification

Neither of these documents in and of themselves are complete or necessarily
the tools any organization (other than those in the DOD or EU requirements
umbrellas)  should be using to determine if an ERMS/RMA/CMS is properly
suited to their specific needs or requirements.  As Peter stated earlier in
this thread, and MANY have stated repeatedly when this issue comes up, every
organization needs to develop a Functional Requirements Document based on a
Needs Assessment for records management obligations to satisfy their
specific situation.  It has to be able to allow you to meet any regulatory
or legal requirements placed on your market segment, industry, location of
business or other guidance placed on your organization.  It also needs to
accommodate any business needs you have for distribution, privacy
protection, information classification, disposition, or other aspects of
your business model.

Both documents, along with ISO 15489 (which expired in 2006 and is far past
due for a revision), and other guidance such as what is found in 36CFR Part
1234, or other sources are also excellent tools to assist you in developing
a set of questions that you need to have answered when evaluating
applications to determine if they meet YOUR NEEDS... but just like buying a
car, refrigerator, underwear, peanut butter, or anything else... what works
for someone else may not work for you.

[log in to unmask]

Wonder if we should start asking again about making up a set of "Listserv
FAQs" with these types of issues listed in them so we can stop re-hashing
this stuff?

List archives at
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]

Back to: Top of Message | Previous Page | Main RECMGMT-L Page



CataList Email List Search Powered by the LISTSERV Email List Manager