On Why I No Longer Support the DoD 5015.2 Standard

By Don Lueders, CRM, CDIA posted 05-27-2013 13:53

  

Very few people outside of the Department of Defense have more firsthand experience with the DoD 5015.2 Electronic Records Management Software Applications Design Criteria Standard than I do.  I first began working with the Standard in the late 90s when I was hired as consultant for a small company called TrueArc.  TrueArc was the new name for a company called Provenance.  Provenance had one product, a records management application called ForeMost.  A few years before I joined the company, ForeMost had become the first records management application to be awarded DoD 5015.2 certification. 

Over the course of the next 12 years or so I played a major role in the design, creation and certification of four entirely new electronic records management applications (including two SharePoint-based solutions) and consulted in the product design or certification process of at least a half dozen others. 

In the past I have supported the Standard because I honestly believed that, while it certainly wasn’t perfect, it nevertheless provided a reasonable framework for managing records in an electronic environment.  However, over the last few years that opinion has changed considerably and I have come to view the Standard as both an obsolete relic of 20-year-old business model and a failed attempt to provide effective functional requirements for managing electronic content through the final stages of the information lifecycle.  And I believe as a Certified Records Manager and dedicated Information Lifecycle Management professional, I am ethically obligated to state my opinion publically. 

 

________________________

 

The first version of DoD 5015.2 was released in 1996 after many months of extensive research by dedicated analysts at the Department of Defense with the support of a number of private sector Records Management professionals providing consultation.  From a technical perspective, 1996 is several lifetimes away.  For those of us who are old enough to remember, the early 90s saw the creation of a new set of collaboration products which, at the time, were called ‘Document Management’ applications.  There were many vendors creating many different versions of Document Management products, but it wasn’t long before a small number of products captured the significant majority of the market. 

For the most part, these solutions provided the basic functionality required to manage unstructured content through the early stages of the Information Lifecycle: Creation, Distribution and Use.  Most products had some rudimentary features that provided limited support for the fourth stage of the Information Lifecycle, Maintenance.  None of the major Document Management solutions natively supported the last stage of the Information Lifecycle, Disposition.  This limitation precipitated the creation of a new software market segment, the Records Management Application. 

Just as with Document Management applications, many new Records Management products were released over a short period of time, but only a handful of solutions were broadly adopted by the general market.  (The significance of the market-driven evolution of these product sets should not be underappreciated. The notion of completely different applications managing distinct stages of the Information Lifecycle helped perpetuate the belief that unstructured content can be separated into non-record ‘documents’ or official ‘records’ -  when in fact that distinction is completely irrelevant given that all of this material is discoverable evidence in a legal matter and must all be managed accordingly.  I believe the idea that unstructured content can be segmented in ‘records’ or ‘documents’ has caused incalculable damage to the Enterprise Content Management industry and confused users, vendors and even other Records Management professionals ever since.) 

Even though a few forward-thinking vendors were just beginning to integrate their Document Management solutions with existing Records Management applications and creating the first rudimentary Enterprise Content Management solutions, separate solutions for ‘document management’ and ‘records management’ was the state of the market when the DoD decided to create the first version of the Standard.  And the DoD wanted to standardize how they managed their ‘records’ across all branches of the Service, so it made sense for them to build a standard around functionality that focused on the end-state lifecycle stages that were currently being addressed in existing records management products - at the exclusion of most other lifecycle management features that were included at the time in document management applications. 

Interestingly, this explains why the DoD named the 5015.2 Standard the ‘Electronic Records Management Software Application Design Criteria Standard’ and why the Standard itself says it “sets forth mandatory baseline functional requirements for Records Management Application (RMA) software used by the DoD Components in implementing their records management programs”. 

