Real world SharePoint 2010 deployment issues
I am currently engaged in a large SharePoint 2010 enterprise deployment (a corporate intranet, collaboration team sites, extranet sites, my sites – the works!), delivering SharePoint sites to several thousand users over the course of a year.
As the sites become available to users and they get to grips to what it means to them and their day-to-day work, the gap between what the marketing blurb from Microsoft promises the platform will deliver to the “information worker” (improved ways of working and attendant productivity benefits) and the reality of what can actually be achieved with the tools available, readily becomes apparent. It has led to several interesting discussions with the client, with the defensive response from me usually along the lines of “but that’s SharePoint out of the box I’m afraid…”
This post is a compilation of some of the big ticket issues I have encountered, from the standpoint of the information worker using SharePoint day-to-day. Unfortunately, these are not the only ones…
1. Managed metadata fail. This is probably the number one problem area, as it affects several major areas of functionality that give the lie to positive spin about productivity benefits. We wanted to use Managed Metadata to promote an organisational taxonomy that would create a consistent corporate vocabulary, driving a better search and document management experience, but unfortunately Managed Metadata simply doesn’t integrate well enough with other products in the SharePoint/Office stack. These are well known by now, I’m referring to its failure to integrate with InfoPath, SharePoint Workspace (for offline synchronisation), it’s problems with Office 2007/2003, it’s failure to update in Datasheet view, and play well with SharePoint Designer. In the end we advised that it would only be used with caution and in agreement with the business areas that wanted to use it.
This is disappointing because Managed metadata is a great idea in SharePoint 2010, but it’s clearly not the finished article. I’m hoping all of this is ironed out in SharePoint 2013
2. Co-authoring fail. On the face of it, this appears to be one of the big wins with SharePoint/Office 2010 integration, and I do remain a fan of the functionality. However, for whatever reason, co-authoring for Excel – arguably THE most important Office application to organisations (it certainly is in my scenario) – sucks. It is only available within the the Excel web app, and it is terrible. Functionality is severely limited, and the workbook in many cases fail to even open in Web app because it is doing something that is too complex for the Web app to support.
3. Outlook integration fail. “What – you mean I can’t drag and drop an email into SharePoint?” Yep, that’s right, it’s one of the first thing users of SharePoint ask, especially those that have been doing that on a system that SharePoint is replacing (Opentext Livelink for example), and is part of their day to day work activities! The limitations of SharePoint integration with Outlook really cannot be overstated – customers need this to be fully spelt out to them prior to deploying SharePoint. Workarounds are of course available – and fully appraised here, but is is all far from satisfactory. There are useful pieces of functionality that are available with SharePoint – such as meeting workspaces, that the users have reacted favourably to, but again, these are not without their issues. Why can you not email a document library in a meeting workspace? Why does the list of attendees not update after a meeting invite has been amended? Why can I not click on a recurring meeting link to view it separately? (answer: because the site uses a custom master page and doesn’t have the fix in place for that particular gotcha). What happens when I copy across a meeting from my Outlook calendar to my SharePoint calendar list (connected to Outlook)? And lastly a question from me – why are meeting workspaces being deprecated in SharePoint 2013!?
4. Other productivity fails. This covers a multitude of sins, but generally they can all be categorised as things you expected to work, but they either don’t, or you end up sorely disappointed with the implementation. Examples here are:
(i) Creating and editing documents in SharePoint. In Office 2010, we can either create a new document from a content type-enabled document template, upload it into a library, or create it in the Office client application and save it into SharePoint via “Save and Send”. Experiences with Save and Send have been patchy, and issues include sites disappearing from the list of sites, or too many sites appearing in the list of user’s sites (the same goes for the SharePoint Sites view in Windows Explorer), questions/issues with using the Network places alternative (documented here and here), and users getting themselves locked out of their own documents!
(ii) Moving documents around SharePoint – either via Explorer view or Content and structure tool – I’ve already documented these issues here. Add to that a crappy experience in Explorer view because of it being too slow, or prompting for credentials, or some other issue.
Overall then, the conclusion I’m making is that all these shortcomings, experienced painfully at first hand when implementing a SharePoint ECM solution in the real world, and the sense of frustration and let-down that all these things convey to the end user, leads to dissatisfaction, and ultimately directly impact end-user adoption of the solution. And that is a big problem to overcome.