Blogs

My last post generated a lot of very good feedback about whether it is ever okay to maintain two separate repositories, one for collaborative content and one for records.  This proved very helpful as I put together some recommendations about this topic for a client. One very nice thing about the blogosphere is that I have the choice as to whether or not I take a stand on an issue; in this case I decided to walk a fine line and look at both sides of the issue. Unfortunately, one doesn't have that luxury in client work. I needed to make a recommendation and that meant taking a stand.

And my stand is this: I believe we shouldn't give up on the information lifecycle. 

Although it is tempting to think that by using separate systems, one for "collaboration" and one for "records" we can remove the burden on end users from worrying about how to classify a document, I believe this is false economy.

The risks of separating collaborative and records content can be high. Having a formal records platform for only final records leaves the very good question of what becomes of all the drafts and versions that led to the document becoming final.  I'm no lawyer, but I can tell you that in any discovery process you will be asked for the draft and work in progress documents even if you have legitimately disposed of your "record" copy.

I agree with those who commented that  we can't always achieve perfection. My post from last month speaks to this and I definitely stand by the fact that we can't let the perfect be the enemy of the good.

I believe we can have "good" even while not losing sight of the information lifecycle. Although those words may scare some people, information lifecycle management doesn't necessarily equate to a lot of overhead. In fact, proper information lifecycle management should mean LESS overhead.

The term I've used in the past is "subversive" RM.  By this I mean end users don't know (and probably don't care) about  when something is declared a record or what the classification is.  This can be achieved relatively easily by using simple metadata inheritance at the container level.

I advocate a big bucket approach instead of a big budget approach. Wherever possible consider creating a retention schedule based on retention period instead of content type. This means that users likely won't be able to use retention as a search item but let's face it, most users don't use records classifications as search terms anyway.

At the end of the day it comes down to business value and risk.  Every ECM project should focus on maximizing business value while minimizing risk. Clearly it can be a challenge to rationalize these two things but in my next post I will address strategies for creating an ECM organization structure that can help resolve these questions and help you achieve your content management goals.