Several months ago we began what seemed like a typical ECM project, organizing a big bunch of documents into a series of libraries. We are nearing completion on this project, and we recently had a meeting to wrap up a few nits. We have done our best to pare down the number of libraries to a minimum by using metadata to be able to sort and filter within larger libraries, but we noticed a problem. People appear to be having difficulty deciding between two seemingly obvious choices, a library related to Stakeholders and a library related to Internal Communication. The slide-zone between these libraries is the fact that they both frequently contained content related to events.
When we find content being mixed-up between two libraries, we usually look for ways to merge those libraries together and differentiate the content by metadata. We discussed that option, and decided that all we needed was a way to identify the Stakeholder, and / or the topic of conversation. Both of those seemed like easy-to-create attributes, but overlap was unlikely and that meant that there would be a bunch of sparse columns (something that bothers the database guy in me) but since the overall volume is small, who cares about a few holes? There are enough other metadata elements to support organizing these documents by topic, so this seemed like a good way to end the confusion. We suggested that a simple lookup list for each additional attribute would work (we already have a list of stakeholders), and we added that to our task list.
The next item on our punch list was a way to make the landing page of this site more welcoming and more immediately useful, i.e. to create a better user experience. We had stated this as one of our early goals, but we all (practitioners and users) agreed to hold off until we had resolved the underlying content management issues. Now that we felt close to knowing the types of content that will be stored in this site, we felt we could move toward building that “what do you want to do today?” type front-end. We started with the obvious question: “what will people come here to do?” The answer was that they will come to either read or review one of our internal documents on this subject, or they will be contributing content necessary for an event. The latter category would include things like research on a topic to be discussed at a meeting, graphics for a presentation or answers to questions raised during a public meeting. This category was also expected to hold about 80% of the content on the site.
As we started to discuss the nature of a calendar-of-events, our earlier confusion also began to become clear. The overlap between stakeholders and internal communication was almost always associated with documents that were being prepared for an event – an event sponsored by one of our stakeholders. With that bit of knowledge, we decided to add a ‘sponsor’ column to each event (internal events are sponsored by us) and we eliminated the problem that was causing the confusion.
I feel very good about two things. The first thing that I like is being reminded of the importance of understanding the underlying business process as you design an ECM solution. Fortunately, we have been working with this group long enough that they understand this too, and they have started to describe their business process in content-friendly terms. The second thing I like is how easily SharePoint lets you associate events with content and people and tasks and anything else, because they are all list items.