The problem here is obvious to anyone even remotely involved in the Enterprise Content Management industry: stand-alone Records Management applications haven’t existed for almost a decade.  The first few years after the turn of the last century saw a flurry of acquisitions by the established Document Management vendors of the smaller Records Management application companies.  These products were integrated (with varying levels of success) and the first Enterprise Content Management (ECM) solutions were the result.  These new integrated solutions were the first to provide customers with the ability to manage unstructured content across the enterprise throughout its lifecycle.  From creation to distribution, to use and maintenance and to final disposition, content was being managed cradle-to-the-grave in one unified solution.

Yet the DoD Standard never adapted to this fundamental shift in content management technology.  Through more than 17 years and three versions of the Standard, it has steadfastly remained a very detailed set of functional requirements for a records management application.

I remember when I was young, my dad would often carry a beeper with him in case his office needed to contact him quickly.  At the time, I thought that was pretty cool technology.  Beeper use was fairly common back in those days and I imagine there was at least one industry standard that they applied to. 

But of course technology evolved and beepers have been replaced by cell phones, an exponentially better solution to the problem that beepers addressed. 

The cell phone industry has a myriad of standards to which it complies.  And I wouldn’t be at all surprised if those standards don’t include some small set of requirements left over from beeper technology.  But those standards address the current state of the technology: cellular phones, not beepers.

The DoD 5015.2 Electronic Records Management Software Applications Design Criteria Standard is a beeper standard in the Age of iPhones.

 

________________________

 

I had no input on the original version of the 5015.2 Standard.  Nor did I provide any consultation on either of the subsequent revisions.  If I had, I am under no illusion that I would have done a better job designing the Standard than the dedicated people at the Department of Defense have done.

That said, there are about 170 unique functional requirements in the DoD 5015.2 and I can tell you from experience that all but a very few of them are either irrelevant, obsolete, over-engineered or completely unnecessary for managing the final stages of the information lifecycle of unstructured electronic content given today’s technology. 

A detailed description of the problems with each requirement in the Standard would fill a good-sized book and (despite overwhelming appearance to the contrary) I am trying to be brief - so I will limit my discussion to concerns I have with a few high-level groups of requirements. 

If you are not entirely familiar with the certification process, it is important to keep in mind that DoD 5015.2 certification is an all-or-nothing proposition.  In other words, the product vendor hoping for certification must meet every one of the 170+ requirements to be granted certification, so no one set of requirements is more important than any other.

Cutoff Processing

As a Certified Records Manager, I have a fairly well documented understanding of how organizations manage records through their lifecycle.  Over the course of my career, I have only occasionally heard mention of organizations including a cutoff process as the Standard defines it as part of their records management practices.  And these organizations have always been some part of the US Federal government and cutoff has always been limited to managing physical (e.g. paper) records rather than electronic records.   

I do not see any real benefit to including a cutoff process in managing electronically stored records.  The notion of a cutoff was created to facilitate the bundling of (paper) records that expire at different intervals so the transfer or destruction of those records could be carried out with more efficiency.  (For example, a paper record due for destruction on June 3rd, one due for destruction on June 17thand one due for destruction on June 25thwould all have Cutoff Dates of June 30th, would all be put into the same folder and all destroyed during the scheduled monthly records disposition process.) 

Because the destruction (or transfer) of records can be automated in an electronic records management environment, the value of cutoff processing has been completely eliminated.  Yet there remains dozens of Cutoff Processing requirements in the DoD Standard and vendors have spent millions and millions of dollars developing functionality to meet those requirements. 

Metadata Management

There are two iron-clad rules in effective records management: 1) minimize the burden on the end user and 2) create accurate record classification strategies.  Break either of these rules and your entire solution will be rendered useless.  The Baseline Compliance Test Procedures for certifying against the Standard is full of countless metadata requirements for a wide range of record types.   The level of metadata tagging suggested by these procedures would almost certainly impose an undue burden on any organization’s end users and would undoubtedly result in an extremely low (perhaps even zero) adoption rate. 

In addition, there are a number of very specific, sometimes obscure, requirements for how certain properties must behave.  Meeting these requirements is often difficult for product vendors because their metadata properties are normally a core component of their solutions and usually very difficult to modify.  But the solution vendor is forced to create these unique metadata features that, at best, provide marginal utility in a production implementation. 

