Avoid Newbie Mistakes: 10 Steps to Successful SharePoint Deployments

A common word that keeps popping up around SharePoint deployments is “Governance,” as if it will help you avoid chaos and have a more successful deployment. The answer is, when executed properly, it can. Governance consists of rules and guidelines for designing a service offering. Its goals aren’t to shut down a deployment and make it take forever, but, rather, to find balance in user flexibility while providing for IT oversight. Here are 10 key steps to help you be successful in designing your SharePoint deployment.

1. Confront Reality

Understanding where your company is in its maturity of SharePoint can better help you understand the next steps, as well as the challenges your corporate culture will face. Confronting reality is something that can be done at any time during a deployment. Often, it isn’t a greenfield deployment; there is already something in place, and that current solution may or may not be working. Why?

An assessment of your Intranet, collaborative platforms, file sharing platforms and usage scenarios will help you understand where to begin. It’s time to wake up and see that there are better ways to do things, and you may need resources to accomplish this.

You will find that making any changes will affect the balance of empowerment for the business, and give up some control from IT. It may feel unnatural at first. Doing this with the out-of-the-box deployment often is where companies start with SharePoint. They find that giving the business site collections to create projects, workspaces and team sites makes them very happy.

The balance can get out of control when the business is left with a default install. The default install has faults. There are no quotas enabled, and all data goes into one content database that continues to grow until it fills the drive. Auditing is off, versions aren’t enabled and chaos can reign quite easily without some forethought about the answers to these questions. The newbie mistake is to decide to figure out many of these things later. Later comes too late, when the environment is down or, worse, never backed up. Again, it’s something that by default isn’t automatically configured. Backing up the drives isn’t good enough. The data is in databases, and the binaries and development assets are on the disks, while the configuration is spread across the system. This might seem obvious to those running the system for awhile, but unfortunately it is a common mistake.

2. Create a Governance Plan

Before we can create a governance plan, we need to understand what governance is. I’m a fan of the definition from the Burton Group: “Governance uses people, process, technology, and policies to define a service, resolve ambiguity, and mitigate conflict within an organization.” The governance plan does just that—it defines the service, roles, team, technology and the policies.

People – Think virtual teams. The roles for a SharePoint environment can be as simple as a Portal Admin and an IT Infrastructure Admin. This provides some level of delegation and empowerment for the business, while maintaining patch levels and optimizing administrative tasks by someone who has the appropriate skill set. The larger the enterprise, the more these tasks become divided into roles stemming from a development lifecycle. It may be an SDLC (Software Development Lifecycle) or an Operations framework like MOF 4.0, where a framework is laid out with staged deployment involving different roles— the Dev team, the Test team, the Ops team, the Engineering team and the Service Manager, along with the Project Management Office. A support desk, along with communication functions and release management, can provide these teams with simple to highly-structured support, based on the requirements and complexity of the application and organization.

Process – The process for this service most often determines how the site or site collections live and die—it’s about the lifecycle management of the unit of provisioning. Exchange supports mailboxes and SharePoint supports Site Collection as its most scalable unit, but, in some cases, the unit of provisioning actually is a site. The process is the system set up to support the provisioning process. Imagine it as a workflow from creation all the way through to the archive and deletion process. Who can create sites? Who approves them? How are they managed?

A great way to achieve stability and address cultural issues is to include Site Admin training as a prerequisite to owning a site or site collection. In the training session, you could include HR policies on security and risk associated with your information policies. Your SharePoint community will be happy they were told the rules ahead of time.

Technology – The technology is the platform. It’s also what I like to call the “Buzzwords.” In nearly every SharePoint marketing deck, you will find the SharePoint pie. This pie consists of buzzwords from Portals, web content management, records management, BI and others. The SharePoint Platform is plastic, so mold it to support the service you envision.

Policies – Customization policies will keep you out of trouble. Security policies are right up there, as well. You need to establish the rules of the game and learn how to enforce them. A customization policy might define who can use SharePoint designer, or, it might determine how you support custom development assets and how they are evaluated even before reaching your dev boxes.

Service – The service is what you’re building. It’s what helps you be consistent and achieve scale. The service definition will give you, in black and white, what everyone agreed that you would build and support.

3. Get an Exec Sponsor

Without a stakeholder who has a budget, your deployment is doomed from the start. You need the visibility and support of the business. At Microsoft, they are called shadow apps. The key stakeholder might be the director of HR, Marketing or Communications. It isn’t always the CEO, or even a C-level executive. While it is great to be on their radar—and have the awesome visibility that goes with a spot on the radar screen, the day-to-day details are rarely discussed in the board room. The CIO’s vision for information management and the ability to support the growth of the business is critical. The platform the CMO chooses to push the marketing message can either hurt or embrace your service. Vision is a key word.

 4. Create the Dream Team

You don’t need to hire an army. You can find people with the right skill sets right in your corporation. It also is extremely helpful to have the guidance of someone who has performed previous SharePoint deployments. Microsoft’s SharePoint Deployment Planning Services provide the option of working with a skilled partner to get your service scoped. I can’t over-emphasize the importance of training by a skilled SharePoint instructor, especially one who is a SharePoint MVP. There are many out there who have built instruction based on their deployment experience. While Microsoft’s Official curriculum training may help you learn how to install, the insight of the instructor will provide the core lessons.

5. Build Services not Stuff

While a lot of Microsoft applications come with a simple wizard-based install, you would never just install Active Directory or Exchange and then hand over the keys to someone. It’s the same with SharePoint—you need to design a service around it. You need to decide what you’re providing and how you’re providing it. This service-based approach will help you to scale, and set the expectations of the business. It’s an approach that is mandatory to achieve the core requirements of the business and IT. Balance is essential to success, and the only way to achieve it is to scope the service and roll it out in a phased approach as the service delivery team can handle the rate of change.

