Methodology


Way back in March of last year I posted a blog entry listing some of the new records management functionality I was hoping to see in SharePoint 2010 (referred to as Office 14 at the time).  Now that the new records management features have been made public, I wanted to take a quick look at how SharePoint 2010 compares to my original list:

Mulit-level file plan – definitely included in SharePoint 2010.

Unique expiration and disposition throughout each level of the file plan – also included.  Just like the file plans we are all used to seeing in the other major records management solutions. 

Significantly enhanced email records functionality – there are big improvements in e-mail records management functionality with out-of-the-box SharePoint 2010, partner add-ons and new Exchange 2010 archiving features.  I’ll post a separate entry on managing email records with SharePoint 2010 in the near future.

Expunge functionality – the jury’s still out on this one.  I want to be able to destroy a record in the Records Center (or wherever you manage it in SharePoint 2010) and know that it can’t be recovered.  I’m still not sure how I’ll manage this in SharePoint 2010, but I’ll keep investigating it and let you know what I discover. 

Hierarchical file plan representation – yep, it’s there.  You can view your full file plan hierarchy.   

Out-of-the-box metadata based classification – this is included and definitely out-of-the-box.  Should be a big help to Records Managers who are trying to minimize the records management burden they place to their end users.

Access to records from document workspaces – ‘in-place’ records management takes records management out of the Records Center and applies it anywhere within SharePoint.

Unique and persistent record identifiers – yep.

E-discovery beyond the Records Center – SharePoint 2010 provides for e-discovery all over the place.  E-discovery was one of the Microsoft’s biggest investment areas in SharePoint 2010.

There’s also a ton of other new records management features that I didn’t include in my original wishlist that will have a huge impact on managing records in SharePoint 2010.  I’ll be writing more about them as well as the features mentioned above in the months to come, so stay tuned.

If your organization is considering implementing a SharePoint records management solution there are two important solution design concepts that you partitionshould be familiar with.  (OK, I know you are all Records Managers and not information technology propeller-heads, but trust me, you want to at least be familiar with these concepts.)  

 The first concept is the Information Lifecycle Model.  Most of you have probably heard this term in one form or another, but the key here is understanding how best to apply it throughout the enterprise from within a SharePoint framework.  I will address the Information Lifecycle Model in my next post.

 The second concept is the use of Master sites and automated site provisioning.  Master sites and automated site provisioning will both help you govern your SharePoint implementation and allow you to effectively manage the information lifecycle of your documents and records. 

provisioning2 A master site is just what it sounds like: a central location for all your organization’s standard Content Types, metadata and Information Management Policies.  They enable the design and retention of content to be defined in a single place. 

 Automated site provisioning allows an organization to quickly and easily commission standard SharePoint sites across an organization.  With automated site provisioning your organization can apply such things as standard taxonomy elements, information lifecycles, search, and security settings in exactly the same manner in every site you create.  This allows you to enforce site standards while still allowing your users the flexibility to customize SharePoint for their own purposes.

 If you are in the process of designing your SharePoint architecture or even if your organization already has SharePoint implemented, I would encourage you to investigate Master Sites and automated site provisioning and discuss developing them with your solution deployment team.  As a Records Manager, it could be one of the best strategic decisions you ever make.

moviescreen-mike2I want to move away for just a second from discussing pure SharePoint records management issues and talk a little about something I’ve become really excited about lately – namely, MIKE 2.0. 

 MIKE 2.0 is an information management delivery methodology developed by BearingPoint and made publically available as open source.  (You can find it here.)  Whole books can be written about MIKE 2.0, so I won’t go into a ton of details here.  But, for what it’s worth, I think MIKE 2.0 is the best delivery methodology I’ve ever seen for developing your records management (or Enterprise Content Management) solution. 

MIKE 2.0 has a lot of excellent components which can all be utilized to help your organization create a successful records management implementation, but there are two things in particular about MIKE 2.0 that really appeal to me.  The first is its focus on pre-implementation analysis.   Nothing you do to create a successful SharePoint records management implementation will be more important than the analysis you do prior to creating your first SharePoint site.  MIKE 2.0 understands this and provides some terrific tools and guidance for managing the ‘Business Assessment’ and ‘Technology Assessment’ phases of the project. 

