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