A tale from the SharePoint trenches

Mauro Cardarelli has written a nice piece about measuring the success of a portal.  Reading his post about a recent portal launch made me reflect on my not so recent portal launch.  We are 9 months into a very large portal deployment, where we took a regular HTML intranet site and turned it into a behemoth portal site, handing over content control to the content owners and combing several smaller sites into the larger portal.  It was quite a ride during development, and has been an interesting experience since deployment. 

Here are some things I have learned, experienced, or accepted having to just deal with:

Visual Content Display
Placing content control in the hands of non web people will slowly produce an inconsistent look and feel with text, display and tone.  While you can post guidelines and suggestions, they pretty much are treated like those long disclaimers or policy pages that we all sign and never read.  End users have unique taste and ideas on how to display and handle their content, and what may look elementary or bad to you they are proud of for figuring out.   Since SharePoint lacks the strict control that something like MCMS has, you open your site to visual imperfections and inconsistencies.

At first you may say, well I can keep a handle on it, I can run through the site and help tweak and correct things.  You can’t and you won’t.  Work grows busy with support and development issues plus playing the role of big brother is not fun.

Final status:  You just deal with it.
Support and the Blame Game
Due to item #1, you have now widely increased your support audience.  Now you have to help a large number of people with their content entry, list and library creation and any other odds and ends that come up.   You are also the ear for all issues with SharePoint and often the tone of voice is rather accusatory and angry, as if you yourself built SharePoint.  I standard reply will probably soon become “I’m sorry that is how the product works, there is nothing I can do.”  This doesn’t help at all with your popularity.

Another thing that is often heard is “SharePoint is broke, it won’t do XYZ”.  In my experiences, 99% of the time, SharePoint is working just fine, and it is more user error, lack of understanding or some small detail that has been overlooked and is causing the confusion.   Users tend to quickly blame the product, or the support staff for any and all issues, when most come back to user error.

Another aspect of support is remembering all of the details and nuances of SharePoint.  It is true that everything in SharePoint is just a list.  Or that all sites including portals are just a WSS site.  At the base this is true, in reality there are lots of unique details and quirks with portals, WSS sites and the OOB web parts that SharePoint ships with.  A user may run into an issue and you work to figure out what is going on, then you don’t hear about it again for another 3 months, which in the meantime you have flat out forgotten what you figured out before.   Keep a FAQ, running list of bugs, running list of fixes, oddities and end user instructions.  Getting organized from the get go will help down the road with future duplicate support issues and trying to remember all the quirks of SharePoint.

Final Status:  Get organized and get a tough skin.  Most users are very nice, but some blame you for everything.  Don’t be afraid to say that this is how the product works.  You didn’t build SharePoint, don’t take responsibility as if you did.


Strike a balance between proper terminology and common sense
End users are not developers.  Nor do they talk like developers.  SharePoint is a sea of terminology.  Some of it we need to preserve, and at different levels.  In the newsgroups I am a stickler over the correct usage of site definition and site templates, because they are two very different things and warrant different support responses. But when it comes to the end user, they don’t need more terms to deal with nor will they take the time out to understand them. Unlike us, their lives do not focus around the site and they have many other things to do.  Talk to end users using common sense terms and don’t get hung up over the technicalities.  But on the flip side to that, be open in comprehending what they say, a support issue may drag out longer than necessary due to the fact of a simple miscommunication or misunderstanding due to terms being mixed up.

This may seem odd to bring up, but I think it is easy to get wrapped up in your own world of what you know and all the terminology that goes with it.  I recently spoke with a manager at the swim lesson company my daughter swims with and she started referring to classes by code names.  I was instantly lost and had to ask her to stop and explain to me what she was referring to.  These codes she deals with on a daily basis and naturally assumed I knew them as well (I could tell by how put out she got when I asked her to stop and explain).  Don’t assume anything, verify you are talking the same thing when working with people and try to be conscious of their experience with the product and don’t talk over their heads.

Final Status:  Learn from your users and talk at their level.


Taxonomy is Key
I was told once by Todd Bleeker that taxonomy is key when it comes to planning a SharePoint site.  This was back when I was naïve and new to SharePoint.  I also read in an article or two that taxonomy was very important.  I tried to listen and remember that, but it is hard to do so when you are also trying to learn a completely new product.   Hindsight, taxonomy IS key.   You have to have a solid plan and organization for your site.  Portals can quickly run away from you.  Depending on how much freedom your content owners are allowed, portal areas and sites can be created hand over fist and faster than you will ever suspect.  You will be amazed how many WSS sites will be created in the months following deployment.

Once your site has launched, it is hard to reorganize it as people are learning where things are and you can’t rearrange items at the drop of a hat.  It takes thought and planning and evaluation if the moves will really provide value or just confuse the users. Not to say you can’t change stuff, but it has been my experience with not only SharePoint but sites in general, what you set up as the organization from the start is what you will be stuck with for quite some time.  Change is not adapted well nor is it easy to often do.   As users work with a site, they learn it, where things are and what things are called.  Changing this is a high risk venture.  Think about Amazon.com.  I mean how long have they had those tabs even though they are passé?  We are all trained to use those tabs, changing format would be very high risk for Amazon.

Final Status:  Really plan your taxonomy.  Seriously.
I have gone on long enough, but I felt compelled to share some of the things I have learned with my SharePoint experiences.

3 thoughts on “A tale from the SharePoint trenches”

  1. Nice Post :

    Now I won’t be afraid to say to my clients that this is how the product works. I didn’t build SharePoint. I guess Project Managers do risk analysis before start working on the project or forming a team.

  2. I have been looking for a good example of a taxonomy of a Sharepoint site. I need to buld a fairly complicated marketing Sharepoint Intranet and could use some inspiration!

Comments are closed.