The other aspect of MIKE 2.0 that I find so compelling is the iterative nature of the implementation phases of the project.  Having worked on a number of records management implementations that used the old ‘waterfall’ delivery methods, I can tell you without hesitation that an iterative approach is a much more effective and generally successful approach to rolling out a records management solution. 

If you are at the early stages of your records management implementation and have some influence on how the project will be managed, I encourage you to consider MIKE 2.0 as your delivery methodology.

beach-failureI go way back with the DoD 5015.2 Certified Resource Kit, so I may not always be as impartial as I should be.  But to be fair, I need to mention a few reasons you may want to think twice about using it. 

As I’ve discussed before, the Resource Kit is extremely complex and can be horribly brittle.  (In all fairness, this really isn’t the fault of the designers and developers as much as what it takes to comply with the arcane test procedures of the DoD standard.)

There are too many features that run off of timer jobs.   This means that things often don’t get processed right away.  Instead, you may make a fairly simple administrative change and have to wait over night for it to propagate throughout the system.  That can get tedious.

Destruction of records is the same as hitting the ‘Delete’ key.  This is not a huge problem unless your organization has strict requirements about guarantying that your destroyed records can’t possibly be recovered.  If that is the case (as it is in many government agencies), you’ll have to go through a very laborious database expunge process each time you destroy a set of records.

The Resource Kit only allows you to create file plans that are two levels deep.  Unfortunately, that’s all the DoD5015.2 requires and that’s what the Resource Kit provides.  (There are some work-arounds for this problem.  I’d be happy to discuss them with you, if you want to talk about them off-line.)

Finally, and probably the most troubling thing about the DoD 5015.2 Certified Resource Kit, Microsoft does not support it.  In short, you can download it for free and install it, but you are on your own after that. 

Apparently, this was a tactical decision by Microsoft and I understand not even Microsoft has unlimited resources, but if your IT Department is anything like the ones I’ve dealt with, you are going to have a tough time convincing them to install anything that isn’t supported by the manufacturer.

The good news is that Microsoft is well aware of these problems and I would expect to see some or all of them corrected if they certify the next release of SharePoint coming down the road.  Stay tuned…

The few SharePoint Records Management resources Microsoft has made publically available all suggest limiting Records Libraries to one unique Content Type each.  In other words, all of an organization’s contracts will be declared to the ‘Contracts’ Records Library (and, presumably, given the same retention).  As experienced Records Managers, we know this simply isn’t practical.  Rarely – if ever – will a single file plan component contain just one record type.  This is certainly true for case-based records management, where a whole array of different record types are routinely maintained in the same folder. 

 I believe Microsoft promotes the notion of one Records Library/one Content Type because they want customers to use the Records Routing functionality that installs with Records Center out-of-the-box.  That’s understandable and I also believe in using the Records Routing tables, but one Content Type is just not practical for real-world implementations. Four puppets, holding in hands a puzzle of multi color

So how do you manage multiple record types in the same Records Libraries?  Here’s how one of my customers is doing it.  First, create a single content type for all of your team, department or organization’s records.  Call it ‘Accounting Record Content Type’ or ‘Acme Company Record Content Type’.  Make sure the Content Type includes all the attributes necessary to manage the record throughout its life cycle.  Assign the Record Content Type to all of your Records Center Libraries. 

Next, have your developers customize the records routing process to route documents to the Records Center based on metadata value’s assigned to the original document’s Content Type.  (I’ve discussed metadata-based records routing in several previous posts.)  Now when your users declare the Elm Street Bridge Project contract a record, it can go into the ‘Elm Street Bridge Project’ Records Library with the other project related records, regardless of its Content Type.

To make this process even more efficient, I suggest including all the Record Content Type attributes in the base Content Types of all of your organization’s document Content Types and have your developers migrate these values to the Record Content type at declaration.  That way, when your users create a document, they can fill out the necessary record information from its inception.

« Previous PageNext Page »

Follow

Get every new post delivered to your Inbox.

Join 61 other followers