Among Social Business and E2.0 practitioners, there has been some debate about whether or not Microsoft’s SharePoint product is (or can be used as) an E2.0 solution. Regardless, within the world of social tools, SharePoint is impossible to ignore, and for as long as IT departments are able to dictate to their business organisation the tools that must be used, it will continue to be a major market segment.
If used properly, despite all its limitations, there is no reason SharePoint cannot succeed. But anecdotal evidence suggests that in many cases, neither widespread adoption nor business value are being achieved. As my colleague James Dellow pointed out, there is an emerging body of ‘worst practice’ around SharePoint implementation projects, and this is partly why we see shocking statistics such as 80% of users with SharePoint access still share documents by email, according to one survey.
The frustrating thing for us is that we know how to use the underlying capabilities of the platform to deliver user value and help drive social business outcomes, but whilst many IT departments seem content to over-spend on basic technology, implementation and customisation, they are often simply unaware of the necessary social experience design and adoption skills that can transform an IT platform into a piece of successful business infrastructure. But thankfully, that is starting to change.
Earlier this year, I ran a workshop for internal communicators who use SharePoint, intended to help them get to grips with the platform and work out how best to use it. At the beginning, I asked whether any of the attendees had gone through an evaluation of different technologies and platforms and then selected SharePoint as the best. None had. In most cases, it was chosen by people in the IT department with little or no involvement from potential users.
So why do so many IT departments choose SharePoint? Various reasons, including a desire for control, ignorance of alternatives, and the fact it is based on the Microsoft stack, which is seen as a safe choice. Price is also a factor, but there seems to be something of a myth that because they already have various Microsoft licenses, SharePoint is inexpensive. The reality is often quite different, as a few moments with the SharePoint license calculator demonstrates. In fact, it is among the most expensive options available, especially when you factor in Microsoft’s own recommendation that the product requires approximately $8 of customisation services for every $1 of license fee.
However, the real cost for any user-facing technology in a large organisation is not licenses and hardware, but the attention and time it demands from thousands of people in the firm. Poor Return on Attention (ROA) has a far bigger impact on the business than the setup costs alone – and given user experience is probably the biggest weakness of the product, this is a real and present danger. And finally, of course, there is the cost of maintenance and upkeep. Because SharePoint is designed to meet the needs of IT buyers, not users, it brings with it a culture of control that means you have to go running back to the IT department for a whole host of simple activities, such as setting up, managing or customising individual spaces.
So, given the costs, is SharePoint the best social business platform? Well, probably not when you compare it to native social business platforms such as Jive, Socialtext or IBM Lotus Connections. In every key area of functionality, you would be hard pressed to find anybody who would even place it in the top 3 available options. It is an adequate Document Management System (DMS) for most purposes, with the advantage of tight integration with MS Office, but it lacks the depth of functionality of leading products in this category. As a portal server, it is adequate and probably competitive with mid-range products, but the user experience is so poor out of the box that only a minority of users actually take the time to create and populate webparts (portal elements).
In terms of social features, SharePoint 2010 has a very weak wiki, which turns out to be a plain list of pages that can be edited collaboratively; a blog, which is very basic compared to the dominant (and free) WordPress platform in terms of both ease of use and features; personal profiles and social networking, in a very basic sense; and finally, tagging (at least within individual sites or spaces). Sadly, a great many IT folk would respond to this by saying these features are probably “good enough” for their firm, and thus denying their users the possibility of something substantially better than adequate. But as Michael Idinopulos points out in regard to activity streams, what seems like a basic feature can succeed or fail based on the user experience they support.
Mary Abraham recently touched on the problem with this Swiss Army Knife approach in relation to law firms and their use of SharePoint:
To be fair, you may be able to open a wine bottle and slice a piece of cheese with your Swiss Army Knife, but are you actually able to use it to prepare a nutritious and delicious meal? It seems that the SharePoint Swiss Army Knife suffers from similar limitations when it comes to social media.
Avoiding Implementation ‘Worst Practices’
Despite its limitations, it is perfectly possible to develop an effective social business platform using SharePoint 2010; but there are some common mistakes that should be avoided if at all possible. We are often asked to look at under-performing SharePoint systems, often because they are not achieving expected levels of adoption and usage. More often than not, we see one of the following patterns:
Install it and they will come: this is where companies install the out of the box system and expect that because SharePoint claims to have blogs, wikis and other features, that these features are good enough to attract voluntary usage right out of the box. Sadly, that is not the case and an out-of-the-box Sharepoint install might be used as a place to dump documents, and perhaps even to publish a 1990’s-style intranet, but it is very unlikely to see usage take off in the way we have come to expect with consumer tools.
Customised to death: this is where IT departments decide that, for the sake of consistency, they will develop and build all required features within SharePoint, rather than use other tools. This results in the kind of inflexible, tightly-integrated, highly customised system that becomes harder and more expensive to develop and maintain, and which runs the risk of being thrown out if the next version of the platform does things slightly differently (as has been the case with each version to date). Despite the high cost and complexity of developing inside SharePoint, IT departments often fall into this trap. What should be a relatively straightforward area of technical development has become so complicated that multiple technical experts can be required to install and configure Sharepoint 2010, as Cap Gemini (a systems integrator who do Sharepoint work) recently outlined in their technology blog.
IT-implemented silos: this is where the system is architected and configured to require specialist help whenever new sites are required, permissions need to change or customisations are required for a particular area of the business. It may result in lower risk from an IT point of view, but at the expense of usage, which is almost the definition of a self-defeating strategy given that more and more people are able to use tools like Dropbox, Skype or Google Apps as work arounds for poor internal systems.
Technology tail wags the business dog: social business platforms should be selected on the basis of user need, not IT preference. Even once the platform is selected, the solution design process should be as independent as possible from the default look, behaviour and structure of the platform, and driven instead by business need and desired behavioural outcomes.
SharePoint as a capability layer
Our preference, and the approach we often advise our clients to consider, is the pace layering strategy we have outlined previously. Essentially, we argue it is best to treat SharePoint as a base platform on which to build user-facing features. Use the platform to provide Office integration, authentication, document management and portal services, but build as much user-facing functionality as possible above SharePoint, either by leveraging one of the many complementary specialist products that sit on top of SharePoint, such as Newsgator Social Sites or Telligent; or, perhaps by using best of breed social tools that have strong SharePoint integration, such as Confluence or Socialtext. Thomas Vander Wal gave a good overview of the pros and cons of this approach in a presentation assessing Sharepoint’s potential as a social intranet platform earlier this year in Copenhagen. Finally, in an ideal world, where you want fine-grained control over user experience, you might also consider developing your own social layer that leverages the SharePoint APIs to integrate documents, lists and other SharePoint objects, whilst avoiding the platform’s biggest user experience limitations.
Once you have decided how to create the functionality you require, the interesting work begins, which is to mould and shape SharePoint into something that users will want to engage with, and then work closely with them on adoption, training and communication plans that puts these features into the context of day-to-day tasks and processes that people need to perform.
In shaping SharePoint to deliver a workable social business platform, there are a few key issues to bear in mind, but all of these can be overcome if you have the right blend of design, user experience and business skills on the project, rather than just developers. For example:
User Experience. Why do millions of people use Twitter, Google docs or Facebook? Part of the answer is undoubtedly the simplicity of their consumer-grade user experience for the individual, and the way these tools enable them to connect with others. A tool that does one thing well will usually be used ahead of a tool that does many things poorly or even adequately. User experience *is* the product as far as people are concerned. This is perhaps the biggest failing of SharePoint projects, and in some ways, the easiest to fix.
Silos and Document graveyards. The basic model of SharePoint assumes each site is a silo that does not need to share content with other sites, and there are too few meaningful cross-silo sharing features in the platform. This is a big problem for users, but ironically, it is an even bigger headache for administrators as it runs the risk of re-creating the world of separate file shares and home directories that SharePoint is partly intended to replace. This is an anti-pattern that needs to be designed out of the solution in many cases.
A document-centric, not a people-centric model. SharePoint assumes the pivot for knowledge sharing is a document object. Notwithstanding the fact that less and less current information is these days stored in documents, this assumption makes it harder than necessary to navigate the social networks of the organisation or to locate and find expertise.
They key thing to bear in mind here is that the most important skills required to turn a SharePoint implementation into a successful social business of E2.0 platform are not MSCE certification or SharePoint development, or indeed technical skills in general, but rather a deep knowledge of social experience design, user behaviour, incentives and motivation inside the enterprise. If an expensive IT system deployment results in 36% of users refusing to even engage with a platform and 80% defaulting to email for sharing, that is wasted investment.
Given how many SharePoint deployments are now hitting an adoption wall, I hope that more and more IT departments will begin looking at higher level thinking such as social business design to take their internal systems to the next level and give them a greater business relevance, and therefore a greater chance of success.