I have been working with SharePoint 2010 since the very early beta days. At that time I was working for a consulting firm where I was assisting a county government with their SharePoint administration and development tasks. I was lucky because my customer decided to take a risk by allowing me to move them towards a new SharePoint version before even the beta was available. They agreed to allow me to invest time in SharePoint 2010 and investigate the effort to upgrade their recently deployed 2007 farm to SharePoint 2010. While SharePoint 2010 was in beta I worked to convert my custom developed SharePoint 2007 solutions to Visual Studio 2010 SharePoint projects. Two weeks after SharePoint 2010 hit RTM I successfully migrated an intranet and a public facing web site from SharePoint 2007 to SharePoint 2010.
Since that time this customer has gone on to do some amazing things with their SharePoint 2010 farm, including rolling out several more public facing web sites and an extranet.
So I titled this post “Tips for SharePoint Beginners” and I am sure by now you are asking, where are the tips? I wanted to first establish a bit of background so you can see where my opinions on SharePoint 2010 came from. These tips are really aimed at the person or persons who are planning a SharePoint deployment. Hopefully a few of these tips will provide you with a bit of wisdom and guidance to help you be successful.
- Know why you are deploying SharePoint. This may seem obvious, but I have seen many organizations decide that they need to deploy SharePoint just because they hear everyone else is doing it. Before you even begin to think about deploying SharePoint, make sure you fully understand the products capabilities and licensing models. Ensure that you have a good business reason for deploying SharePoint. Don’t start out with SharePoint as your solution and then go looking for a problem that it can fill. I believe that every organization can benefit greatly from SharePoint, however, you need to identify why YOUR organization is going to use SharePoint.
- Don’t be an army of one. A single person or department (…I’m looking at you in IT) should not take on a SharePoint deployment alone. If you want a successful, well adopted implementation, you need to include representation across the user base during planning and governance. Implementing a SharePoint steering committee is a very good practice. For the best outcome, have representation from different departments within the organization invited to be on the steering committee. I also recommend rotating people in and out of the steering committee to keep fresh ideas and perspectives.
- Choose the right tool. SharePoint is like a hammer. It is a great tool that helps you accomplish specific tasks. The key is to know when you really need a screwdriver. By reviewing the SharePoint documentation and overviews you will have a better understanding of when SharePoint should be used and when it shouldn’t.
- A single conversation with a wise man is better than ten years of study. If you or your co-workers are not experienced with SharePoint deployments, ask for help! There are many great Microsoft partners that have deep SharePoint expertise. SharePoint is not just about technology but it is also about business processes. Working with an experienced SharePoint team will give your organization a much better chance of fully utilizing your SharePoint environment and seeing higher user adoption.
- Have a plan beyond deployment. Having a healthy SharePoint environment requires more than just a good deployment. Installing the software in a properly architected server farm is just the beginning. A healthy SharePoint environment can only stay that way if there is a good governance plan in place. This plan outlines the who, what and why of your SharePoint Farm. Who is the project sponsor? Who has final authority over policies? Who is the SharePoint administrators? Who has access to SharePoint? What is the usage policy for SharePoint? What features will be enabled in the environment? Why is SharePoint being used in the organization? I could keep going on and on. A solid governance plan will help end user adoption and will ensure that the SharePoint farm is being managed and used as intended.
- The tortoise wins the race. Quickly pushing out a SharePoint environment to an organization will almost certainly fail. Users do not like change and they are even less likely to use SharePoint if they feel forced. Start with a small SharePoint project and get buy in from those who will be impacted. Over time you can slowly bring on new features or users to the environment, building on the success of the previous project.
- Empower the user. SharePoint enables a distributed management system for sites and content. By empowering the user to create their own sites, libraries, lists and workflows you will see an increase in productivity and employee satisfaction. Users who constantly have to wait for a SharePoint administrator to build everything will be frustrated an unhappy. Empowering users doesn’t mean that you let them run wild and do anything they want. A well defined governance plan working in concert with SharePoint security and quota controls can make a user feel empowered to build solutions to their own issues.
- KISS principle. The biggest obstacle when deploying and managing SharePoint is controlling complexity. Focus on the out of the box capabilities and resist the urge to install a bunch of 3rd party solutions (or develop your own). Don’t run past your current knowledge or skill set. Take your time and learn about all of the features of SharePoint. You might be surprised at what you can do with lists, libraries, web parts and SharePoint Designer. Of course there are always exceptions and in some cases the whole reason for deploying SharePoint is to support a 3rd party solution or another product (such as Team Foundation server or Project Server).
- Don’t reinvent the wheel. You may run across a situation where you need to extend SharePoint for a specific task or requirement. Before you jump into Visual Studio I recommend that you do a bit of research to see if the solution you require has already been built. Purchasing a pre-built solution can be less costly than trying to build your own. A pre-built solution you purchase will also most likely have some sort of support option in case you run into an issue.
- Play in the sandbox. Developing custom solutions in SharePoint 2007 was a dangerous affair. The first issue is that every custom solution had to be deployed at the farm level. This means that if a single custom solution starts to misbehave it has the capability to impact performance and stability of the entire SharePoint farm. The second issue is that Visual Studio didn’t provide an easy way to build solution packages (.wsp) so many people resorted to manually copying and deploying files to a SharePoint server. Both of these situations can really cause a mess in a production SharePoint environment. With SharePoint 2010 there is a new feature called sandbox solutions. A sandbox solution is built with Visual Studio 2010 and deployed as a SharePoint solution package (.wsp). The difference is that the sandbox solution runs within a separate controlled process space on the SharePoint servers. If the solution misbehaves then it only affects itself and not the whole farm. A good rule of thumb is that if you are going to build customizations, build sandboxed solutions. In some cases a solution can only be built as a farm solution. In those circumstances make sure you carefully test the solution before deploying. One last note, only sandbox solutions are allowed to be deployed in SharePoint Online.
- If it is not a solution, it is a problem. In the previous bullet point I mentioned SharePoint solution packages. Any custom developed solution should only be deployed to SharePoint if it is in a solution package. A solution package contains all of the solution’s files along with a manifest that directs SharePoint on how to install the files. This allows for easy deployment and retraction of your solution across one or more SharePoint farms. If you don’t use a SharePoint solution package for your customizations then you will quickly find that supporting your environment becomes a nightmarish task. Don’t be that guy (or girl) that just copies custom solution files directly to the SharePoint servers and NEVER manually modify the web.config file.
- Prevent frustration with education. People, in general, resist change. People despise change if they feel that they cannot understand the new “thing”. In this case the thing is SharePoint. A solid training plan when well executed will drive adoption to the new SharePoint environment you are deploying. Training doesn’t have to be an expensive proposition. There are many free online resources such as webcasts, videos and hands on labs that your team can utilize. Some of my previous customers have taken on a train the trainer style of education. They select a few people who are excited about SharePoint and send them to formal training. When those people return they host classroom style training for the other employees. This helps control costs while building up a key set of employees who are experts in the usage and management of SharePoint.
- You can lead a horse to water. You will never be able to force people to use SharePoint. The more you insist, the more they will resist. The key is to have an active marketing effort internal to your organization about SharePoint. Demo the features and capabilities. Show people how they can accomplish tasks more quickly and become more productive. When people get excited and are not forced into a solution they seem to adopt it with less resistance.
Do you have tips for those starting out with SharePoint? Let’s hear them in the comments section!
I have compiled a selection of documentation, case studies, how-to articles and training on my SharePoint resources page.