Keep track of all the latest news and events on developer tools and technologies you care about
By Andy Hodges.
So you have been given a project and been told to build your company Intranet, but you have not had experience of SharePoint 2010, where do you start? Capture some requirements, install SharePoint out of the box or undertaking a pilot are all common examples of where a project can begin. Internal IT teams are often called upon to undertake projects when they may not have experience of SharePoint before. This article is intended to cover a number of areas and be a starter for 10 approach, seasoned SharePoint professionals, look away now.
1. The Business Case
I would strongly recommend firstly reviewing the business case for the project. Any project should to be linked back to the mission, vision and values of a company. Anything that you do working for an organisation should contribute to the company mission, vision and values and the Intranet is no exception.
If not already, the business case needs to be clearly defined, the outcome of the project can only be successful if the success criteria are extrapolated from the business case. Successful Intranets are usually driven by business users and not the IT department, put the user first and involve them at all stages in the project. Finally the outcomes of the project go beyond meeting user requirements. You need to understand what will actually be delivered, how this will be used, and what affect this will have on your users.
2. User Adoption
An Intranet is only going to be successful if it deliveries tangible benefit to the users. This benefit must be forecast and measured to show the project has been successful. Find some way of quantifying an ROI or a saving in the cost of doing business, this information cements the business case, which can help the project through often lengthy sign off processes.
Users will always use the path of least resistance with anything that they do, so the Intranet needs to be simple and quick to use. Undertaking user workshops and defining requirements is half way to achieving this but developing a solution that meets the majority of the requirements which is intuitive, superbly designed and quick to use is the key to user adoption. Delivering part of the solution early is an effective strategy to getting user buy-in, but be careful not to rush this to the detriment of quality and useable functionality.
Deploying SharePoint out of the box is a certain path to user resistance and low take up. Customise SharePoint to allow users to quickly find what they are looking for and quickly upload files to the correct place. An effective information architecture will help you to achieve this.
3. Design – Don't think about it at the end of a project!
A SharePoint Intranet needs a level of design, whether this is a simple colour change with the logo in the top left, changes to the CSS and HTML on the default master page, or a custom designed home page and subsequent templates, which option you pick will depend on your budget and aspirations for the Intranet.
The important thing is that you put as much emphasis on the design, as you do on the functionality at the start of the project. There are many examples of products that would not have sold well without great design, and SharePoint is no exception, do not underestimate the affect that something that is well designed has on increasing user adoption. To this end think, about the design upfront, what level of design do you want to go to and how will you resource this?
4. Home page Web Parts that you might build.
When designing pages use the requirements that you have gathered to create wireframes of the home page and any other pages that are important, such as departmental home pages. The wireframes will need to be run past the business users to get their sign off. Some examples of Web Parts that you may want to have built are:-
1. Latest News - showing news articles from other areas of the site. If you build the Latest news Web Part to only show certain articles based on Meta Data, it gives a lot more flexibility to re-use this Web Part in other areas of the site. Have pictures on the news articles to make them eye catching and engaging.
2. Quick Links - always useful and on the whole requested by users.
3. Notes - a free text area that users can use to store notes about tasks or handy web links, all about giving them a tool that they find useful and will come back to the Intranet to use.
4. Recent Documents - always a good Web Part for departmental sites so that users can see the content that is being updated.
5. User details - to give ownership of the sites to the users, showing the users responsible for maintaining the relevance of the site and content ensures that they keep it up to date.
6. Polls - useful for gathering user feedback across the business.
7. Latest Wiki's / Discussions - great for showing what people are updating and talking about.
Those are some examples of Web Parts that you may get asked for, there are plenty more custom Web Parts and some that may pull data from other systems, that aren't listed above. My advice with any Web Part is to look how you can keep it fairly generic so that you can reuse it across the site.
5. Social - using the features of SharePoint to go social and also add-ons that could be used.
Social is always a hot topic in organisations, some are all for it and some are resistive due to pre-conceptions on security/productivity. Deployed correctly in SharePoint, social functionality such as discussions, instant messaging, tagging, Wiki's and people profiles can increase employee productivity and satisfaction.
Knowledge sharing organisations will find some great functionality that can be deployed, and I would highly recommend that if you have a disparate workforce across numerous offices you should deploy MySites with each user having their picture updated to help take up. The best feature that MySites has is the organisational Chart, where an employee can see all their colleagues and view their profiles. The people search that SharePoint offers is great and I have seen examples where customers have won work through finding the right people in their organisation quickly.
If MySites is not enough for your organisation and the activity feed is just not doing it for you there are a number of 3rd party products that have integration into SharePoint.
1. Yammer - the true Facebook for the enterprise, I haven't had much exposure to integrating this into SharePoint but it looks to have some very good features and is free for the basic package. I am hearing more and more customers looking at this service.
2. Snap Work Social - a relatively new start-up and still in Beta but currently free and some good social features.
3. NewsGator Social Sites - an established player in the market and a very comprehensive product.
6. Document Management - Shared Drives
I won't deal with the whole of document management in this article, this can be a large area depending on your requirements. What I will deal with is the issue of shared drives. I hear the same thing project after project, "We want to move our shared drives to SharePoint, how do we do that?". My usual answer is don't, or not in the way that you are thinking. Shared drives are just a mechanism for document management, and now there are better ways to store and find documents in SharePoint. The steps that I would usually take are:-
1. Investigate the files that you have, archive off all the content that you don't need, this can be as simple as leaving it where it is on cheap storage, rather than importing it into the SharePoint DB.
2. Understand what needs to be imported into SharePoint. Who uses it, how often, is it likely to change?
3. Define some document content types. This could be as simple as adding columns for collecting data that is uber important to capture against each document.
4. Implement retention policies, even one content type with a retention policy is better than nothing but I would still recommend implementing a full information management policy, but if time and budget is not on your side, then I recommend steps 3 and 4 to stop the same issues you currently have with Shared Drives.
5. Meta data vs. folders - The way that files should be findable in SharePoint is by using Meta data, but when you have multiple collaboration projects being undertaken by your company it may be almost impossible to navigate to very similar files without putting extraordinary amounts of effort into defining your Taxonomy. I would recommend storing project files in a project site in a standardised folder structure, so users can find it either by searching or by navigating. Any company wide policies or procedures could be appropriately tagged and stored in a central document centre, these files can then easily be searched for. This is probably not ideal but practical for small organisations.
6. Configure SharePoint Search to index any external content sources, such as archives or Shared Drives that are not being moved.
I have mentioned there is much more detail to document management but the steps above are a quick and practical way to getting up and running quickly.
7. Office 2010 and Lync integration.
As you would expect from Microsoft's product set Office 2010 and Lync have some good integration points into SharePoint. If you plan to install SharePoint 2010 then deploy Office 2010 unless there is a really good reason not to. There are major improvements to collaborating on documents using SharePoint 2010 and Office 2010 that Office 2007 does not have. You can download a PDF detailing the Office/SharePoint features here: Business Productivity at its Best
Lync is excellent to providing instant messaging, meeting workspaces and seeing the availability of your colleagues. If not in the first phase consider deploying Lync as part of an overall collaboration project.
Ensure that you look into the licensing and have a grasp on all the options early on in a project. Engage with your Large Account Reseller and ask a lot of questions to make sure you have everything covered. If you don't yet know the specific architecture, then work up some scenarios and have these priced and then quickly undertake the technical architecture to pin down the required architecture. The biggest question to ask is, do you need SharePoint Server 2010 standard CAL's or SharePoint Server 2010 Enterprise CAL's? I am forever looking at SharePoint Edition Comparison when talking to customers about SharePoint. Weighing up the cost benefit of SharePoint enterprise licenses will depend on your business needs and the requirements that you have. You can upgrade later so the decision can be made later if you are unsure as to which version to go for now.
The architecture is closely associated with the licensing of the SharePoint farm and can be worked through at the same time. Again it is a huge topic but a few lessons I have learnt SharePoint 2010 projects are: -
1. Ensure the Minimum specs are met for your SharePoint servers and the SQL database. Microsoft does not support under-specified environments and more importantly you want your Intranet to be highly responsive all the time.
2. Check that someone previously hasn't installed SharePoint on SQL Express, the "Standalone version" does this.
3. Do not install SQL on the same VM/Machine as the SharePoint installation. Whilst this is a supported scenario it won't save any resources as you will need to double up on the minimum specs. Keeping it separate also ensures that backup, DR and configuration changes are more isolated.
4. Have Dev, QA (Pre-Prod) and Production environments. Not having these budgeted for and created can lead to later support costs and risks to business critical systems that are not acceptable. Releasing a SharePoint custom code solution is extremely difficult if these environments are not in place.
5. Capacity plan, use best practice calculators and documentation for determining the disk, RAM and network connectivity capacity that you need.
10. Roll-out strategy.
Discrete business units are often a good place to start the roll-out of your Intranet. Doing this also enables learning from any issues encountered, which can be resolved for later business units. For the first business unit pick the one that will be most receptive to the new way of working, they are more likely to keep using it even if there are a few niggles that need ironing out. If you cannot roll out the Intranet to a business unit then consider replacing processes or applications that cause users lost productivity and frustration at the moment. Some examples could include a Holiday Request Form, Searching existing content or Time management.
Finally, if you have the time and budget, properly invest in Information Architecture, Document Management policies, Information Management policies and create a companywide Taxonomy. If you have projects over 500 users you will want to go into a lot more detail than I have outlined above and the time planning will be repaid later in your project. I haven't covered migration from SharePoint 2007, but my advice would be don't underestimate the time and effort involved in a migration, plan and start this as soon as you can.