Most all EDRMS (Electronic Document and Records Management System) projects in the past 15 years have failed to deliver on the recordkeeping element. Most projects start out with the goal of delivering recordkeeping accountability, but invariably end up abandoning recordkeeping. Fortunately the reasons for these failures are now very clear, as are the actions necessary to avoid these failures:

1)     Reason for Failure à Insufficient emphasis on increasing the organization`s overall value of recordkeeping in the eyes of everyday users. Solution à There needs to be major emphasis on changing perceptions, culture, policies, and attitude toward recordkeeping.

2)     Reason for Failure à EDRM software buyers do not sufficiently understand the recordkeeping capabilities of the software, or how to use them to achieve widespread user adoption. Solution à Key project managers and records managers need to master these specific features and adapt it to their organization’s specific requirements.

3)     Reason for Failure à There has been no means of quantifying or measuring the success or failure of the projects. Solution à The organization has to adopt a quantitative means of measuring the success of the project on a daily, weekly, and monthly basis.

RIMtech takes the position that the implementation of any 5015.2-compliant product will fail unless significant project resources are spent on implementation planning in accordance with a proven methodology that overcomes the 3 points of failure above. Implementation will determine project success, not product.

There are certain inviolable principals that are essential to successful electronic recordkeeping success. They are:

Qualification    How users decide which documents to manage as business records.

Declaration       Users have to decide that a particular document is a business record. Which ones? Similarly, when creating a document, at which point will they turn it over to the organization as a business record?

Classification   Each record must be assigned an appropriate retention rule from the approved list of rules, or retention schedule.

Each of these three factors (qualify, declare, classification) is in fact a critical project measurement metric[1]. Everything in any electronic recordkeeping endeavour contributes in some way, however indirectly, to one of these three factors. Each factor can, and must, be measured against an acceptable threshold. Any organization can readily agree upon a minimum acceptable threshold for each of these three factors. Some typical acceptability thresholds might be:

        Qualification. 5% of all incoming email, 95% of all documents created and download
        Declaration. 95% of all business records should be declared into SharePoint.
        Classification Accuracy. A minimum 85% of all declared records must be properly classified

Each of these three factors is easily measured, and must be regularly measured, by department, on a regular basis. Further, we need to “hit” all three to succeed. We cannot fail on any of the three, or the entire project will fail. Put another way, if we cannot run Disposition with complete confidence, which is based on the accuracy of the classification, the project simply is not successful

[This is an abstract from the Report “Managing Records in Microsoft SharePoint 2010”]

In order to apply sound recordkeeping practices to SharePoint, we must understand the difference between Deletion and Disposition.

Deletion refers to a simple, arbitrary deletion of a document. It can be completely user-initiated, and manually executed. For example, you simply select a document in SharePoint and delete it. Or it can be machine-initiated and machine executed, perhaps by a pre-determined workflow process.

Disposition however is very different from deletion. Disposition refers to a formal, structured process whereby documents are evaluated against formal rules (retention rules) within an approved list of rules (retention schedule) to determine which documents are qualified to be destroyed or transferred to a permanent archive, in accordance with the applicable retention rule. Disposition is a human-initiated process that consists of the following three typical steps or phases:

1 Qualify. Documents are measured against applicable retention rules to determine if they are qualified for destruction or transfer.
2 Review. A qualified Records Administrator reviews the qualified documents to validate their status, changing the status if required.
3 Processing. Qualified documents are destroyed or transferred, at the request of the Records Administrator.

The distinction between deletion and disposition is extremely important to understand, because both need to be happening in SharePoint at the same time. Think of deletion as informal destruction, in the sense that the decision as to what to delete and when can be made arbitrarily, by anyone at any time, for any reason. Think of disposition as formal destruction, in that the decision as to what to delete, when, and why, is not arbitrary – it is dictated by an authoritative centralized rule list known as a retention schedule. This retention schedule is formally pre-approved and is based upon laws and policy that govern the organization.

SharePoint uses the same process for both deletion and disposition, which can quickly get confusing. SharePoint uses the following two capabilities together in combination for deletion and for disposition:

        Policies. These are retention rules that state when a condition is met, take some action. This action can be document deletion, i.e. “Delete when document is 5 years old”.

        Timer Jobs. These are hidden SharePoint elements that run continuously in the background – you will never see them run. They act upon the policies, deleting documents when the rules specified by the policies are met. Think of them as “bots” that automatically act on the policies continually, without human input.

The first and probably most important thing to understand about applying recordkeeping to SharePoint is that you have to use these exact same capabilities for both deletion and disposition.

For all declared records, we will use SharePoint Policies, but we will not use Timer Jobs, as the timer jobs do not give us the opportunity to carry out our three-phase disposition process. We will instead manually initiate a formal disposition process. We will customize SharePoint’s built-in capabilities to construct the disposition process we need, as shown later in this report.

For the remainder of the documents in SharePoint (undeclared records and non-records), we will use the SharePoint policies and the Timer Jobs, as delivered out of the box. This represents deletion, not disposition. We will be inevitably deleting some undeclared records that really should have the formal disposition applied to them, however as stated earlier, hopefully we have very few undeclared records. Because we are using SharePoint retention Policies, it may seem as if we are doing recordkeeping, but we are not – we are doing Deletion.