One of the amazing things you will frequently witness during the process of automating something is the transition from unconcerned consumer to connoisseur. People who were perfectly happy tossing a bunch of files into a folder on the K: drive suddenly become concerned with the induction, retention and disposition process. People, who were comfortable pawing their way through a bunch of similarly named documents, worry about the effectiveness of versioning. People who were un-phased by using email as the transport layer for collaboration question the reliability of alerts and people who have probably recreated content they couldn’t find obsess over the accuracy of search. The good news is that no matter how unfounded their concerns, the answer with SharePoint is usually “yes you can”, “yes it does” or “we can make that work the way you want!” Our most recent struggle with these questions revolved around the destruction of documents.
There are at least two points in the document life-cycle where a destruction policy is necessary. One is at the end of the retention period, when the document no longer has value. The other is during the creation of major version. We want to keep the major version, but we may need to delete the drafts and / or the prior version. This makes perfect sense, and is easy to understand for any given document, but it becomes difficult when you start thinking about hundreds of documents. SharePoint provides numerous tools to help us through this process, but it also complicates our policy making process. Library settings, alerts and workflows in SharePoint, enable us to implement retention, destruction, notification and even legal holds on content, but they apply to libraries. This means that we have to extend our analysis up-front to the decisions that lie in the future.
“Will all the documents in this library be disposed of according to the same policy?”
If the answer is “no” then you need a different library.
The other problem we have to deal with is the standard double-edged sword that is SharePoint, namely that we tend to mix collaboration and content management in the same place. I truly love the fact that we can support a collaborative, iterative content development process inside the library where complex content will be stored. It reminds me of the new construction within the industry we insure, where fabrication and storage facilities have been built proximate to the emerging power plant. When completed, the construction remnants will be removed, just like the draft documents and many of the data sets and spreadsheets that supported the analysis and decision making along the way. However, just like with the documents themselves, these are decisions that have to be made up-front. How many drafts do we keep? How long do we keep them? Who decides when a draft document is published as a major version? How many major versions do we keep?
The real problem isn’t with SharePoint, and, to avoid the faux pas revealed in last week’s post, I will add that it isn’t really a problem. As we work to change the collective behavior of people, we are asking them to give up the control they perceive to be inherent in the current process. People have a sense, however false, that they are in control of the contents of a shared folder, and when we ask them to yield that control to workflows and policies, and they instinctively push back. The fact that I can point to 60,000 documents under a root-level shared folder as indication that the current process is out of control is irrelevant. The thought process says “I can take control of this content at any point” and we don’t see that capability in SharePoint. I can modify the parameters that control the automatic actions, but that is buried beneath the surface; I can’t touch those parameters as easily as I can the documents themselves. In addition, the decisions we make affect all the documents in a library. That is a great benefit, but it’s also a scary proposition.