Blogs

Two weeks ago, I started working on a draft Information Policy document that should have been completed about a year ago. I’m not going to beat myself up over this, there really wasn’t any good way to do this work the right way and I do think we are better doing this late than not at all.

Last year, we (information services) began working with a group of people to organize documents for a recently reorganized department. They had inherited a bunch of historic content and they were charged with creating a new generation of presentations and process documentation. The goal was to make sure that everything was easy to store, easy to figure out and easy to find. Since we already had a lot of content, we needed a better way to organize and access it. The people involved have been great partners to work with, they are knowledgeable, methodical and they have been surprisingly receptive to using the slightly more advanced features of SharePoint. While we began this project in agreement that an information policy was necessary, it remained an elusive goal.

The information policy for this collection of content will address features like:

·         Purpose

·         Definitions

·         Ownership

·         Responsibilities

·         Access

·         Managing change, growth, inquiries

There’s more, but basically it’s the standard collection of information that, once you understand it, would help you build a nice solution in SharePoint.  Oh wait, we already built the solution.

In this case, I justified putting the cart before the horse, and loading it to the top of the sideboards, because it was an easier way to elicit the policy information.  While  my staff’s job would have been easier had they been given a comprehensive list of documents, permissions, processing requirements and retention periods before we clicked “Create New Site,” it would have been way too much to ask our users to “imagine a site where…” Our development effort was a series of false starts on paper followed by more than one false start in SharePoint. Still, we made good progress, and I’m convinced that we would still be sitting in the conference room if we had tried to work this all out in our collective imagination before trying to build anything. Even the false starts weren’t that bad.

In one case, after we created three libraries, we noticed that we probably only need two. In another case, we noticed that a calendar part could provide the necessary glue to bind a bunch of things together without creating an elaborate metadata scheme. The latter is a good example of what our coworkers would never have gleaned from the hypothetical world. Those of us who fully understand that a calendar is just a list, and that we can do anything with it that we can do with a list, have a huge head start on the folks who understand the calendar by example based on the thing hanging on their wall. In some cases, it is not fair to ask people to “imagine greater” as the ScFy channel likes to say. Sometimes, it’s more appropriate to ask practitioners to “work a little harder” at understanding what the requirements are. There’s a fine line between spending too much time planning and writing requirements and standing up a straw man solution, knowing that you might have to tear it down. SharePoint can be difficult to change, but if you don’t go too far down the road, it’s pretty easy to blow up.