Email Records Management                                                                                   

The Standard has scores of very clearly defined requirements for email records management.  All but a very few are wholly unnecessary and simply won’t be used in a real-world production environment.  As anyone who has been employed in the last 20 years knows, the proliferation of email has been explosive.  More than any other record format, the process of declaring an email record must be extremely simple.  Any solution that is the least bit taxing on the end user is certain to fail. 

Yet the Standard still requires incredibly complicated (and ultimately laborious) email records management functionality for product certification. 

Is it nice, for example, to be able to classify an email and all four of its attachments into different categories across the file plan, each with its own unique set of metadata and each with a link to the email and the other attachments?  Yeah, sure.  Will anyone in a real world implementation ever actually do that for one email, much less the multiple email records they may have to declare every day?  No, absolutely not. 

Non-electronic Documents 

As the title of the DoD 5015.2 Standard suggests, its intention is to provide procedural guidance for managing the lifecycle of electronic records, yet it includes some very specific requirements for managing non-electronic (i.e. paper) records, as well.  Interestingly, these requirements are not at a level that would allow an organization to realistically manage all of their non-electronic records in the same certified solution that manages their electronic records.

There are separate standards for physical records management solutions and some great products with excellent integrations with existing electronic Information Lifecycle Management applications.  The DoD Standard should defer to them and focus exclusively on the features and functionality required for managing electronic records. 

Records Relationships

The Standard requires the ability to associate one record with another through records relationships.  A certified solution must be able to create custom hierarchical types, as well as custom peer-to-peer relationships types that can be applied to two or more records across the repository. 

These relationships are expected to be part of the record’s metadata and managed along with the retention and disposition of the target record (e.g. if Record A has a relationship with Record B and Record B is destroyed as a result of meeting the end of its retention period, Record A’s relationship to Record B should also be destroyed.)

Years ago when virtually all of our records were on paper it made sense to have a few relationships types that could be applied from one record to another (cross-reference and convenience copy are two that come to mind).  But things have changed since then.  Given today’s technology - especially with respect to search and retrieval capabilities - this functionality, particularly at this level of complexity, is almost certain to go completely unused in a production environment. 

Metadata-based Security

There are two primary forms of metadata-based item-level security required by the DoD 5105.2 Standard, ‘Supplemental Markings’ and what I’ve always referred to as ‘Access Control Columns’.  Supplemental Markings are required properties on records (or ‘folders’), while one or more Access Constraining Columns can optionally be applied to records as necessary to meet the particular record’s unique security requirements. 

The security provided by Supplemental Markings (SMs) is similar in most ways to that provided by Access Control Columns (ACCs) except for a few small differences.  To be as brief as possible, a user or group of users is assigned predefined SM values, such as NOFORN or FOUO, and one or more of those values are optionally assigned to individual items in the file plan.  In order to have access to those items, a user or group must have all of the values assigned to them.  (As an example, if a user is only assigned NOFORN and the item he wants access to is assigned NOFORN and FOUO, he would be denied any access to it.)

ACCs are user defined fields that can optionally be designated to support item-level access control.  For instance, a property could be created called ‘Region’ and it could be designated as an ACC.  It could have three predefined values, Region A, Region B and Region C.  One or more of these values could be assigned to a user or group and one or more of these values could be assigned to an item in the file plan.  However, unlike with SMs, a user or group only needs to be assigned one of the values to access the item.  So, if a user is assigned a Region value of ‘Region A’ and an item is assigned values ‘Region A’ and ‘Region B’, he would still be granted access to the item.

Used separately, these item-level security requirements can become very complicated quite quickly when implemented in a production environment.  But, technically speaking, they must be able to work together, as well.  So it is very possible a scenario may occur where a single record has active Supplemental Marking security requirements and one or more Access Control Columns.  Given the tremendous volumes of records in most mature repositories, this potential real world scenario – which product developers must consider and test for - would produce a mind-boggling level complexity and render the entire solution unmanageable. 

Product vendors have spent countless hours developing features that meet Supplemental Markings and Access Control Column requirements.  Unfortunately, I would be very surprised if there are any organizations out there – public or private – that actually use them. 

________________________

By themselves these design flaws are problematic enough, but they unfortunately become compounded by the certification process itself.  The 5015.2 is a detailed description of how the US Department of Defense wants to manage its electronically stored records.  The processes, procedures, roles and permissions are all designed to meet the specific requirements for records management functionality in a DoD repository.  In this respect, the 5015.2 more closely resembles a solution requirements document than an application standard.  Yet the Standard has been widely adopted by non-DoD agencies, State and Local governments and countless private sector organizations in the US and across the globe. 

Standards are meant to define solutions to problems experienced by an entire market, not one particular customer. But vendors are forced to meet every requirement in the Standard (as interpreted in the official Baseline Test Procedures) or risk failing certification. 

For example, the Standard requires that a certified solution allows a user to file a single unique record in multiple locations in the file plan, maintain links between them and manage each filing according to the retention and disposition requirements assigned to the record category or folder into which the record has been classified.  From a technical perspective, this is an extremely complicated requirement and product companies spend thousands of man hours and hundreds of thousands of dollars creating functionality to meet it. 

Yet I can’t imagine why this requirement is included in the Standard at all.  This isn’t something that was ever required in paper-centric records management.  In fact, it wouldn’t have even been physically possible with non-electronic records.  This requirement is just one of several in the Standard that make me sometimes wonder if its designers sat back and came up with ideas that started with the phrase, ‘Wouldn’t it be cool if we had a requirement that…’, but never actually justified its inclusion from a market-wide best practices perspective.  

My other primary concern with product certification is that what passes for compliance with any particular requirement seems to be completely arbitrary.  No consideration seems to be put into the idea of whether or not the solution is a realistic interpretation of the requirements that would be readily adopted in a real world deployment. 

For instance, I’ve seen solutions (none of which I’ve designed) that manage retention and disposition workflows that require the user to suspend the workflow when a particular event occurs and then restart the workflow at the end of a given retention period.  But the retention period could be 25 years or more.  Is that a valid solution to the problem?  Does anyone really believe that an organization would maintain a suspended workflow – like a car idling in your driveway – for 25 years?  How about 10 years?  Or five?

And I’ve seen certified email solutions – again, not of my design – with declaration strategies that require the user to move the email to a managed folder, add some metadata properties, wait (usually overnight) for the system to route the email into the records repository, log into the repository, navigate to wherever the email record was routed, add additional metadata values and finally approve the email record for classification into the file plan.  

I am not arguing that these examples of certified solutions don’t meet the letter of the law for their particular requirements.  Technically speaking, they do.  What concerns me as an experienced Records Management professional is I am certain beyond doubt that they would never actually be used to manage anyone’s records. 

________________________

Standards play a vital role in virtually every industry.  They are essential to progress, particularly with regards to information technology solutions.  I thoroughly believe in standards and I support them completely.  I just can no longer support this one.

  ________________________

[Editor's Note: Don's article has sparked quite a bit of debate, both below and in two separate blog posts:

Mark Mandel: I Support DoD 5015.2; and Encourage ALL Federal Agencies to Adopt It

Ron Layel: To Support or Not Support the DoD 5015.2 Standard (Some pet peeves and views on the debate from a RIM practitioner’s perspective)

Enjoy them both; and the conversation.]



#Records-Management #DoD5015.2Standard #ElectronicRecordsManagementSoftwareApplications #InformationGovernance #ERM #ElectronicRecordsManagement
17 comments
5415 views

Comments

08-13-2013 09:38

