I agree with what Larry said, especially:
"For my money, a "standard" that hasn't been developed according to the rules set forth for Standards Development by organizations whose role that is results in a document that is not much more than a guideline."
However, with NARA saying "Our endorsement approves the current DoD standard as one possible approach to managing electronic records.", it seems that some individuals and organizations referring to these as "standards" (government, industry, de facto, or otherwise) will never go away. Many individuals are looking for a "safe bet" and saying they are recommending something that is a "standard", even for another realm, makes it seem less risky for them to recommend it. They may not welcome the challenging intellectual work and organizational collaboration that real requirements definition entails prior to system selection. They may be personally uncomfortable with requirements definition, have an uncooperative IT staff, need to collaborate with demanding business departments or have marginal budgets to obtain what they need. Citing standards helps their business case incorporate more than their embattled opinion into the selection process.
However, in the end only concentrating on "cost effective solutions that meet our requirements" is really a safe and targeted way to make recommendations.
John
****************************
John Phillips
Information Technology Decisions
www.infotechdecisions.com
865-966-9413
-----Original Message-----
From: Records Management Program [mailto:[log in to unmask]] On Behalf Of Larry Medina
Sent: Monday, June 07, 2010 1:19 PM
To: [log in to unmask]
Subject: What a "STANDARD" is and is not
This has been an interesting discussion, and similar discussions have come
up here over time. First, let me say I spent 8 years as a member of the
ARMA Standards Development Committee, 3 of those as it's Chair. I've been
on the NFPA Technical Committee for Standard 232 "The Standard for
Protection of Records" since 1999. I've served on numerous AIIM TCs, as
well as a few ISO TCs developing Standards since the 1980s as well.
The opinions below are based on this experience and involvement with the
development of Standards, Technical Reports, Guidelines and with the
auditing of compliance against them by organizations.
In the US, most Standards are developed under the banner of ANSI, the
American National Standards Institute. From their Web Site:
Q: What is a standard?
A: A standard is a document, established by consensus that provides rules,
guidelines or characteristics for activities or their results. (As defined
in ISO/IEC Guide 2:2004)
The ANSI FAQ is found here, but the primary principles are listed below the URL:
http://bit.ly/bEcdds
Overall, the Institute provides and promotes a process designed to protect
the rights and interests of every participant through a set of four
"cardinal principles."
* Openness � The ANSI process is fair and open. Any materially affected
and interested party shall have the ability to participate.
* Balance � Participants should represent diverse interests and
categories, and no single group should have dominance in standards development.
* Due Process � All objections shall have an attempt made towards their
resolution. Interests who believe they have been treated unfairly have a
right to appeal.
* Consensus � Agreements are reached when more than a majority, but not
necessarily all, of the participants concur on a proposed solution.
Now, seeing as this discussion was stated about MoReq and we were told that
it applies principally to the EU Communities, and that it is NOT a
'standard', none of this applies to it. It was correctly described as a
model requirements document, and while it provides guidance criteria for
acceptance and a product can be tested against it for compliance that is
accepted within the EU, it's "nice" to consider it here in the US or
elsewhere, but no one HAS TO consider it.
The BSI (British Standards Institute) has similar information about
"Standards" on their Web Site: http://bit.ly/a4xYK9
And so does ISO (International Organization for Standards) http://bit.ly/9c04Mn
The thing that was confusing to me during this discussion was how DOD5015.2
was/is viewed. This document was written by the JITC (Joint
Interoperability Test Command) which is associated with the DOD (Department
of Defense). And it states on their web site: http://bit.ly/9jh2jq
"It is DoD policy that only compliant products be acquired by DoD
organizations. Products that have been successfully tested are listed in the
compliant Product Register."
In 2003, NARA (The National Archives and Records Administration) announced
that it "endorsed the RMA Compliance Testing Program" and in 2008, NARA went
further and endorsed the design criteria 'standard' itself for use by
Federal Agencies. http://bit.ly/ax4wf3
However, the guidance form NARA states clearly in Item 4:
"NARA's endorsement of version 3 does not require agencies to upgrade their
existing RMA software. Agencies should evaluate version 3, in the context of
their current business environment, to determine if the additional
requirements provide benefits to agency programs. Our endorsement approves
the current DoD standard as one possible approach to managing electronic
records."
So while the DOD document is titled "Electronic Records Management Software
Applications Design Criteria Standard", simply including the word "standard"
in the title doesn't necessarily make it one.
The lack of openness, balance, due process and consensus in developing the
document make it much more of a design criteria document, much like MoReq,
than a Standard unless you are within DOD or a DOD Organization.
If you saw "Pirates of the Caribbean", you may recall Captain Barbossa's
comment about the Pirate Code... "And thirdly, the code is more what you'd
call "guidelines" than actual rules."
For my money, a "standard" that hasn't been developed according to the rules
set forth for Standards Development by organizations whose role that is
results in a document that is not much more than a guideline.
Larry
[log in to unmask]
[Yes, it's really me =) ]
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]
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]
|
