Some people have the misconception that I’m anti-SharePoint
, but that’s really not the case. What I don’t like about SharePoint is how it is implemented in many organisations I come across. The typical implementation anti-patterns I’ve seen include:
- We are going to deploy a “vanilla” SharePoint, so it will be easy to upgrade later.
- We need something to do X and SharePoint lets us do X and more… we just haven’t worked out why we want the ‘more’ yet.
- Switch on the social features in SharePoint? You must be kidding.
- We’ve deployed SharePoint, now lets find out what users need it to do.
The first point is probably the worst case, because it limits your ability to do anything but train your users to work within the constraint of the vanilla experience. Yet, SharePoint is designed to be extended and integrated. And (just as with any complex enterprise product) you will need to do that if you want to work within SharePoint’s architecture, which has some limitations as a social business platform.
Case in point – I was recently asked by someone to help them explain why a particular social business software product was better than SharePoint. My response was this:
- Why do they think SharePoint would meet user’s needs?
- Why do we assume we have to choose one or the other?
80% of users with SharePoint access still chose to e-mail documents to necessary parties instead of using SharePoint.
There are – as the blog post and comments report – many possible technical solutions to this problem that can be plugged into SharePoint. Still, fundamentally the argument goes that email is so pervasive we need to fit new tools around the dominance of email. In effect, don’t change anything. Which leaves me thinking that some organisations just want to use SharePoint as a platform to augment email. And you wonder why I don’t work with organisations that use SharePoint that much…
BTW Headshift isn’t technology agnostic either – we have preferences
, but we’re not aligned to a single product or vendor either.