Bruce Miller has threatened for years to write a book amalgamating his decades of experience in electronic records management. This publication feels like a preview.

The Author and the Report

In ARMA International’s Managing Records in Microsoft® SharePoint 2010, Mr. Miller offers a mix of theoretical advice, practical application, metrics and project management guidance. Information Management and Technology matrix teams rejoice: this work is for you.

The report is divided into the following sections: the use case, assessing recordkeeping requirements, key underlying recordkeeping principles for SharePoint, implementing a file plan, folder structure and management, declaration and classification, classification accuracy, disposition, recommended best practices and project implementation.

In addition, there are four appendices: U.S. DoD 5015.2 STD Requirements Analysis, Metadata, Module List and Microsoft Resources for SharePoint 2010. Mr. Miller provides a glossary and bibliography also.

The Use Case

Mr. Miller opens his publication with a case study: a company with 1,000 employees subdivided into manufacturing, administration, legal, finance, human resources, sales, marketing, information technology, safety and security and shipping and receiving. 

All 1,000 employees create and distribute business records on a daily basis using the Microsoft Office 2010 suite. They receive approximately 100 emails per day in their Microsoft Exchange Outlook accounts. The organization does not require all of the functionalities of DoD 5015.2 standard but it does have the typical needs of a Fortune 1000. 100 contractors support the business.

The company has a retention schedule: 10 primary level categories, 20 secondary level categories and 200 tertiary categories. Each employee and contractor has their own tertiary category in which to hold case files (records that have a beginning and end date) and subject files (documents supporting ongoing business activities). 

According to Mr. Miller, the number of case records will be five times the amount of subject records. To facilitate disposition of the case records, qualification rate must be at least 85%.

Recordkeeping Requirements

Mr. Miller offers three options in SharePoint 2010:

  • OOB (Out-of-the-Box): use the built-in recordkeeping features of the product and live with any recordkeeping limitations the product may have.
  • Customize SharePoint: extend the product’s OOB recordkeeping features by customizing it to compensate for the gap between what is delivered OOB and the organization’s recordkeeping requirements.
  • 5015.2 Compliant: buy a DoD 5015.2-compliant SharePoint plug-in product.

Appendix A outlines the 168 baseline requirements of DoD 5015.2. He lists the requirements most important to a Fortune 1000 company and outlines the decision-making factors to support the three options.

Underlying Recordkeeping Principles for SharePoint

Wisely Mr. Miller maps SharePoint 2010 functionality to Records and Information standard ISO 15489. However, he skims the surface only of the complicated question, “what is a record?” Instead, he outlines three types of information submitted to SharePoint 2010:

  • Record: this document needs to be preserved. Put another way, it cannot be auto-deleted. It is a finished document and in play.
  • Work-in-Progress: This document is placed into SharePoint, but it is not yet complete. However, it is usually safe to assume that because it is something being worked on, it is a business record that eventually will need to be declared as a record.
  • Reference: this document is not a record, but is needed to conduct work. Often it is a document received from outside.

He outlines decision points around the three status in an “if-then” table -- because the objective is to choose the correct records state and manipulate it in SharePoint 2010. The three states include:

  • Declared Record: a document that has been declared a record and is therefore being managed as a record.
  • Non-Record: a document that does not meet the criteria of a record and does not need to be managed as a record.
  • Undeclared Record: a document that meets the criteria of a record and should be managed as a record, but has not been declared as a record.

Math follows, projecting the number of potential states declared on a daily basis in this case study. He describes case versus subject records more in-depth, because “the principle of case versus subject record Type is the single most important principle in recordkeeping that the reader needs to understand. It drives the mechanics of recordkeeping in SharePoint.” 

He compares a records retention schedule to a file plan (because, after all, your retention schedule should have some kind of code in front of each records series, therefore making the relationship 1:1). Mr. Miller illustrates the primary, secondary and tertiary relationships more closely. He concludes the section by defining the difference between destruction and disposition, commenting briefly on SharePoint architecture.

Implementing a File Plan