I have read your blog post, Mark. I appreciate your tenacity on this, but we are going to have to respectfully agree to disagree here. The DoD 5015.2 model for records management has been a staggering failure. (Please note my latest AIIM Experts blog post.) Keeping it because it includes a few metadata definitions, which can fit on a one-page document, just doesn’t make sense. Adding additional requirements makes even less sense.

08-07-2013 10:27

Don, please see my blog on this topic. I agree on the details of your comments about flaws in the standard. However I strongly disagree with your opinion that we should drop it entirely.
The standard has a number of strengths around metadata requirements, forensic destruction of electronic files, and transfers that, if followed, provides much needed consistency across agencies.
The fact that the standard includes many features that most agencies will not use, and does not address some that should be used, to me is less important than the consistency enforced by the metadata requirements.
All ECM/RM vendors except Microsoft have long included these features, so it largely is a moot point.
I encourage JITC to modernize the standard to include such topics as managed folders, classification inheritance, role and process based classification, auto classification and more.
One key misconception is that the standard somehow mandates a concept of operations. It does not. The certification test has scripts that follow a largely user based records declaration process that is outdated, but this does not have any effect on how an agency actually puts a product into operation. It only addresses which products are certified, or not.
This can be corrected by including the option in the certification scripts to use classification inheritance and similar approaches that would be more likely to be used in a real system.

06-10-2013 17:46

Thanks, Ron. I'm looking forward to reading your follow-up comments.

06-09-2013 14:17

Don, I love your blog on this subject as I believe that a full debate on standards for IT systems creating and housing Official Federal Records is really needed. You have taken a position that others no doubt share; and you raise some really good points for discussion (both agreeing and disagreeing) as the responses already posted indicate. I agree with many of your arguments for throwing out 5015.2; but I do have a few pet peeves that your blog brings to the fore:
1. Why are the discussions and serious work on standards for managing Government electronic records in the US always limited to DoD 5015.2, as though it is the only existing standard? As you very convincingly point out, this standard is so outdated and inadequate in many ways as compared to others such as MoReq 2010, ISO 16175 and the Object Management Group’s Records Management Services (RMS) specification.
2. Why would anyone seriously interested in establishing a systems standard for federal government RIM/Information Governance (IG) think that DoD and their technology vendor community has all the answers, and that what may be required and workable for Defense will also be viable for the civilian federal government?
3. Why is the work and debate on systems standards for Record Information Management (RIM) in Federal Govt. dominated by systems vendors and industry analysts who also make their livings advising technology companies on how to position their products to maximize sales to government and private sector customers?

Thanks, again Don for stimulating this discussion with your blog! As indicated, I’m not ready yet to agree with every point in your piece; and if time permits (and space on this AIIM Community site allows) I will try to follow this up with a more detailed explanation of my concerns in another post, as my attempt to do so here exceeded the space limitation for comments. I'll also have some point-by-point reactions to your concerns with the six specific requirements of Cutoff, Metadata, Email Records, Non-electronic documents, Record Relationships, and Metadata-based Security.

06-06-2013 08:34

I remember being friendly competitors back in the day, Alan. Seems like a lifetime ago now. TRIM was a terrific product.
My SharePoint blog has a fairly big following in Australia and I’m reasonably familiar with their Continuum theory. They make a compelling argument and it doesn’t stray too far from my belief that we need to quit treating content as ‘records’ or ‘non-records’ and start managing all of it through its entire lifecycle. Certainly worth a closer examination.

I’m hearing some encouraging things about NARA and the DoD through back channels lately, so I wouldn’t write them off just yet, but I agree that they need to show a serious sense of urgency behind this. We’ll see…

06-05-2013 11:29

Don, this is an excellent article worthy of a panel round table at AIIM. There is an important point you missed
which is theological in RM terms . DOD and some folks in the Navy strongly adhere to the principle that a Record must be declared before it becomes a record. This never allows for documents in process or those never declared a record to become a record. The Continuum theory exposed by the Australians which DOD has never adopted assumes a document is a record upon creation . That model has a better goodness of fit
to integrated ECM systems which have rapidly become defacto industry standards. Having worked on AIIM Standards committees particularly on Records and Document systems prior to integration the problems were evident. It will take an act of Congress to change DOD and the National Archives thinking . Al Linden
PS I was VP of Tower when we were friendly competitors