6. Define Clear Policies and Standards

The assembly line was built on the idea of standardization. “You can have any color car you want, as long as it’s black,” Henry Ford said. While automakers have come a long way since then, standardization is what allowed them to support high demands and keep their costs low. In IT, the commodity service of SharePoint needs to be very similar. The service provides a consistent quota, template, and provisioning and de-provisioning processes. The business users can expect a consistent service, know what they’re getting and adjust their needs around it. You may find off the shelf tools such as the Quest Site Administrator tool (http://www.quest.com/sharepoint) or the codeplex sp configurator tool (http://www.codeplex.com/spconfigurator) can help you set and keep your auditing policy settings consistent. Out of the box there are challenges for turning on settings across large numbers of sites to capture who changed or deleted a document, settings not enabled by default.

This is not to say that a custom application-based service can’t be successful. It can be very successful when similar principals provided as policies are adhered to. Customization policies, for example, may require that all code introduced into the environment be rolled up in a solution package. It may require that third party software have support and maintenance agreements to avoid situations where problematic code has no developer. Within an organization, it may require all code introduced into the SharePoint environment to be supported not by an individual, but by a development team associated with a division or business unit. You don’t want to be stuck supporting an application where the key and only developer just left the company.

7. Invest in a Scalable Information Architecture

The capacity boundaries of lists, site collections, sites and so on may quickly be passed on as things that are only of concern to IT. Think again. Unfortunately, the reality of the scalability of lists is a somewhat common issue. This issue is ultimately escalated to IT, but it could have been prevented by a bit of end user training in the use of folders and custom views.

Web Applications – These are good for memory isolation and department level applications in a multi-tenant environment. You do want to limit the use of these objects as they require a lot of memory.

Site Collections – The most scalable object in SharePoint is the site collection. It is the most common unit in a collaboration environment, and is automatically enforced with my sites. This is the rollup of ownership, permissions and galleries, yet is the smallest unit of quota.

Sites – While site collections obviously are collections of sites, they can contain more diverse sites. They are useful for breaking up content and often are used in delegation of an internet site or Intranet portal. They can be useful for separating one project from another as they each have a separate home page with web parts and lists.

Discovery is an important part of any Intranet SharePoint deployment. Navigation, site directories and cross-site navigation can help make content more consumable. Users definitely will be happier when they can actually find things.

8.  Don’t forget Change Management

Running SharePoint on a single box is a challenge. The biggest mistake a newbie can make is to put all the eggs in that one basket and then forget about it. What happens when someone needs a webpart? A simple rollout can take down the environment due to a memory leak. Even a service pack can put the environment at risk. You must have an environment where these issues can be fleshed out. The more complex the environment, the more like environments are required: development teams need a dev environment and IT teams need a preproduction evaluation environment. What about restores? What about test? With virtual environments, these can quickly be built up and torn down to perform validation, or they might exist as long as work is being done on the development projects. The key here is not only to stage the deployment effect of a software lifecycle, but also to manage change and mitigate risk. IT is working on evaluating Service Pack 2 and the dev team is working on the latest solution. You don’t want them both to go out at the same time, because any issue will result in a finger-pointing and yelling match. No one wins. Stability comes from managing risk.

Change control dictates that changes are rolled out and validated at each stage, and production changes happen during a maintenance window where usage is brought to a minimum and communication is clear about what’s going on. IT is happier, Development is happier and the business reaps the benefits of high availability. The change management process can involve a change management board or a release manager, or, it can be as simple as a SharePoint list tracking changes rolled out and validated by the infrastructure. A note of caution: make sure your key steps to recover a deployment, along with the change management list with the package’s deployment, are not found only in the deployment you’re trying to recover. Various straightforward ways exist to accomplish this beyond a client with offline capabilities.

For example, a development environment is set up, code is introduced by the business units and the policies are established. Tthe code is wrapped in solution packages (.WSP), tested with standard unit tests, including one for memory leaks using SPDisposeCheck. Code introduced goes through a staged deployment process and is stored in TFS with source control and a change process. All this requires more resources, and that’s where the tradeoffs exist. Are you building high value applications on SharePoint or are you designing an out-of-the-box service with the concept of a commodity or utility in mind. The commodity out-of –he-box design may not include just the out-of-the-box code, but also may have features benefitting everyone who went through full scale rigorous performance testing. It’s about tradeoffs.

9.  Adoption is What Counts

You could create the most fabulous, rock solid SharePoint deployment but, if no one uses it, your efforts were wasted. In the section above on confronting reality, we mentioned that you need to understand where the business is, and what other platforms are available. You can’t force feed the business, but you can lead it to the solution through training. They likely will be very happy to be involved in the master page acceptance and will provide feedback on the navigation. While they may not understand the challenges of deciding whether the service should provide sites or site collections, they may be able to tell you which of their requirements can be impacted by that decision.

Adoption doesn’t end after deployment. Care and feeding are required throughout the lifecycle of the environment. SharePoint deployments don’t need to be stagnant. They can evolve along with the skills of the deployment team.

10. Keep it Simple

Overly complex and over-structured deployments can bring a deployment to a halt. In all of this guidance, it may sound like a ton of overhead is required. In reality, it’s more about having insight and using that insight to provide flexibility, and providing clear boundaries so your users can achieve scale and build the solutions they are so interested in using.

SharePoint is a lights-on experience; not everything needs to be enabled from day one. All of the functionality from forms allows workflows, BI dashboards and Excel services to wait as users figure out how to create and manage a list. They can learn how search works, and emphasis can be placed on making it work. Relevance is something that easily can be managed with some focus on what users are looking for, as well as paying attention to keywords and placement on the portal in relation to what they need.