This article can also be found in the Premium Editorial Download "SharePoint Insider: How to plan for a SharePoint 2010 implementation."
Download it now to read this article plus other related content.
Smaller organizations launching SharePoint 2010 often take a very casual approach to the deployment process. They purchase some licenses and install SharePoint without any real
To make sure SharePoint is used successfully, it makes sense to carefully consider the issues that inform a deployment strategy. What follows are tips on how to do that, along with key questions to ask within an organization about a planned deployment.
Formalize your vision. If you’re considering deploying SharePoint, then you probably already have some idea of the types of things that you want the project to accomplish. However, a good first step in the planning process is to create a formal document outlining how the SharePoint platform will be used. This is important, because the way that the organization plans to use SharePoint will have a direct impact on the hardware and software it will need to purchase. Your long-term plan for SharePoint can also have an effect on things such as service-level agreements (SLAs) and disaster recovery requirements.
As you document your vision for how SharePoint will be used, consider the following questions:
- Will SharePoint be accessible solely from the internal network (as an intranet), or will it be accessible from the outside world as well?
- Who will have access to SharePoint? Will it be solely for employees? Are you going to form business-to-business relationships with suppliers or strategic partners through SharePoint? Will you have a SharePoint site that is accessible to the general public?
- Are you planning to develop any custom SharePoint applications? Will any applications you are currently using be ported to SharePoint? (Some organizations use SharePoint to replace their customer relationship management, help desk or expense reporting software.)
- Will SharePoint replace your file servers? What about your Exchange public folder servers?
Develop a governance plan. If left unchecked, SharePoint can quickly spiral out of control. To avoid that, it is critical to establish a solid SharePoint governance plan prior to deployment. A governance plan outlines how the SharePoint system is to be used as well as the various permissions, responsibilities and policies that will be in effect.
Entire books have been written on SharePoint governance, but here are a few important questions that should help inform your governance plan:
- Will you be building a centralized or a decentralized system? (The IT department generally controls a centralized deployment, while a decentralized deployment involves the creation of multiple, independent SharePoint farms, each of which might be run by a different department.)
- Who will be allowed to create new SharePoint sites? Will all users be allowed to create sites at will, or do you want to limit site creation rights to supervisors or managers?
- Will those who create sites incur chargebacks? If so, how will the chargebacks be enforced and at what rate?
- How will lifecycle management work for sites?
- Who will be responsible for managing and maintaining SharePoint?
- Will the SharePoint administrator also manage the underlying SQL Server database, or will that responsibility fall to a separate database administrator?
- What will the policy be for data recovery?
- What types of auditing will be used?
- What kind of system availability will be required by your SLA?
Define the logistical requirements. Once your organization has outlined its vision for SharePoint and drafted a SharePoint governance plan, the next step is to begin defining the logistical requirements. These will enable the organization to meet the goals laid out in the vision and governance documents.
Begin this process by defining the capabilities that need to be put in place. For example, if your SLA requires “five nines” of availability, or 99.999% system uptime, you might determine that the best way to meet that requirement is by building failover clustering support into your servers. In that case, failover clustering would be a logistical requirement that would have to be met when you move on to the next step: designing the actual SharePoint architecture.
A final set of questions will help focus your requirements definition efforts:
- How much future system growth do you anticipate? (Your logistical requirements must address both scalability and capacity planning.)
- How do you plan to manage the SharePoint deployment? (Organizations with large-scale SharePoint deployments almost always have to budget for third-party management tools.)
- How do you plan to back up and recover SharePoint data? (The backup and recovery software that you use must address the requirements set forth in your governance document.)
- If you are going to use SharePoint as a replacement for a file server, public folder server or application server, how will you migrate the data to SharePoint and how long will the migration process take? Will you need special tools to assist with the migration?
Organizations often will use methodologies similar to the one described above to plan for and eventually design the architecture for their SharePoint deployments. Sometimes, the resulting plan can be cost-prohibitive. In such situations, it might be possible to spread out the costs by doing a multi-tiered deployment, in which the various aspects of the plan are implemented over time instead of all at once. At least you’ll have a comprehensive, long-term SharePoint strategy mapped out. Being casual has its place – but not in the enterprise SharePoint deployment process.
The politics of developing a SharePoint strategy
A tremendous amount of work goes into developing a comprehensive SharePoint deployment strategy for an enterprise-class organization. And over the years, there have been various examples of an IT department’s exhaustive planning and strategy-building efforts getting derailed by office politics.
To avoid those situations when someone in middle management throws a monkey wrench into your plans, work with upper management as you start to create your SharePoint vision and governance documents. By getting upper management involved from the very beginning, you enlist executive support for using SharePoint. Having upper management on your side can be a big benefit when internal politics rears its ugly head. It also gives senior executives the chance to voice concerns early on in the planning process – so by the time you’re ready to deploy SharePoint, the management team will be well aware of the project plan and you should already have answered its questions about it.
There’s another advantage to having corporate executives in on the planning process: budget sign-off. In many organizations, the executive team has to approve spending on large-scale IT projects. If they’re involved, they’ll come to understand the proposed scope and expected benefits of your SharePoint deployment project, and that should make it easier to get the team’s blessing – and the funding you need.
ABOUT THE AUTHOR
Brien M. Posey is a seven-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Posey worked as CIO for a national chain of hospitals and health care facilities and as a network administrator for insurance companies and for the Department of Defense.