Shared, Public and Private

imageContinuing with the theme of “what may seem like an oversight might actually be a good thing,” our project brought us to the finer nuances of the SharePoint calendar this week. As I mentioned last week, we discovered that a calendar was a good way to represent the access paths to the content we are storing. This is because much of the content is associated with an event. Using the calendar not only lets us tag content with the event it belongs to, but also lets us answer questions like “what did we prepare for these guys last year?” The calendar works, but as is often the case with SharePoint, some people want more than they should have. In our case, the primary users were requesting a level of calendar integration with Exchange that we either couldn’t or didn’t want to provide. Note: I added the two options because it seems that if you need to do something that SharePoint doesn’t support out-of-the-box, there’s always a way to get it done. That’s usually a good thing, but not this time.

Calendars were perhaps the first collaboration communication mechanism. I’m not just talking about SharePoint; we have had public, community, team, company and project calendars since farmers first began planting crops based on the appearance of the night sky. While you might think that with today’s modern capabilities, we could all just have one calendar; that would be a disaster. In fact, it’s not even clear when we want to switch between the three types of calendars implied by the title.

Shared Calendars – These are a great boon to collaboration. People on teams can easily tell when they can and can’t schedule meetings, and they can build around other information. For example, we have an employee who normally telecommutes from Chicago. Seeing that he is in CT for a meeting helps me to schedule things that would benefit from an in-person meeting. I don’t think SharePoint is a good place for shared calendars. Although I’m sure there are ways to make the sharing work well, calendar sharing is a transactional process and it works better in Outlook.

Public Calendars – This is what we are building into our latest SharePoint solution, and it’s a perfect use of SharePoint. Public calendars tell the world when things are going to occur, and lots more. Ours is also letting people know who from our company is going to be attending, who is sponsoring the event, and it will have links to all the content related to the event. In the past, we have used them to store agendas and provide links to the supporting material for each topic. The site we are working on is a collection of document libraries, and the calendar is like the calendar on the bulletin board of your public library. It makes it easy for people to see what is going on in this area, without having to check multiple shared calendars.

Private Calendars – These calendars, as well as the private events people put on shared calendars should be, as the name suggests, private. I don’t need to know when someone’s colonoscopy is scheduled, the fact that they’re out of the office is good enough for me. I had my Outlook calendar published into my MySite under SharePoint 2007, but that connection lasted about a week. Outlook is much easier to connect to than SharePoint, and I can see my Outlook calendar anytime, anyplace and from any device that I can see SharePoint from. I don’t know a technical way to prevent it, but there should be a penalty for putting personal items in a SharePoint public calendar.

Those may all seem like obvious conclusions, but we have had requests to accommodate as well as attempts and successful violations of all the above. People, it seems, need to be made aware of the purpose of each calendar that they encounter. Here’s my standing guideline for SharePoint calendars.

Every item on this calendar relates to the content stored on this site!

Once again, as Steve Weissman loves to say: “it’s not technology, it’s psychology

This Has to Go – No Wait

imageOne 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.

Time to Build Something

AIIM Conference 2012 - Ready for KeynotesLate last week, I was discussing a SharePoint project with a group of coworkers, where I had to keep saying “that doesn’t matter” and “it doesn’t make a difference” following each with “from SharePoint’s point of view”. I was working with a newly assembled team in our company who, among other things, are trying to organize a big bunch of documents that they inherited. My first encounter with this group spawned a blog entry about the importance of context, over on my AIIM blog. This second meeting was the result of the experts having categorized the stuff they have and my first pass at how we might want to deal with those categories in SharePoint.

The result of their examination of content in hand and content imagined included 29 categories of information and 46 topics within those categories. After the meeting, we agreed to build a site that will be comprised of 3 custom lists, 9 libraries and two sub-sites. The sub-sites will be created from templates as we will need to have many of each type over time. In addition to that, we will repurpose one existing custom list by pulling a special view of its content into this site using Marc Anderson’s SPServices library (something we learned last week). The distillation process during this week’s meeting was governed by 4 principles:

  • Finadbility – The first objective was for people to be able to come to this site in the future and find what they looking for without a lot of poking around.
  • Usability – The site should be characterized by a good user experience. That means, we should organize content in ways that support useful webpart views, dashboards and clear navigation based on the implied question “how can we help you?
  • Sustainability – Three of the four people in this group will retire in less than 10 years. Not only does this site store the content that the people who will take over our jobs will need, we don’t want their first task to be to rebuild this site.
  • Governance – There is some stuff on this site that needs to be protected, some that needs to be monitored and some that needs to be destroyed when it becomes out of date.

I was very impressed with the members of this group, and their ability to imagine how they would work with the site, how their content might evolve and how future employees, without the benefit of the 90+ years of tacit knowledge in the room, would look at this content. However, we finally reached a point where our discussion exceeded our collective imagination. In describing the way a library’s metadata might allow for a specific view to be rendered in a webpart, for example, I was asking them to build imaginary extensions to imaginary objects. In trying to help me design a better solution, they were describing hypothetical documents that might result from meetings with hypothetical stakeholders. It was time to actually build something. I don’t dance nearly as well as Marc Anderson so I suggested that I start building the site, in my office, on Monday.

There are two important lessons to take away from this meeting, they aren’t included here, and neither have anything to do with SharePoint. The first take-away from our meeting is something that I actually have to go around and fix in a few places. One of the topics we discussed was whether or not we wanted to have a place for historic documents that were related to this project. At first, we thought that was a good idea, but after a short discussion, the consensus was “no!” Even though I’ve seen this done in the past, I now realize that it makes no sense. A history library would contain “the stuff we didn’t want to read when we started this project in 2012.” It’s not like there was an epoch changing event last week. Nuclear power has been around for about 55 years – in terms of our civilization, that’s not a long enough period of time to start carving it up into ‘before and after’ sections.

The second point – the discussion we had was based on Information and Content Management principles that I learned through AIIM. I plug that association a lot on this blog, but without the help of the programs and people in AIIM, our SharePoint implementation would be nothing more than a web-based K: drive.