Mr. Miller outlines the characteristics of the typical file plan and its accompanying metadata. He emphasizes the need for strong data consistency in metadata fields. Somehow, the company must build a SharePoint module that can be used by designated responsible parties to create new case categories.

Meanwhile, he stresses that event date retention rules should be applied to case files as triggers. Mr. Miller recommends another custom-built module to create an administrative list of event dates to be applied in the SharePoint 2010 Records Center.

Folder Structure and Management

The team designing the SharePoint 2010 execution must consider folder structure and management in-depth. Mr. Miller acknowledges best practice versus real world implementation. Four different scenarios must be accommodated:

  • OPR Folder: The Office of Primary Responsibility (OPR) claims and maintains custody of that folder.
  • Secondary Folder Instance: a different department uses the folder with the same name.
  • Dissimilar Folder: same records, stored by a different department, in two different folders.
  • Unrelated Folder: catch-all folder related to the documents stored above, but not the exact records.

Meanwhile, two possible document storage scenarios must be addressed.

  • Homogenous folders contain related documents of the same subject. Apply the retention rule directly.
  • Heterogeneous folders contain documents of different, unrelated subjects. Apply the retention rule directly to the documents.

Regardless, the implementation team knows two typical user behaviors: “users will name documents on a similar subject differently [and] users will create folder structure in different locations, storing documents for the same subject.”

How does the team link these two behaviors? Through the Category (metadata) field. These three rules are described as sacrosanct:

  • A folder is either a records folder or a non-records folder.
  • If a folder is a records folder, it must have an assigned Category.
  • If a records folder, only records of the same subject (Category) must be stored inside it.

Mr. Miller admits there is an alternative. Sometimes folder management rules are too burdensome on the organization -- really, what department has time to consider all of these rules? He describes out-of-the-box inheritance rules and folder management best practices and library setup.

Declaration and Classification

Two classification realities are indisputable.

  • Classification is driven by document content.
  • Classification is entirely user-driven.

Essentially, classification occurs via the “Three C’s”:

  • Categorize the document as a Record, Work-in-Progress or Reference.
  • Classify the document against the File Plan.
  • Complete a minimum of four metadata fields:
    • Content Type
    • Subject
    • Category
    • True Document Date

Whether via out-of-the-box methods or through custom coding, metrics must be maintained constantly. He invites his reader to vet common SharePoint declaration methods and document creation flows. Mr. Miller transitions to an enthusiastic description of In-Place Records Management and Content Organizer features. The reader is treated to several records declaration scenarios, from automatic classification to drag-n-drop.

Observations on the Report

This is a deeply-considered report that has useful, practical gems of advice scattered throughout. For example, if you’ve never fully considered metadata (beyond Dublin Core), you will find some listed in Appendix B quite valuable. However, blink and you miss them. I wish he had highlighted them better.

Investing in Mr. Miller’s report is a wise move by ARMA International. The reader does get very useful advice -- his hints on records management in MySites is worth the price of the publication alone -- but if you seek a cookbook to teach you how to assemble a SharePoint 2010 Records Center, this is not it.

I’ve had the good fortune to assemble a SharePoint 2010 Records Center and compose lessons learned, but many of our colleagues have not. I would like to see more 1:1 analogies between records theories and best practices to SharePoint 2010 functions and architecture.

I’ve worked with a number of companies and only one in my experience barely matched the user case presented. I realize you’re smart enough to glean your own advice, but be aware that Mr. Miller makes some theoretical assumptions that may not resonate with your role or your industry. That may sway your decision on whether or not you’re willing to spend the money on this publication.

Finally, if you’ve sat at the table with him for two or three days strategizing an implementation, you know Mr. Miller is a skilled facilitator. He is an invested consultant -- he is one of the gifted who has the ability to make everyone in the room feel special. “Style,” said Flaubert, “is everything,” and I don’t hear Mr. Miller in this publication. Too bad, because I’d love for more of you to know him.

Please note: from 2006—2008, the author of this publication Mr. Bruce Miller consulted to an electronic records management system implementation team of which I was a member.

Editor's Note: You may also be interested in reading: