Most SharePoint Implementations Fail?

By DDLS Webmaster | 17 September 2014

Many implementations fail -for a number of reasons: Design – Information Architecture: SharePoint is a not just a website, it should be planned and implemented like a database!

The SharePoint Intranet often starts off as a replacement for file shares on the network. While SharePoint can handle this with ease, it is highly likely (and desirable) that it will expand to be more than that. This is when the design becomes crucial.

Uploading existing content to SharePoint is fine, but how are you going to work with it from then on? Do we want staff to simply search anytime they want to find something, then scroll through potentially 100s of items that may have met their search criteria, but isn’t really what they are after.

This is where Meta data (Site Columns and Term Store Columns) needs to be carefully thought through.

Meta data will allow you to perform automatic functionality like archiving, making items non editable item (becoming a record) and allowing people to find objects faster making SharePoint more relevant.

Content Types is a SharePoint technique for categorising the items created or uploaded to SharePoint. Your existing word templates can be identified as content types allowing for automation of workflows, retention and auditing policies, and a central point of setting changes. It is far easier to have these things in place before launching your intranet, than trying to modify potentially 1000s of items later on.

Pre Installation Decisions: Disk infrastructure on the SQL Server is another area that SharePoint administrators either are not aware of, or have accepted advice from the SQL Administrators or the SAN Administrators.

If you have Storage Area Networks you can be a little less concerned but you still need to ensure that the storage is setup for performance as well as offering faster recovery time, not just storage size. A common pitfall for administrators is not being aware that a single site collection lives on the one content database in SQL Server. If you have a single site collection for your whole intranet, then all staff could be concurrently attempting to access the one content database! Here is where you need to ensure performance is going to be acceptable. Also would you want to restore an entire content database in your whole intranet?

By spreading areas of your intranet to different content databases you potentially have better flexibility. Of course your SAN may be set up that these types of events are minimised. Multiple Site Collections does however bring administrative overheads to the table, but at least staff won’t complain as much.

How Will SharePoint be Accessed?: With more and more staff using tablets and potentially the option to work from home becoming more common place, the ability to provide staff with access to work content via a browser is something that SharePoint was designed to do.

It is accepted now that all you need is a browser to do most things in your private and social lives. For example banking, booking holidays, and finding information. Staff will want to do the same when at work. With the onset of IP version 6, and technologies like Access Anywhere it is going to be far easier with the IPsec features built into the IPv6 packet header to provide signed and encrypted access to the SharePoint server from anywhere, provided you use a public address.

Moving SharePoint to the Cloud? Of course you could go into a cloud based solution for SharePoint Point.

This eliminates your need to know “how many SharePoint servers do I need?” You may not need extra SharePoint servers 24/7. This becomes your Cloud ISP’s problem during high demand periods.

As for the content databases, your business would need to ensure that the ISP data centres are in the same country as your head office. In the event of any legal proceedings, you don’t want to be dealing with multiple country legal systems.

If you have a line of business application that you want to deliver in SharePoint you will require a SharePoint Application Role server on premises that the cloud based ISP will defer the workload to.

This is primarily to take the Service Level Agreement concerns off their plate, and back onto yours. The last thing they want is for your LOB application to be holding up the show on a multi tenancy installation.

If the office lost internet access, then you obviously won’t be able to access your SharePoint intranet if hosted in the cloud. It can however make authentication for staff physically external to the office easier. They wouldn’t need a VPN connection as the SharePoint Intranet is accessible from the internet. This would require a federated trust relation to be established between you and the ISP. You don’t want to hand over a domain controller to your ISP, nor have to deal with dual user account maintenance.

This is by no means an extensive lists of the many parameters that need to be taken into consideration for a successful SharePoint implementation, but I hope this information has given you cause to pause, and seek extra planning time in case the push for SharePoint is making you rush. DDLS offers Microsoft Official Curriculum courses for SharePoint 2013: