Several months ago I wrote a white paper titled Stop – Don’t be the Next SharePoint Disaster. Judging by the feedback and downloads it was definitely well received, with many readers out there telling us they had come up against some of those problems themselves.
However, not all readers were happy, some commented the white paper was too much about what not to do and not enough about actually to do. They knew there SharePoint deployment was a disaster (they didn’t need us to tell them that) what they did need was some advice on how to turn it around and make it a success. In response to this feedback I decided to write second white paper to outline the steps needed to take to make your SharePoint deployment a success. I call this plan for success the Seven Pillars of SharePoint.
Creating a successful SharePoint deployment is like building a house – before we start picking wallpaper and HD TVs for the inside we have to build the house, and before we can build the house we need to dig the foundations. The Seven Pillars of SharePoint are the foundations of the house – if they are strong and robust the house will last for years, if they are shaky and incomplete the house will come tumbling down around our ears.
Pillar 1 – Corporate Strategy
Once the decision has been made to use SharePoint it is important to document why SharePoint was brought in, where it will sit within the organization and the functions it will provide. This document should be agreed by all involved and kept for future reference, this will become your SharePoint Strategy Document. As simple as this sounds without proper documentation it can be easy to forget what SharePoint was supposed to do for the organization and why you even had it in the first place. The SharePoint Strategy Document should provide continual guidance as to what information is to be held in SharePoint, and how that information needs to be managed.
It is also essential to decide on the scope of SharePoint at this stage, without clear guidance on what functions can be contained in SharePoint and which functions can’t, scope creep can set in. Scope creep can lead to the project growing without guidance and can end up in disaster. The group responsible for creating the strategy document and ongoing governance are called the SharePoint strategy team; this team should consist of representatives from the stakeholder groups affected by SharePoint. This team will be responsible for creating the corporate strategy, implementing, managing and maintaining it.
The strategy team should also cover the following areas in the SharePoint Strategy Document:
•Deployment and configuration
•Education and Training
Pillar 2 – Change Management Process
In order for SharePoint to grow and evolve with the organization users/stakeholders must be able to request changes. The first step in this process is setting up a mechanism for users to request a change; this could be done through the site as a survey or list. The strategy team should convene regularly to analyse the change requests. Initially they should check that the requested change is aligned with the overall objectives of SharePoint Strategy Document as discussed in Pillar 1 – The Corporate Strategy.
If the change request does not fit in with the strategy the team must feedback to the stakeholder and explain why the change was not implemented. If the requested change fits with the corporate strategy then the request needs to be passed onto the technical team for them to conduct a resource analysis on it. Once strategy team have a business case for the request with the resource information they are in a position to decide whether to implement or not.
This process must be in place from the start of a deployment to make sure all changes are analysed and implemented properly. Without this process the site would either:
1) Stop growing and remain static, or
2) It would grow chaotically and become unworkable.
This process must be applied to all change requests no matter how small or large. The process control works best if applied consistently to all suggestions, without proper guidelines a perceived small change could result in a major headache for the strategy team.
Pillar 3 – Back Office Administration
Prior to implementing the SharePoint deployment the back office team will need to decide which version of SharePoint to install Windows SharePoint Server 3.0 (WSS 3.0) or Microsoft Office SharePoint Server 2007 (MOSS). If MOSS is selected a further consideration is which version to go for Enterprise or Standard.
Once these decisions are made (and licensing has been thoroughly investigated) the next decision the back offices has to take is to decide on the technical implementation and the specification of the hardware needed. These decisions are all based firstly on the expected traffic. Once the back office team has installed SharePoint there next task before any work begins on the SharePoint environment is to test the backup and restore procedures. Without a tested backup and restore the entire SharePoint deployment is put at risk. Only proceed with further developments when the backup and restore procedure works successfully.
The final task the back office staff must complete is to create a disaster recovery document; this document will detail exactly what to do if a disaster should occur. A disaster recovery document should contain a complete set of instructions including screen grabs of how to bring the system back following a complete outage. This document should be a complete step by step guide that can be followed by a non-technical member of staff.
Pillar 4 – Training
Training is essential for a successful SharePoint deployment, without training users will not be able to use all the functions within the site and the deployment could fail. Getting users comfortable with SharePoint and familiar with the site will improve user participation and increase the likely success of the site. Detailed training analysis is required to decide on the levels of skill within your organization and how this maps on to SharePoint. Training is typically split into the following areas:
Server Administrator- This training is aimed at the person(s) responsible for maintaining the servers SharePoint is located on.
Super User- The super user is responsible for 70% of the configurations of the site. This person should be IT literate and should be a proficient user of Microsoft Office. The super user should also have the ability to take business problems and map them onto SharePoint – this role is perfect for a business analyst
End Users- End Users account for the majority of SharePoint users; end users interact with the site most regularly and use information on the site to complete their job. It is important that this group feel comfortable with the site as they will generate the most traffic, without their interaction the deployment is put in jeopardy.
This breakdown covers the majority of SharePoint users found in most organizations. If your organization has the skills to develop in-house then the following two areas of training will also need to be addressed.
SharePoint Designer Developer – As we can see from the role of the super user 70% of the organizations bespoke needs can be configured by this function. A further 20% can be customised by using a tool called SharePoint designer. This tool allows for codeless customisation. SharePoint designer allows the organization to create more complex workflows, non-standard data sources and much more.
The SharePoint Designer Developer is required to have a high level of technical IT skills but does not need to have code.
Visual Studio Developer – The final 10% of an organizations needs has to be developed using Visual Studio. Developers can create even more complex workflows, they can surface highly intricate data constructed from many disparate legacy systems – in fact just about anything that an organization needs to happen can be created by the Visual Studio developer.
The person for this role should already be a software developer with knowledge of Visual Studio.
Pillar 5 – Clear Ownership
It is imperative that the SharePoint site is owned by somebody – the question is who? As mentioned earlier the ongoing governance is the domain of the organization’s SharePoint team. Therefore it would seem logical that this team owns it.
The problem arises when we consider ownership of content, who is responsible for what, who owns the documents, who owns the various sites and sub-sites, who’s responsible for deleting content etc. All of the above can be resolved by clear usage policies, from the start of the deployment users need to be clear on what they own, what they can delete and when.
The cornerstone to this is the ability to create and deletes sites; the business will need competent guidance in this area. Users will need to be absolutely sure under what circumstances they can create a sub-site. Once created the guidelines need to be very clear about how long the site can stay open if there is no activity – remembering that the person responsible for creating it may no longer be in post.
Pillar 6 – Technical Development Process
Once the organization starts to leverage SharePoint there will be an increasing desire to enhance the product by adding functions and configurations. To do this safely the business will need a safe, efficient and repeatable process. Microsoft has enabled this in advance by including the notion of features into SharePoint.
Once a widget has been created for the SharePoint site it is uploaded by a designated person, this then becomes a feature available to the site. Once the feature has been uploaded it can be turned off or on with a click of the mouse from the Site Settings page. This is important as if there are errors in the feature a non-technical user with the correct permissions can switch the feature off and it will no longer be active. This reduces the amount of time the feature is available and reduces the need for technical involvement.
It is also important for the organization to implement a Develop-Test-Deploy procedure for new features and site designs. This procedure should take place on a completely separate set of hardware from the main deployment. This hardware can also be used as a backup to the main server as part of the disaster recovery plan.
Pillar 7 – Ongoing Maintenance Tasks
Maintenance to SharePoint takes two forms change requests (as mentioned in Pillar 2) and ongoing maintenance tasks. Ongoing maintenance task are defined as tasks that are completed on a daily, weekly or monthly basis to keep the site updated. These maintenance task do not affect the structure of the site, its functions or the overall look and feel, if they do then they are classified as a change request and must go through that process. An example of a maintenance task would be adding announcements to a team site, or adding a column to a list.
These smaller everyday tasks are the very tasks that keep the site alive and relevant. It is important to take these task into account when planning for a SharePoint site, the strategy team must consider who is going to complete these tasks and at what frequency. SharePoint works at its best when ongoing maintenance tasks are delegated to multiple End Users within each site. This allows site owners and participants to have more control over their site; it also stops a bottle neck forming when the responsibility for these tasks fall to one person.