“It’s sort of like playing a child’s mini keyboard, as soon as you get a tune going you run out of notes”. This is a quote from one of my favorite car shows where the host was describing how a particular car fell short in a few areas. It was in fact a really nice car, but there were a few nit-picky issues that the host just couldn’t get past.
I think this same analogy often holds true with SharePoint. As others have stated, and I tend to agree, it’s the world’s largest Swiss Army knife. It contains lots of functionality and can be used by an organization in many different ways, but there are times when it does fall short. I’m regularly involved in the initial requirements gathering and analysis efforts for clients when the shortcomings are identified. They’re usually expressed in one of two ways:
a) SharePoint does what I need but not how I need it
b) SharePoint doesn’t do what I need at all
The first argument usually shows up when SharePoint is new to an organization and the proponents of the incumbent system feel threatened. A recent example I saw involved alerts. The requirement was that users should be able to set up and manage alerts, but because the SharePoint user experience was different than that of the existing system it was angled as a negative and became a focal point and somewhat of an internal struggle for the client. In reality it wasn’t a shortcoming but did reinforce the fact that the client would need to retrain users when SharePoint was implemented.
When the second argument comes up it usually isn’t a big deal. If there’s a specific requirement that SharePoint doesn’t meet, like a calendar roll-up or a specific document review process, there’s a high likelihood that with a little custom development or a 3rd party product the requirement can be completely satisfied.
That’s not to say that either of these types of arguments can be easily dismissed. They shouldn’t. If I’m being honest, the administrator of the incumbent system had a really good point with the alerts. Yes, SharePoint could completely meet the requirement. Yes, a little end user training would be needed. However, the user experience to perform the same functionality within SharePoint was pretty bad when compared to what the users were used to. Also, just because you can fill a gap with a 3rd party product or code doesn’t mean you should do it blindly without thinking things through. It doesn’t happen often, but there have been times when I’ve seen SharePoint contorted to do something it really shouldn’t be doing. Yes, it met the requirements, but the result was a system which required a lot of maintenance, didn’t scale very well, and really didn’t provide the users what they needed.
I can give more detailed examples of where SharePoint has run out of notes on the mini keyboard but I'd like to ask the community: What are the aspects of SharePoint where you’ve see it fall short and how have you overcome these limitations?
#SharePoint