06-04-2013 09:23

Great article. I have been a member of NMA/AIIM since 1979 and I have seen many changes since the personal computer (hardware) was invented and this new market called "software" emerged in the form of "applications" that dominate today's marketplace.
The internet spawned the creation of "dotcoms" in the 1990's and thousands of startup "software" vendors arose overnight to capture their market share of a fast growing information management market. For the first time in the history of the world anyone, anywhere in the world could communicate with the "click of a mouse" and could own a business using a personal computer loaded with the latest and greatest software (apps). There were no standards. There were no rules to follow. IT professionals were allowed a "blank check" without any consequences for their actions. No one was thinking long term. The goal was to start a business on paper and sell to the highest bidder and the first wave of investors flocked to the internet market with a lure to get rich quick scheme. When the internet "bubble" bursted and all these hardware and software companies failed it left a hugh void to fill regarding hardware and software choices and creating policies and procedures to govern records regardless of where they reside (paper, electronic).
President Clinton asked John Carlin, Archivist of the USA to come up with a solution to this growing records & information management problem. John Carlin asked the military Joint Chiefs of Staff for their help and they tasked the US Air Force with reviewing this problem. The Air Force conducted their review in 1994-95 and created a set of "functional baseline requirements" for electronic records management applications (DoD5015.2). This action was neccessay to ensure that thousands of hardware and software vendor products created would adhere to uniformity and meet the set of functional baseline requirements. 90 % of the IT companies could not meet the requirements and went out of business because of DoD5015.2
Today IT departments across the USA are still not aware of the significance (ROI) and the benefits of the DoD5015.2 standard and how it relates to records and information management and overall governance. At the time this standard was created IT departments across the USA were babies just learning how to crawl, walk and talk.
Thank God Records Managers were smart enough to recognize that all records (paper, electronic) are created, captured, stored and disposed of in their lifecycle.

06-04-2013 05:07

I found this blog very interesting. From now on I will not be looking for if the vendor product is licensed DoD 5015.2 any more. I totally agree that user friendliness is extremely important, thy should almost not have to do anything, if possible.

05-31-2013 15:44

Another concern about DoD 5015.2 is the success of RMA implementation and user adoption. Most of us know from experience that success in RMA implementation requires an application that people will actually use; allowing them to work in their preferred environment with minimal effort. Unfortunately, many of these solutions are not DoD 5015.2 certified, or the level of customization necessary to achieve certification has rendered them impractical.
As a result many agencies have purchased RMA’s that are certified, but are not even close to meeting their user adoption and business objectives.
So, I think a new alternative to DoD 5015.2 must focus not only on essential recordkeeping requirements, but also on practical means for implementation within our users’ business environment and today’s technology.

05-31-2013 15:37

I generally agree with your comments, Don, but I do have a few quibbles.
First, you state CATEGORICALLY "stand-alone Records Management applications haven’t existed for almost a decade." I beg to differ (Note: I am a user, not a vendor). Your assumption seems to be that EVERYONE WHO IS ANYONE has an enterprise content management system AND that this system includes records management in some fashion. Don, it ain't so! MY employer has had HP's Autonomy Records Manager (ARM, formerly CA Records Manager, formerly FileSurf) for a decade, BUT is just beginning to deploy SharePoint (which I do not claim to be an enterprise content management system). It will be interesting to see what HP produces in the Child-of-ARM/TRIM next year, but there is NO possibility that we will be implementing what you consider to be an enterprise content management system.
Second, you state "The Baseline Compliance Test Procedures for certifying against the Standard is full of countless metadata requirements for a wide range of record types. The level of metadata tagging suggested by these procedures would almost certainly impose an undue burden on any organization’s end users and would undoubtedly result in an extremely low (perhaps even zero) adoption rate." I do not claim to be as familiar with DoD 5015.2 as you are, but I'd like to point out that, for example, library catalogue system (OPACs) typically conform (in the USA) with the MARC21 metadata transmission standard, which has hundreds of metadata elements (see http://www.loc.gov/marc/umb/). The point is that NONE of these elements is used in any one record, but, in a large library, there is high probability that most if not all of the elements will be used in SOME records. In other, having a large number of metadata elements never establishes a requirement to use all of them for any one record.
That said, I do hope the DoD, in the interest of better records management, comes up with a better solution, and I hope your posting kicks off a vigorous discussion at the DoD and NARA (and not just in RIM circles).
Best regards,
Fred

