Tuesday, March 27, 2012

Useful phrases for fighting SharePoint-Sucks-Syndrome

Many organizations face the challenge of good SharePoint adoption due to the battle of fighting the SharePoint-Sucks-Syndrome (not to be confused with Paul Culmsee’s SharePoint Fatigue Syndrome). SharePoint-Sucks-Syndrome is a debilitating illness that includes the lingering misconception that current-day SharePoint is no good, simply because of bad experiences with previous versions (read SharePoint 2003). Most of us know that SharePoint has improved with leaps & bounds over the past few years. But if you have to work among, or consult for, those who are still suffering from the destructive symptoms of this disease, : ) here are some great affirmations and other useful phrases to help people feel better about their SharePoint experience:

“Put some MOSS on it…”

This phrase was thrown around a lot in one of the offices I used to work in – whenever there was some business process that needed to be improved, or some application that wasn’t quite doing what it needed to do, or if in general something just wasn’t going well, we’d say “Put some MOSS on it!” We were of course talking about Microsoft Office SharePoint Server 2007, and that was our way of saying that using SharePoint could make any situation better. That’s right – to us, SharePoint was a hammer, and everything else was a nail. : )

“…the intranet site…”

I long for the day when SharePoint is such a pervasive platform that we actually stop using the word “SharePoint” to describe our use of it. This phrase helps bring that day closer. When you’ve placed the latest information about the upcoming office event on the homepage of the intranet portal, don’t say “the latest info has now been posted to SharePoint…” Unless you have to make the distinction between the SharePoint intranet and some other intranet available in the office, try to just focus on the great content you’ve just provided, and the convenient and universal access that an intranet provides, without mentioning the irrelevant details of the platform hosting the content. This is even more important if your colleagues have had bad experiences with older versions of the SharePoint portal – now suddenly the value of your content is not quite as enticing because a user is suffering from the thought that they’ll have to battle the platform to get to your content.

“…the application…”

This phrase also helps get us closer to the day when SharePoint is just an assumed platform. It also helps get us closer to the Age of the Devs when there’s more focus on the effective applications built on SharePoint than there is on the infrastructure concerns surrounding SharePoint. If I build, for example, a .NET desktop application for managing customer accounts, I usually give it a cool name, deploy it to the users, and from that point on everyone uses my cool name when they refer to it. No one ever says “be sure to add that new customer to our .NET 3.5 Smart Client app”. So if I build the same application using a custom web part, or an InfoPath form, or some custom SharePoint Lists, what’s the value of mentioning that the application is hosted by or delivered using SharePoint? Particularly in an age where more of our everyday applications are simply Software-as-a-Service, the details of what’s powering that Service should become less and less important.

“It’s not DESIGNED to do that …”

Sometimes folks suffer from acute Attitude issues when SharePoint doesn’t do something that they think it should. Let’s take the out-of-box Blog feature, for instance. Some users can’t understand why SharePoint blogs don’t do every cute little feature that they’ve seen done on their favorite blogging platform (a platform which, by the way, probably ONLY does blogging). Sometimes you’ve got to explain to them that SharePoint isn’t designed to do all the things you’re expecting in this case – SharePoint’s goal was to give you a basic blog to get you up and running, not to compete with every other blogging platform in the world. And there are certainly plenty of other examples of this across SharePoint’s functionality. With that being said, can you buy a 3rd-party add-on to get the functionality you need? - Probably. Can you custom-code the functionality you need using SharePoint as a development platform? - Absolutely. Can you realize that apparently having a blogging platform with all the bells and whistles is important for you and your organization, and probably means you should go invest in a best-of-breed blogging platform, while at the same time admitting that SharePoint is still useful for all the 900 other things you do in your organization? – I hope so.

“I gotta have More SharePoint!…”

In other words, tell them the Cowbell sent you… : )


So, what phrases do YOU use to fight SharePoint-Sucks-Syndrome?


  1. This comment has been removed by the author.

  2. Okay, so... that "Intranet Site" bit, I've heard SharePoint Nazis spout that rhetoric before. It's a rather cute way of calling one thing something it isn't in an attempt to lump it in with a broader spectrum. To me, that's like encouraging people to refer to a dune-buggy as an "automobile" so it can cleverly get lumped in with cars. Although a dune-buggy can get you from point-A to point-B... you'd be better off with a normal car. Can a SharePoint site be an Intranet site? Sure! But, the aspects of SharePoint that are specific to SharePoint (namely, it being 10 pounds of dung in a 5-pound bag) necessitate it being labelled as SharePoint. Content Management does not mean "Intranet." Windows Explorer and MS Office can act as Content Management, but that does not qualify as an Intranet. If you have an independently-written intranet site that is catered to the requirements of an organization, THAT calls for a blanket term like "intranet."

    Which leads me to your "designed to do that" point. Why do you think users constantly expect SharePoint to do things it can't do? Do you think that possibly has anything to do with SharePoint being treated as a solution to a undefined requirement set? Let's face it, SharePoint is a mediocre, flimsy solution to a random set of needs. However, far-too-often it's treated as a one-stop-shop to a complex set of requirements that it can't fulfill. As a result, you have users trying to accomplish things SharePoint can't deliver on. In my experience, user frustration usually doesn't come from SharePoint NOT being able to do something, it comes from unintended results when users attempt to do things SharePoint is SUPPOSED to be able to do. In my organization, if SharePoint can't do something, we just build them an independent ASP.Net application that can accomplish what SharePoint can't. But, when users attempt to do things that SharePoint just refuses to deliver appropriately, that's where user frustration comes in. We have an expensive product that is supposed to accomplish tasks A, B and C, and we can only accomplish task B on Tuesdays between noon and 2:00 when the user's blood type is O positive for some reason. So now, you have an "Intranet" that can't do what it COULD do, had the organization not been sold on SharePoint being an "Intranet," but you also have a product that isn't accomplishing what it's supposed to accomplish. You wouldn't install "MS Paint" and call it "Photoshop," because Paint can't do all the things Photoshop can do. Then again, it's hard for me to say that "MS Paint Sucks," because it isn't being treated as an alternative to Photoshop."

    You know, as long as you are using a piece of software within' the parameters of what it can do, NO software sucks. Just like, as long as you don't try to turn on the AC, your dune buggy doesn't suck as an automobile! Time and time again, SharePoint people claim that SharePoint doesn't suck as long as you're using SharePoint for what it can do. It gets sold as a be-all end-all, one-stop solution to an organization's internal IT needs before any requirements are even gathered, and when users experience the frustration that comes with their "solution" not really being a solution, it's THEIR fault. For some reason, if you encounter errors or any kind of unexpected results in SharePoint, it's the USER'S fault for trying to use SharePoint beyond what it was supposedly "intended" for. SharePoint is sold as a one-stop, cock-diesel, collaboration tool. You say it yourself... it's not SharePoint, it's "The Intranet." When you put a blanket label like that on a product, users kind of expect it to act as an "Intranet" would act. When you consider what SharePoint is packaged to accomplish vs. what it actually CAN accomplish, I'm sorry to say, SharePoint SUCKS!!!

  3. There's a reason why "Sharepoint sucks syndrome" is a thing amongst CMS users. Sharepoint is designed in a way that makes it difficult for users to navigate through the system. As we know, aspx is the code language of Sharepoint. Aspx is also the code language of a product called Centralpoint. Centralpoint allows you to code in LITERAL aspx. Sharepoint requires you to learn all of their secondary operational constructs, which is an education in an of itself. Centralpoint does have a function library, but the actual coding aspect behind structuring functions is true aspx. This is one of the main reasons why there are people out there ranting about how Sharepoint sucks.