A ‘whipping boy’ is an 15th century term for a boy who was designated to take the punishment when a prince or other such noble misbehaved so that the boy would be punished instead of the prince.  I’m not entirely certain what lessons this taught the young prince but my guess is that it was either 1) other people would be suffer for his mistakes so he should be responsible, or 2) that he would never be punished for anything so he was free to do anything he wanted. It would probably depend on how moral or empathetic the prince was or even if he cared about the boy being punished.  You might be surprised at how a dark ages royal parenting strategy applies almost directly to SharePoint.

SharePoint continues to move itself closer and closer to being the center of the business world and with each new release extends its fingers even deeper into almost everything in the enterprise.  As such, people are interacting with it so often that they are unable to distinguish between what parts are SharePoint and what parts are external systems.  This is good or bad, depending on your point of view.  It is good that people are relying on it but bad that they are not able to distinguish even obvious lines of demarcation.  This blurred line results in SharePoint taking the heat for any and all problems that use SharePoint in any way, even just as a place for hyperlinks.  In short, it becomes the Whipping Boy, taking the punishment for the failings of another.

Case in point: a few weeks ago a call came in that ‘SharePoint was down’ except that it wasn’t and had not actually been ‘down’ outside of the scheduled maintenance window in years.  It turned out that one of the pages deep in the site on ‘sharepoint.ourcompany.com’ had a hyperlink to ‘outsidevendor.com’ and that other site was the one that was returning a ‘404: Not Found’ error.  A simple look at the address bar by either the user or the help desk would have spotted this but it was instead routed to higher level SharePoint support.  The issue was cleared up quickly by contacting the owner of the page within SharePoint and having them correct the link but this was hardly the first time such a mistake has been made.  In fact, it happens so often that we’ve accepted the position that SharePoint is “guilty until proven innocent” in the minds of most people in the company.

Other recent examples of the ‘whipping boy’ in action:

• SharePoint alerts are being sent from the wrong email address! (a security patch was made to Exchange that forces emails to use the defined “from” name on the email account instead of using the site specific “from” name that SharePoint sends)
• I can’t print PowerPoint files when I download them from SharePoint! (an IE/Office misconfiguration that happens when the PowerPoint files are loaded from any website in the company)
• I’m not getting any SharePoint alerts! (the user had rules defined in Outlook to delete all SharePoint alerts when they arrived)
• SharePoint performance is horrible! (a network device in the data center was misconfigured, crippling all network traffic from several server racks not just SharePoint.  SharePoint was simply the more widely used)
• and so on and so forth

None of these problems are SharePoint’s fault, but all are blamed on SharePoint at least initially because that is where the interaction started and this has a negative impact on the perception of the product itself.  This can be a big deal around budget time as upper management comes to see the product as either unreliable or unpredictable and is much more willing to question the funding associated with it.  Common solutions to this problem are to either educate senior management, keep excessive “CYA” documentation to present when questioned, or impose the draconian step of implementing a “you are now leaving SharePoint” style dialog that is almost universally despised. I do have some other suggestions on this that I will get to later.

To further complicate this, SharePoint 2013 has introduced a new application model that brings with it applications that are embedded within a SharePoint page so well that users can’t even see that it is separate from SharePoint at all.  How do we position those so that users can understand the line between SharePoint itself and the underlying applications that may even be hosted by completely different companies?  Do we merely accept that SharePoint will be blamed for any application outages, even though SharePoint itself has nothing to do with those outages? Do we simply lump it all under the SharePoint banner and try to do damage control as the situations arise? Do we create the mother of all paper trails so that we can look at each outage and prove that it wasn’t really SharePoint?

Frankly, all of these options are pretty ugly. Education is normally the answer to these types of problems but SharePoint is so large that the learning curve for anything beyond basic usage is already so steep for the average user that things like this would just get lost in the mix and forgotten.  Especially since it is so rarely an issue encountered in most people’s day to day interactions with the tool.

I know people are going to be upset with me for this but I feel that the best approach is what is the best for the users, which is to blame SharePoint first.  We know SharePoint isn’t usually responsible for these things but that is the perspective the users are coming from and trying to force them to understand more than that not only places an unfair and unwanted burden on them but sounds like whining on our part.  The user called because they have a problem and, like it or not, we have the tools and the depth of knowledge to troubleshoot and diagnose the actual problem and we can get the process of resolving the issue in motion.  The user came to us with a problem and we were able to solve it – that sounds like a good outcome to me!

This solves the problem for the user but still leaves us with the larger problem of SharePoint gaining a negative reputation across the company. The obvious first step is simple openness about the state of the application. Make sure all key benchmarks are posted and visible, including not only uptime but also ticket resolution that shows a breakdown of where the actual problem was. If this information is presented occasionally to the organization in some form, it will help mitigate the reputation damage.

This approach still feels like playing defense though where we are constantly fighting just to hold ground. Instead, we should go on ‘offense’ and take control of the source of those negative impressions by putting on our Ultimate Customer Service hat and taking steps to go above and beyond normal ticket resolution. Ensure that the whole process related to solving a user’s problems is so positive and so thorough that the users eventually become happier when the SharePoint team takes over an issue because they know that it is now in good hands. In this way, the very people who would have become your greatest detractors now become your greatest champions.

If you have other ideas or suggestions on this topic, I’d love to hear them!