The document has been so written so that it applies to implementing SharePoint 2010 and 2013.
The document outlines several key areas such as; getting a client and sponsor, defining governance, having a skilled team, training provision, service operations, information architecture, policies and standards and configuration management.
At the end of this document are contact details if you have any queries
Please keep it as clear and simple as possible. Avoid speculative discussions as well as a deep dive into underlying mechanisms or related technologies.
↑ Back to top
Many reasons why a SharePoint implementation can fail in an organization stem from the fact that from the outset there was little to no executive support and/or sponsorship.
It is crucial that Executives are behind your SharePoint implementation and that there is sufficient communications to the company workforce from management stating they support the project. This is the first step.
Obtaining executive sponsorship fosters adoption of SharePoint, eases the training strategy and ensures management understands some basic SharePoint principles behind how the workforce can improve productivity through the use of SharePoint.
The provision of SharePoint with executive sponsorship means that at the end of the project that the company sees a cost benefit to the project. After all, any IT project costs money, the value of enhanced productivity through the successful deployment is
a financial benefit to the company.
If you do not get executive sponsorship of the project and go blasting into the land of deploying SharePoint with no 'buy-in', there will be an uphill struggle meeting any of the other goals related to expanding / enhancing the platform, since no executives
have not been involved in the project from the outset. And if they have not involved:
SharePoint is a vast platform, covering Document Management, Business Intelligence, Social Collaboration, Team Working, custom Application Development and more. There is no point in deploying SharePoint if there are no goals to support user productivity.
To create goals you need to develop a business plan. This business plan sets out the high level strategy and written in a way that your sponsors will understand. This business plan defines the goals and meets the vision provided from your SharePoint sponsors.
It connects further plans relevant to the actual implementation of SharePoint (Quality and Project Plans). This is step two.
At the same time, the sponsors will need to present what they see as a vision for SharePoint - meaning - how do they see SharePoint aligning with their business goals and aspirations.
In order to set those goals it is important to state exactly what you wish to achieve - for example:
8 - Ensure Configuration Management Exists,
Governance surrounds this
You need commitment to creation of governance for SharePoint and membership for this needs to be set as a pre-cursor to 'what SharePoint should be used for' strategies. As a starter, lets take a look at three areas that will require governance set. Initially:
SharePoint implementations fail if the team being used has not been selected on their skills and if the team being used is not being managed effectively to deliver the implementation.
Implementing SharePoint is like building a house. You need someone to design what the house looks like, and that house will look like what client wants based on their vision. There will be a mass of detail in the design of that house, heating, water, electricity
are the services that need to be built and configured. You need someone to implement that design, complete the build and then support the services in that house.
Getting the right people to help design, build and then deploy SharePoint is vital. This can only take place after the goals have been defined, investigated and mapped into a SharePoint delivery. This is step three.
Customisation of SharePoint is not implementation, but that does not mean that you don't have their requirements in mind for that customisation to take place (remember the Goals?).
I've heard stories of developers being used to implement SharePoint - that is just wrong. Consider that house again. Do you get a plumber to design the house layout? Some people might say 'Yes, why not' - but I bet you that after that house is complete within
a month you'll be getting someone to look at it again - probably a structural engineer? So putting in SharePoint requires a number of differing roles all of which are pretty skilled in their roles. All you need is someone to orchestrate the work. Step in the
Project or Programme Manager, who, if not present means a lot of people doing their stuff without anyone to ensure that what is delivered meets the client requirements.
Yes, to put in SharePoint means ensuring you have a skilled team, who have special skills.
In the Managing and Implementing SharePoint 2010 Projects Book, chapter 6 'Building your SharePoint Team', I have attempted to to identify the kind of people and why they are needed. Note that the people in a SharePoint team is down to a combination of a
developed business plan, quality and project plan combined with the clients vision of SharePoint (i.e. what are the benefits they want their users to gain from its implementation).
This also relates to the people required to support SharePoint once implemented.
Check out this link here – it is a small section of the relevant chapter:
9 - Foster Culture and Adoption
On my site I wrote a blog covering the relevant training necessary for individuals to quickly focus on the training required to pick up SharePoint and the relevant services provided.
Whilst there are a vast number of training providers available you need to ensure there is a identifier that states the areas of training that you wish to cover. Adoption of SharePoint is key to its continued success in an organization. A key factor of this
is to ensure training is available and a model defined so that users can continue to benefit from the features the platform provides (because they understand those features). This is step four.
For SharePoint, and indeed, this is prevalent for any platform or application there are two types of training strategy that needs to be catered for.
First, there is the technical training and this falls into the remit of those working in the technical provision of the SharePoint platform which is concerned with the configuration management of SharePoint. This configuration management is the model of
support for SharePoint. A key component of this is the SharePoint Engineer (or some call an Infrastructure Specialist, or SharePoint Server Administrator). This is an interesting area since SharePoint requires a number of server services and features to run;
for example, SQL, IIS, .NET are a few. Additionally, the management of the platform at server level requires knowledge of the SharePoint platform at server level. Therefore, you need someone who has expert knowledge of the infrastructure services and SharePoint.
Doesn't mean they have to be an absolute guru in all of these, but definitely SharePoint. There are many reasons why this is crucial, especially when they need to manage the Service Operation and the Configuration Management of SharePoint, both of which are
A example why this is so important is an Enterprise organization where the technical teams are split into their relevant service camps. For example, there is an AD team, a SQL team, and Infrastructure Team and a SharePoint team. This means that the SharePoint
team requires good knowledge of the areas outside of SharePoint, because when something goes wrong they will need to know which team to influence and why. In some cases, they would also be called upon to instruct external teams where there is connected services
with SharePoint. A good example is an AD team needing to know how to configure AD correctly for User Profiles to be made available to SharePoint.
Secondly, there is the business training. This can be broken down into Administrator, Power User, Information and Knowledge Users. It is important to understand who the likely candidates are, and why they fit into the relevant roles, and the process by which
they obtain the training (e.g. do they cascade the training to other users, for example).
A good training strategy for an organization has three aspects:
So, what's an example training provision? Ok, lets have a go at this. Below is a simplistic example where you have to train the business, the technical team and you need to provide various methods of training. This example assumes the organization does not
have the funds to bring in external trainers at the current time.
Site Administration (the SharePoint Champions route) - 1 day
SharePoint Development Services Training (based on specific services - example; you want to deploy Performance Point services and need someone to be able to develop the application internally) - 1 week, add an incentive to get certified in the relevant area.
SharePoint Platform and Administration of SharePoint Server Services. This is a separated area and will cost especially if you need them to become expert (through certification). Give one week for starters.
Note that with some of the above there are hidden costs of course. Travel, materials, resources and time will all cost. There are also risks that need to be identified and mitigated. For example, if you are training the SharePoint Administrators, who is
supporting the platform whilst they are on training?
7 - Define Standards and Policies
In the heat of deploying SharePoint, service operations in terms of 'Business As Usual' operations for the platform are sometimes overlooked.
This is a very important area of SharePoint implementation and is directly connected to most of the steps in this guide. For example, if you do not set out how available the platform is you have no policies or standards underpinning your Disaster Recovery
model for SharePoint. If you do not set out how issues will be dealt with then your training strategy will be more difficult to define. If you do not list what makes up your SharePoint environment you will have difficulty recording and managing changes to
the environment through Configuration Management.
Ensure Management of your SharePoint environment is defined. Why
• A self-adapting and well monitored SharePoint environment can result in easier compliance, a reduced chance of data leaks and greater network uptime
• SharePoint proactive monitoring and a self-adapting policy will drive down SharePoint site management and overall IT costs
• SharePoint workers can take additional steps to improve the performance of SharePoint and integrated systems due to a fully structured Service Operations provision.
Creating a Service Model for SharePoint means you have a platform that is understood by your technical , business and governance representatives. That model expands as part of the technical provision in the organization (for example, communications, database
connectivity, etc). This is step 5.
First, lets look at what we mean by a self-adapting SharePoint. The process of providing a site for users can be achieved by defining a group of site policies and rules, and then building scripts to encapsulate those as served templates. For example, you
could provide templates for differing functions of the organization, for example, Project Management type sites have different features automatically provisioned than say Human Resources sites.
As well as providing templates, look at the permissions model for the organization and ensure that you are always in the know of who owns what sites; as site ownership evolves, so does SharePoint sites. Simply monitoring who 'controls' these sites leads
onto identifying training needs, usage, and a better understanding of who needs more aid in controlling thse sites.
Now onto Monitoring. This is not just checking whether certain services are running, like the good old Windows SharePoint Timer, or maybe even the Application Pools for your Web Applications. Monitoring SharePoint means confirming all resources and services
are available. In SharePoint 2007 this was 'easy' - simply monitor your search application, user profile, say the BDC and other related components of the good old SSP (Shared Services Provider). In SharePoint 2010, this becomes more complex with the arrival
of Service Applications - Search, User Profile, Secure Store, Business Connectivity, and more (see the references section for more information). Additionally, these service applications can be deployed to specific web applications, and some can be deployed
cross farm. This changes the landscape of monitoring to the point of ensuring the SLA (service level agreements) for your web applications directly relate to the service applications associated with them. For example, imagine that you have a BDC connected
to a specific web application that provides trading information for the company and is a crucial process of the organization. The SLA for that web application is bound to be of a higher order of priority than say a small project based team site whose premise
is to simply allow those individuals to manage and share content in a project team.
Therefore, if you are migrating SharePoint, don't think that 'Ok, I am going to monitor these services in SharePoint because that's what I did in SharePoint 2007. Think critically of the service applications that by default have been deployed and those service
applications that have been deployed to specific web applications. Of the default applications, determine how important they are to each of your web applications. Create a risk document that shows what the impact would be if that service application failed
on a web application basis. This will give you an indication of how important that service application is to the web application and therefore how much monitoring needs to be applied to it.
Ensure that your Monitoring rules are applied correctly in the Central Administration section for your SharePoint farms. Check that those rules are valid for each of the relevant areas, and reasonably gauge which of those monitoring rules can be either ignored
or modified. Also, make sure that each of the rules are documented, so that in the event that you need to prove your SLA meets targets that each of the monitoring rules in your environment and the business understands what has been monitored.
By doing this you will create a policy driven services approach to monitoring, which is backed up by SLA and has reporting mechanisms to SharePoint governance.
Service Operations is also about ensuring that day to day management of SharePoint continues based on the policies defined, and that users are kept productive through the availability of the sites, the features applied to those sites are functional, and
that users are kept abreast of improvements and modifications to the platform. This means the creation of statements of operations that describe the service, mechanisms and processes that connect SharePoint to your helpdesk, other technical and SharePoint
Your Service Operation is tied to the kind of service offering and hosting that you wish to provide; from sites, to site collections, web applications and how many and what kind of SharePoint farms you have.
For example, the service you provide will be different if your disaster recovery, test and production farm is all on one server (which is a very bad idea anyway), to a split model of having a test farm, pre-production (or staging) farm and a production farm.
Also, adding in say a Development farm (used for say external developers to write SharePoint code) may change the service offerings again.
So, ensure that you know the four service offerings in terms of hosting SharePoint. They will help you design your service operations around them, based on the design of the SharePoint environment.
These four tiers are:
Sites - SharePoint supports hundreds of sites per site collection. It is ideal for collaborative environments.
Site Collections - These are where you can define information and aggregation portals. Examples of these are top level site collection like an intranet; or a site collection for a division in the company.
Web Applications - These are for point solutions, groups of site collections; or where you need namespace and relationship automony.
Dedicated Farms - This is where you have specific applications for a company; or where you need to have staged deployments (e.g. authoring to production); or where you need to have environments to manage the service delivery (test, pre-production, production
and disaster recovery farms).
There are two types of Service Models in SharePoint and understanding them may help you clarify the purpose of the farm as a whole.
Commodity Hosting. This is where you are using out of the box features, and less customisations. Commodity Hosting is method by which a series of templated options are made available. Users then select the requirement they want that is best met from those
templates. These templates could range from self serviced sites through to structured long term sites provisioned and managed.
Application Hosting. SharePoint serves as a platform for hosting customised or line of business applications.
For both of these there are fuller discussions to be had concerning the policies and standards that shape the service model. For example, sites could be listed in site directories, archived on demand, set to a specific quota based on the type of template
used, etc. Other questions to get answers to are how would the support for SharePoint scale, how should search be provisioned, and when does IT support get involved. This will help you get agreement on the service model and build a service offering to match
These answers are surfaced through the work carried out by the Business Analyst, SharePoint Architect and the business.
SharePoint Information Architecture is the backbone of a well defined environment, making up the structure, taxonomy, structure of content (metadata of the organisations created content)). It includes the design of the site structure of SharePoint, and marries
up the clients vision of user productivity with the deliverables of the SharePoint platform.
Information Architecture is akin to designing the layout of a house. Consider that a house is constructed of walls, doors, windows. Also that each of the rooms have purpose, and therefore, the relevant equipment needs to have resources in those rooms. So,
lets think of the equipment that needs to be in the house. For example, a dishwasher may need to go into one of the rooms in the house. Therefore, the kind of components required for that dishwasher to be operational is plumbing and power. Unlike say, a sitting
room which requires say only power. This defining of the resources; and even the detail makeup of those components (e.g. the voltage required, the length of piping, hot and cold water, etc) in the room where the dishwasher will be is synonymous with information
architecture. Meaning, that the purpose of each site in terms of what the users will do in those sites is related to the functionality of that site, and therefore, the detail of the information architecture of that room.
To discover the information architecture; initial work includes analysing the kind of information the company creates what content is attached to each process used to create that data.
For example, consider a piece of content created by a project department that relates to risk management. Generally then, it is possible that the content could be attributed to more than just that risk management process. It could be a cost code, which is
generated by an accounting department. That accounting department generates that cost code through some other process. Therefore there are two things here.
Firstly that the piece of information (cost code) needs to be associated to the project site. Secondly, that the cost code is owned by the accounting department.
The analysis required to build the information architecture requires a skill set to build. Additionally, and this is crucial, information architecture will not survive or be meaningful to a growing SharePoint environment if it is not continually managed
Therefore, discovery of information architecture leads to structure building of the SharePoint environment, and has dependencies on the resources required to manage it going forward. Make sure that you have the necessary skill set and that you make time
to build even a basic model.
Resources required to build your information architecture is the SharePoint Architect and Information Architect.
The SharePoint Architect knows the anatomy of SharePoint and will know where information technically sits in that framework, and where content is stored, and how it can be stored. The SharePoint Architect knows the hardware and the network infrastructure
that needs to be applied.
The Information Architect is required to map the content the organisation creates into the relevant areas that could be covered in SharePoint - below are some examples (and in order of importance):
SharePoint Standards and Policies are created at two levels:
SharePoint End User level standards and policies are designed so that users have an easy and consistent way to manage their SharePoint sites. This begins with requesting sites through to setting permissions.
Usage Policies is one of the most important aspects of managing SharePoint to prevent site sprawl and misuse. Here you need to communicate the guidelines and proper use of SharePoint.
Write up the usage policies, and provide clear instructions on how and when users should work with SharePoint. Explain what constitutes abuse or misuse of the system. Describe how to keep information secure, and when SharePoint should and should not be used.
Provide mechanisms for the users to get support and training; request site design and development services and to request new functionality.
Standards and Policies paves the path to SharePoint Governance, and that plays a major part in the design of organizational level standards and policies. Governance is the key process by which SharePoint can evolve in an organisation revolving around a forever
changing organisation. More information on this topic is available here:
This is the typical best practice for model for deploying a SharePoint farm but also applications into the SharePoint farm.
Changes are moved from Development, to Test and then finally to Production.
Changes can be configuration changes, upgrades in version, or changes to the infrastructure. This can be at farm, web application, site collection and beyond into sites and content, depending on the following factors:
Using sound development and testing practices increases the likelihood of user adoption and acceptance into the SharePoint production environment.
The ninth step is ensuring that SharePoint in the organisation embraces and enhances user productivity.
SharePoint as a collaborative platform is there to inspire and aim users to use tools allowing them to manage and share ideas and content.
By inspiring your users to take on SharePoint collaboration and aiming them, through training motivates those users.
To do this requires leadership through a top level process using SharePoint strategists working with the organization so that their vision is exposed through SharePoint. Remember that first step - executive sponsorship is key to enforcing that leadership.
This means getting users to engage and build a culture where they manage content as whole. You need to instill in users that individually, they are a function in a bigger device; whose goal needs their collective efforts to be achievable. SharePoint allows
this since as a tool it allows people to work closer and engage in a clearly defined and managed online environment - assuming that all the previous steps have been followed.
"Start with good people, lay out the rules, communicate, motivate and reward. If you do all those things effectively, you cannot miss"
The key to providing a great SharePoint service lies in satisfaction as much as it does in service. It is no good providing a SharePoint service if your users do not appreciate the service as being 'good'.
The guides I've given in the ten steps outlined in this guide do not have to be followed completely; but you should have considered each one and weighed them up against the implementation.
There are so many other places for information in implementing SharePoint from a project perspective. My Book,
Managing and Implementing SharePoint 2010 Projects covers much more than this guide; and specifically there will be more detail covered in the book
SharePoint 2013 Planning User Adoption and Governance. Additionally, there are a number of other guides on my website that can help.