Now I have your attention, I wanted to talk about some of the mythical problems of SharePoint. I am sure you all know what I mean. I have had people say things like the following:

1. Word loads slower now since we got SharePoint
2. When I boot my machine up it takes longer since we got SharePoint
3. SharePoint is not very good, it takes too long to upload my 100mb spreadsheet
4. It is not as fast as when we used to save to my network share
5. The internet is now slower since getting SharePoint

I am sure you have had the same weird comments and queries about your SharePoint deployment, or maybe yours went so well that no one ever complained or moaned about it. I have to say SharePoint is one of the applications that either people love it or hate from day one. Eventually they will like it and will adopt it but it just takes time.

The Problem

For a recent client I have been working with "SharePoint" was the first thing that always got blamed for anything that went wrong with the network. Well that is stupid I hear you say, but let's examine it a little more. If I am a user and I am using SharePoint and then something else on the network or my machine causes a slow down what will the user log the call about? You got it SharePoint.

What can we do to help this issue go away?

The first thing to do is to ensure that your infrastructure is correctly built. Visit Microsoft for the best practice designs.

http://technet.microsoft.com/en-us/library/cc303422.aspx

The second thing is to ensure that your servers are networked correctly. I have to say I have seen a lot of issues with SharePoint performance that really have nothing to do with SharePoint. The common ones are:

1. Load Balanced Servers plugged into the same Switch, causes all kind of network issues
2. Routing tables on the core switches not correct
3. DNS errors
4. Team NICS causing problems on certain hardware
5. Windows Server 2008 – Loopback Adapter Error (use the method here)
6. NIC speed not set correctly
7. TCP/IP Chimney performance issue – (use the method here)

These are just a few common issues that I have seen recently. So the key here is to make sure that before your SharePoint solution goes live make sure that the core underlying infrastructure is configured and correct. The worst thing you can do is to deploy a new sexy intranet application into a "dodgy" infrastructure.

The third thing we can do is based on the principle of the 80/20 rule. There is a great book available here that talks about developing software for time. The preface of the book is really about setting expectations and ensuring that users get the best experience possible. So to elaborate, let's say you need to make some changes to the system, but realise that this will cause a slight performance hit. What do you do? Not make the change or make it anyway and fight off the calls?

However with the 80/20 rule you simply need to ensure that when you make these changes that will cause potentially a performance hit that you make sure the changes are 20% or what the users are used to seeing. You can see this with many websites on the internet, think for a moment about the websites you go to, if the website changes only a small amount of content, brand or layout you (me) think they have changed the whole lot. It is all about perception, if I perceive a valid change has taken place I am less likely to log a support call about it as I am focused on the change. I am not advocating the use of "smoke and mirrors" here, but the concept it sound as this portrays the idea of batched up changes.

The fourth thing is to make sure that your support team can actually support it. So what skills do you need to support SharePoint?

1. SQL, SQL and SQL – Key Skill, SharePoint is an SQL Application
2. SharePoint – Obvious
3. Windows Server
4. IIS – Configuration and Authentication
5. DNS
6. Active Directory
7. Networking
8. Backup and Restore Technology
9. Windows Clients (200, XP, Vista)
10. Firewall(s)
11. Diagnosing Faults across platforms

You may look at this and think, that is a lot of skills, and yes it is!! Everyone seems to forget that SharePoint is a web application that requires this core infrastructure. One of the top issues that I saw on news groups, forums or seen emails about has been to do with Alternate Access Mappings!! This is not really a SharePoint issue, it is about Firewall Rules (potentially) and DNS, nothing else. If you DNS is incorrect then you AAM's won't work. Make sure your team can actually fix the system, or at least have the knowhow to diagnose the issue and not just stop at SharePoint. I have to say about 70% or support calls I am involved in for SharePoint do not relate to the actual product itself. For me what makes a great consultant is not someone who can not only build your system, design taxonomy, brand etc, but the key for me is someone who can actually figure out the issues. This is a hard skill as you have to be very pragmatic and understand the application stack. If you look at the development for SharePoint the stack talks nothing about Windows Server, DNS, AD or even that much about IIS, yet these are the core skills that are needed.

Lastly make sure that you allow users to offer feedback. You may not like the feedback, you may not really want the feedback but user adoption is all about finding out what should be changed and how it can be improved. For a project I worked on, we added a custom feedback control and web part to the portal and allowed all users to submit any feedback they wanted about the site. Yes we got negative feedback and some fantastic feedback. Over the past few months the feedback and stopped as the central IT Team has resolved the issues or educated the users on how things should be done. Remember the key to success it about all working together not separating yourselves from your customers. If you invite them to work with you then you will get a better adoption and less support calls. You will also find that you will have less official support calls if you offer feedback.

As you can see these simple steps can help when you as the Consultant or Administrator are working with SharePoint within your business. I am sure there are other ones we could add to the list, let me know what else you think is important for a SharePoint deployment.

Remember:

"User Perception is far more important than the actual in's and outs of how it is configured to your users"

As long as you as the technical person on the team can say it is designed correctly and is supported with proper SLA's then you can sleep better at night. J