Sharepoint Search and Findability

You don’t have to look hard on the Internet to find the SharePoint haters.  Some hate it just because it is Microsoft (cue Kelly LeBrock).  But there are a lot of people out there who have had a bad experience with SharePoint.  One reason is that SharePoint is easy to get wrong.  Getting it right can be hard.

I’ve mentioned in an earlier post the many things about storage that need to be considered when implementing SharePoint in order to get a responsive, robust, flexible, scalable and reliable solution.  And I can’t tell you how many times I have heard about how insufficient planning for or understanding of SharePoint content types caused much heartache and (more importantly) much re-work and expense fixing it.  (Say it with me…)  Getting it right can be hard.

One of my personal goals has been to learn the pitfalls that have snagged others and seek out those with best practices and learn them.  (Of course, with SharePoint’s flexibility and many options, what is a best practice for one implementation can be a disaster (or at least an unworkable solution) in another environment with a different set of needs, a different business culture, and different constraints.  Hence, the recurring theme, “getting it right can be hard.”)   To do that I have become active in the SharePoint user community this year, both in Austin and in San Antonio.

Last month I drove down to San Antonio for the June San Antonio SharePoint User Group meeting.  I was intrigued by the topic – Search and Findability, presented by Bill English.  Mr. English runs a training company, a consulting firm, has written a number of books on SharePoint, and puts on the Best Practices conferences. 

The presentation turned out to be even more interesting, as the focus of the discussion touched on issues I feel strongly about surrounding the idea of “getting it right”.  It was less about specific SharePoint configurations as what has to happen beforehand, and behind the scenes. 

The first important point is the difference between “Search” and “Findability”.  Search gives you all the data relevant to your search term, to the limit of its ability to tell what you are searching for.  The example Mr. English gave was searching for “horn” (“beep beep” – car horn), “horn” (“toot toot” – musical instrument) and “horn” (holding his fingers next to his temples – animal horns).  “Findability” makes the right information surface at the top of the search results.  To do this you need a way to define documents that deal with “horns” (“beep beep”), documents that deal with “horns” (“toot toot”), and horns (fingers to the head).

The only way to make sure your data, information, and wisdom are Findable is to ensure that resources (raw data, documents, people, etc) are properly organized and tagged, which requires defining the tagging and organization requirements, then implementing the proper governance to assure that the tagging and organization requirements are being followed, or that they are modified when organizationally required.  It means understanding the culture in which SharePoint (or any document collaboration tool) is implemented. 

Does this mean that SharePoint (or at least effective Findability) can’t be implemented in an Agile environment?   Not at all.  In fact, because SharePoint has so many features and components, it is a natural for an Agile environment – you can deliver new features in short intervals as role, restrictions and governance issues are addressed.  But you will need a strategic view of what the goals are, and a deep understanding of the shape of the business needs, an understanding up the features and limitations of SharePoint, and defined change management processes, roles and responsibilities for when the requirements do change (as they inevitably will).  Doing these things will make any rework easier and less costly, and more importantly ensure that the cause of rework is an actual change in the requirements, not a lack of understanding of them.  And, yes, getting it right can be hard.

But it can be done with a cross-functional team that works well together, or, in a smaller environment, an individual with strong experience in gathering requirements as well as the technical experience with SharePoint.

More posts about SharePoint.