3 things not to do with SharePoint
I’m a big fan of SharePoint. I’ve worked with it for years, right back to SharePoint 2001. It does a lot of things very very well (Since you ask -- document management, collaborative working, and increasingly social networking functionality). However, SharePoint also does lots of things, its feature set is simply huge. Not all of these features are as mature as others, and as a result it is easy for SharePoint systems to end up feeling a bit mixed and matched. Some things work well, some less so, and some should have been avoided altogether.
It is often as important to know what not to do with SharePoint, as it is to know what to do. So, with that in mind, here are 3 things you should avoid with SharePoint:
1. Build public facing websites. It sounds harsh but SharePoint websites are simply hard work. There are many examples of great-looking SharePoint powered websites (Ferrari is often mentioned) but that is only half the story. SharePoint requires a lot of time, effort and expense to kick it into shape as a website content management system. Even then the results aren’t always great, especially the admin interface which users can find confusing.
SharePoint websites can be a good thing where organisations are already making extensive use of SharePoint internally. The ability to share and publish content across systems can be useful, and there is of course a case to be made for reusing infrastructure and domain knowledge. But generally speaking most companies will find it cheaper and easier to avoid SharePoint altogether for their websites.
2. Customize the graphic design. Microsoft has, over the years, spent a fortune on the user interface of its flagship enterprise platform. SharePoint 2010 brought with it the Office Ribbon. SharePoint 2013 sports the Windows 8 UI. Despite these considerable investments, and the research and user testing that goes with it, many organizations still think they can do better. The first thing many want to do when they get their hands on SharePoint is to change its look and feel, often to match corporate brand guidelines.
Not only can this be expensive, and offer little return on investment, but it can also affect the long-term stability of the solution codebase. Companies would be much better investing in functionality, training and adoption activities. Microsoft themselves now offers this as official advice:
Use SharePoint as an out-of-box application whenever possible — We designed the new SharePoint UI to be clean, simple and fast and work great out-of-box. We encourage you not to modify it which could add complexity, performance and upgradeability and to focus your energy on working with users and groups to understand how to use SharePoint to improve productivity and collaboration and identifying and promoting best practices in your organization.
3. Treat it as a database. SharePoint uses the concept of lists to store data. Think of these as Excel-like data structures (indeed you can connect them and export them to Excel with ease). Lists have columns, and data types. Lists can import data from external sources, and connect to other lists. They are one of the best things about SharePoint and very powerful. However, they are not a substitute for a relational database (ultimately SharePoint sits on SQL, but this isn’t accessible or exposed to users so let’s not confuse the issue).
On many occasions I’ve seen projects where relational data structures have been squeezed into SharePoint. It never works. Want to store a list of contacts? Fine. Maintain a list of tasks for a project. No problem. But as soon as you want to look up information in another list you should worry. SQL server is one tool, SharePoint is another. Confuse them at your peril.