05-31-2013 08:23

Thank you for sharing your thoughts in this fantastic article.

05-30-2013 18:01

I had high hopes for the Presidential Directive, too, Tom. I was disappointed it didn’t specifically address the issues around HOW records management across the Federal government should be conducted, it just said it HAD to be done.
You may find it interesting, though, that I know of at least two large agencies who interpreted the Directive’s omission of any reference to the Standard as tacit approval NOT to require DoD 5015.2 certified applications in their Records Management solutions. That may be the start of a trend. We’ll see…

05-30-2013 17:59

(Note: It looks like there's a glitch that is preventing me from replying to these comments directly, so I'm forced to reply out of sequence. Sorry for the confusion...)
Thanks, Randy, but I’m not suggesting the DoD overhaul the Standard. I believe it needs to be scrapped entirely. That should be much easier for them to do.
And to be clear, my concern isn’t limited to the Standard’s application in the US DoD. I’m also thinking about the majority of Federal agencies and the many State and Local governments who have adopted it. And just as importantly, the innumerable private sector organizations here in the States and across the globe who have made the 5015.2 the de facto standard of choice for records management functionality.

05-30-2013 15:04

Don,
So glad you made these points, and I could not agree more.
It's too bad that the activity around the Presidential RM Directive does not include a close look at the viability of 5015.2 and revising the definition of a record. For all the other good things likely to come out of that major effort, neglecting these two points will have a crippling effect on things in the Federal sector going forward.
Thanks again for taking the time to write your posting.
Tom Munzer, CRM

05-30-2013 08:55

Don - Great breakdown of the standard that adds unnecessary complexity and cost. I'm sure it's been part of the DoD system upgrades and new installation 'problems' and cost overruns. Unfortunately it will be difficult for the DoD to take a 180 degree turn to modernize it.

05-29-2013 14:24

Well done Don, I can only support your provocative but professional and well informed plea against the standard. I wonder what US based recordsmanagers and vendors of compliant products think of this? And it was a pleasant surprise how it reflects the situation in The Netherlands. As you know we have a similar national standard for recordmanagement functionality in systems, called NEN 2082 (2008). The issues of translating the individual requirements to recordsmanagement functionality in DM/RM software products are also very recognizable. Up to the situation where buyers demand a certificate from vendors and only the certification bureau seems to understand the standard fully. Until you analyse the requirements a little longer and come across contradicting requirements and requirements that are impossible to operate or not useful in the first place. Basic but sufficient recordsmanagement functionality for most professional organizations and companies could be well defined by 40 or 50 requirements to the most. And, last but certainly not least, certified products are selected and bought on that certificate, but essential functionality is widely under-used (e.g. audit-trail, retention, declaration as a record, etc.)
Woud love to read other experiences, thoughts and comments!
Check my blog on the dutch situation here:
http://www.ericburger.nl/site/sharepoint-2010/sharepoint-recordsmanagement-en-nen2082-certificering-hoe-zit-dat/
Cheers, Eric

05-28-2013 11:26

I absolutely agreed the segnentation in ‘records’ or ‘documents’ has caused incalculable damage.... Imagine in Europe in non-English speaking countries where we don´t have a word for records, and vendors try to translate it....