WHAT YOU WILL LEARN IN THIS CHAPTER:
By this point in the book, you have learned many things about SharePoint 2010, including how to create lists and libraries, how to build workflows, and even how to work with the personalization features. It is likely that your head is spinning with all the new information you have gathered as you read through all of the new and powerful things that SharePoint 2010 brings to the table. Now, as we are nearing the end of our journey together, we will be introducing the concept of governance. This topic is so central to the SharePoint implementation, that we have dedicated an entire chapter to help you identify and implement a strategy that works for your organization.
The dictionary defines governance as the act of maintaining control and order. When the definition is applied to SharePoint, we develop the concept of SharePoint governance as being the processes and procedures in place to help maintain control of the environment. Because of the breadth and depth of SharePoint, many different things need to be taken into consideration when developing your governance strategy. As you have seen throughout this book, SharePoint is a tool that will cross many different aspects of the organization. Some things, such as search settings, will most likely be configured and maintained by system administrators; however, things like site workflows are likely to be built and maintained by the business units. The governance that is put in place will need to support and sustain both of these scenarios, without inhibiting them from the end goal. At first thought, this might seem like a rather daunting task. How do you provide the policies, procedures, and processes so that SharePoint can be everything to everyone? This chapter is designed to show you just that. But before we get into the specific components of governance, there are a few things we should review together.
There is probably a large range of readers who have made it this far into the book. You may be an end user who is getting up to speed on SharePoint features so that you can manage and maintain sites or you may be a IT professional who is learning the basic features of SharePoint so that you can best support your users, or you may fall anywhere in between. With that being said, it is important to point out the information in this chapter is about governance in general. If you are responsible for managing and maintaining SharePoint, this chapter will help you get started. If you are responsible for simply managing and maintaining specific SharePoint sites, then this chapter will help you see all the work and effort that goes into the system. You may find that you are part of the SharePoint governance team that is built or you may find that you just interact with them as needed. Either way, this chapter will help give you a good understanding of what is included within SharePoint governance and best practices for implementing governance. Even if you aren't responsible for managing the governance, it is still very valuable to understand all the pieces.
One of the most important things to remember when building your governance plan is that your organization is unique. Yes, your organization will be similar to other organizations, but no two organizations are the same. What works for one, may fail miserably in another. When building your governance plan, it is important that you pay attention to the uniqueness of your organization and plan accordingly. If you simply take "best practices" and apply them directly to your organization, then you are in danger of creating future issues. Instead, you should be evaluating the implementation of the best practices and then tweaking them to match your organization's unique culture and environment. Let's take training as an example. As a best practice, it is important that users who are given administrative control over site collections complete training so that they are prepared for their role as an administrator. The type, style, and implementation of the training should be such that it brings the most value to the organization. If you simply copy the same approach that others have used, you may not end up with the same results. Instead, you should take the best from everyone else and then apply what will work best for your organization. Using this approach will allow you to think of governance differently. You will be able to identify the key areas that need to have policies and procedures and then you will complete a process of answering the question "What does this mean specifically to my environment?" This means that your governance policies may look different from others', but at the end of the day, you will have developed policies and procedures that will work for you internally. At the other end of this spectrum is trying to change the organization to work with predefined policies and procedures that have been identified as "best practices." Keep in mind that it is better to modify policies to match the organization before trying to change the organization through policies.
One piece of encouragement that I would like to give you before you read the rest of this chapter is to remember that no one starts with the perfect team or the perfect set of governance standards. The whole concept of SharePoint governance should be based on the fact that it is meant to change and to evolve based on your organization's lifecycle. If you are just getting started with SharePoint, then it is not likely that you are going to have a full team of people to support the effort. It is more likely that you will be working alone or working with a small team to get things started. In this case, it is important to identify the long-term needs and develop a strategy to "grow into" a full-scale support system. But the point is that you have to start somewhere, and you have to know where you are ultimately going. The biggest mistake you could make is to ignore the need for governance and take the approach of "we will work through this later, as we need it" because I promise that, once you realize you need it, you will wish you had started earlier on in your project.
The last thing I want to look at before we dive into the specifics is the need to understand the vision of SharePoint within your organization. Governance is going to be put in place to help ensure that you are tracking toward a vision effectively, using sustainable and reliable systems. Without having a clearly defined vision, it will be hard to use governance to help you get somewhere. It may help you keep the system reliable and sustainable, but it won't assist in getting you to the next level as an organization. Having a clear vision will help keep your team on track and will help you decide what projects and functionality should be the focus of your efforts. Following are some examples of different goals and vision statements for SharePoint implementations:
Provide a gateway to all systems and services provided by the organization.
Use a strategic approach for implementation that allows for a consistent and gradual release of new functionality, allowing for the portal to be developed over time to meet the expanding organization's needs.
Develop a framework that can be used for the release of future organization products and services.
Whenever possible, use the out-of-the-box capabilities to build solutions.
Improve communications by providing dynamic updates for both internal and external communications.
Provide employees a centralized location to share and collaborate on internal and external content.
Provide organization with tools that allow for departments to easily take ownership and provide dynamic updates for their content.
Provide a tool to the organization that allows for structure to be added to the day-to-day operations and procedures through the use of standardized procedures and workflows.
As you can see from the list, there are many different things that can drive the vision of the implementation. Based on the vision, it is likely that you will want to have a concentrated effort in one area of functionality before another. Remember, your organization is unique, so your goals and vision will likely differ from the previously-listed examples.
Now that we have covered some of the general areas of governance, let's dive into the details. Throughout the rest of the chapter, we are going to be diving into the specifics of setting up governance. By the time you have completed the chapter, you should be ready to participate within your organizations governance team. Your role may differ according to your level within the organization, but after reading this chapter you should have a better understanding of what should be in place to support the SharePoint environment. Specifically, the key pillars you will review are:
There are several key roles that are included in most SharePoint implementations. Keep in mind, however, that it is more important to pay attention to the specific functions of the roles than to the exact titles. As long as you have each of the key areas accounted for, the titles don't matter as much. Figure 18-1 shows an example of the various roles that show up within SharePoint implementations. In the remainder of this section, we will describe, in greater detail, each of the roles and the specific functions they contribute to the team.
The SharePoint owner is the person who is responsible for the overall implementation of SharePoint. This person is typically the person who is responsible for bringing SharePoint into the organization and also the person who is responsible for building the team that will provide the support for the implementation. This user is typically a strong project manager who is responsible for determining the best way to implement SharePoint in order to provide the greatest return on investment. The person who fills this role doesn't have to be a technical user; however, he or she should have a very strong understanding of how SharePoint works and should be able to clearly set the vision for how SharePoint should be used within the organization.
The SharePoint infrastructure administrator is the user that is responsible for the day-to-day management of the SharePoint servers. These servers are part of what is called the SharePoint farm. This farm is created when SharePoint is initially installed and consists of all the servers that are used to create the SharePoint environment. SharePoint farms are scalable, meaning that, as user demand increases, additional servers can be added to the farm to help increase the farm's capacity. The person who fills this role is responsible for configuring, managing, and maintaining the farm. This includes all regular server maintenance, as well as any service packs or hotfixes. This also includes ensuring that the server is configured in a way that is optimal to the overall goals of the organization. Configuration includes things such as disaster recovery, SharePoint Designer Settings, Business Connectivity Settings, and Excel, Access, and Visio Service settings.
Note
There are many different technologies and services that are part of SharePoint, including SQL, Active Directory, Windows Server, and possibly Exchange and even others. Based on your organization and your implementation, it is likely that many different people are responsible for maintaining all of the environment elements. For instance, you may have one person who is responsible for the management of SQL and yet another user responsible for the management of the SharePoint servers.
The solutions architect is responsible for the information architecture design within the organization. This role should be filled by someone with a strong technical understanding of SharePoint, as well as a strong understanding of the organization. This person is responsible for determining the best way to architect the environment so that it remains stable, supportable and sustainable. This person should have a very clear understanding of the organization so that they can translate the needs of the organization into a working solution within SharePoint.
Note
Information architecture is the term that describes your farm's hierarchy and layout. This usually includes the different web applications, site collections, and sites within your organization. For more information on the components that make up the information architecture, refer to that section later in this chapter.
The role of SharePoint branding specialist is given to the person who controls the overall "look and feel" of the SharePoint sites. This "look and feel" is considered the site branding. Chapter 9 was dedicated entirely to branding and went through the process required to create a custom branding solution. This role corresponds to that chapter in that the person who fills this role is responsible for determining the branding guides for the organization. Will the organization use only one master page; will each site be able to create a custom master page, or will they have to use the one created by the organization? These are the areas that this role will be responsible for determining the guidelines and standards that all sites must follow.
The role of the SharePoint help desk is to answer the various levels of SharePoint questions from the organization. It is the person/team that provides support when users run into issues using SharePoint. This function could be included with the organization's existing help desk, or an organization could have a user or team dedicated to supporting users as they work with SharePoint.
A SharePoint developer is someone who is responsible for creating custom solutions that can be added to SharePoint. These custom solutions are typically created when SharePoint is needed to do something that cannot be easily done using the out-of-the-box configurations or when there are no third-party solutions that can be purchased to provide the required functionality.
These are the users within the organization that have been through advanced SharePoint training and are familiar with all of the tasks required to create, manage, and maintain SharePoint sites within the organization. They are responsible for working with the organization and then creating and managing the sites and are typically focused on creating and managing the following within sites or site collections:
Sites
Lists
Workflows
Forms
Page layout and web parts
This group of users will play a key part in helping with the release and roll out of future SharePoint solutions. Once they have developed the skills needed to become effective Power Users, you will able to rely on them to provide meaningful input and assistance with future solution releases.
Contributors are the users who have been trained to add content to existing SharePoint sites. They are familiar with how SharePoint works and are able to navigate through sites, adding content as needed. Typically, they are familiar with the following tasks:
Adding documents to libraries
Office integration with libraries and lists
Adding list content
Starting workflows
Creating alerts
Managing personalization features (such as My Sites)
Search
These are the users within the organization that have been trained to navigate through SharePoint sites to find content they may need. Typically, these users haven't received a great deal of training and are able to navigate through the sites based on the sites' design and layout. Typically, they spend most of their time accessing sites where they are consuming information, such as an intranet or extranet site. At any point where they are required to do more than consume information, they would need additional training so that they could understand the value available when using SharePoint as a contributor.
Next up on our tour of governance are the concepts of project and change management. Project management is going to be the tool that helps you get somewhere, and change management is going to be the tool that allows users to make changes once you are there. Throughout the remainder of this section, we will be walking through some of the primary concepts related to each of these areas. In theory, these concepts apply to any area of business, but speaking from experience, when these are ignored or overlooked, some very interesting and complex issues can arise.
In theory, there is nothing unique or special about SharePoint that requires you to do anything different when managing projects. In reality, however, when this aspect is ignored, you end up with many different and unique issues all related to the project fundamentals' time, scope, and budget. It would be impossible for us to cover all the basics of project management in this small section of the chapter, so instead we will look at and highlight some of the key issues that will repeatedly pop up as you are working through various SharePoint projects.
The first thing to start with is defining your project. What is it that you are trying to accomplish? Following are some very common projects that can be completed in SharePoint. Reviewing the list will give you an idea of the different types of things we are referring to within this section of the chapter:
Team collaboration site
Document management solution
Project site
Intranet site
Goals management site
Time-tracking solutions
Forms center
When defining your project, it is important that you develop clear requirements. You can start out by looking at the project in terms of what will be done and who will be doing it. In some projects, it is easier to start with the what and work your way back to the who. Either way, this entire process should occur apart from the technology. In other words, when defining the project, this should be done in nontechnical terms. You should be taking the time to define what needs to be done and setting all technology aside. Once the requirements are clear, you will map those requirements to the technologies available. This approach ensures that you remain focused on the requirements first and the technology second.
When thinking about project management, there are three key areas that you should focus on: time, scope, and budget. Time is defined as the duration of the project, scope is the requirements that you must satisfy to complete the project, and budget is what it will cost you, which includes both hard (expenses) and soft (overhead) costs. Each of these three elements act together to define the project and if any of these elements changes, it will have an effect on the other two elements. The easiest way to envision this is by thinking of the project as a triangle, with the three sides each representing an element. If any one of the elements increases, then the others will also have to increase. If any elements decrease, then the same is also true of the other elements. This can clearly be seen when looking at the scope. If your requirements increase, then so will the time it takes you to complete it and the cost. Figure 18-2 provides a visual that can be used to represent this concept.
Change management is a key concept in any type of project. Some of the key aspects covered are what types of changes will be allowed, who will approve the changes, and what is the process to get the approval and then release the changes to the organization? The difference with SharePoint is that changes can be made very easily and often without any thought to how it will affect the audience. Consider the example of navigation. What if every time a user accessed the corporate intranet the tabs were in a different location or order? It would not take long for a user to become frustrated and unwilling to access the site to gather information. With change management in place, it is likely that a request would be submitted to move the tabs, it would be tested, and then once all the stakeholders approved it, it would be communicated to the users and then the site would be updated. There would be a process in place to handle the changes to the site. Within SharePoint there will likely be many different sites, and it is likely that there will be many different site owners. The important thing is that each of the site owners implements processes within their sites that manage how the changes should be made. If you are working on an intranet site, it is likely that corporate communications or marketing will own the overall design and layout of the site, and they will probably also own the process for which changes are requested. But what about if you are an owner of a team or collaboration site? How will you manage changes within that site? It is important that, as the site collection's owner, you have an approach that will manage the changes and that this is communicated to the site's users. This way, they will know what to look out for and what to do if they want to make a change or a suggestion.
Out of the box, there are a few ways that I can manage the approval process for managing content changes. Keep in mind that content is limited to list content such as list items or pages. For each library, I can configure the approval settings that allow me to require that all content be approved before it is made available for all site users. This means that, if I am using pages, I can create a page and approve it and it will be visible to all site owners. If I then need to update that page, I can make updates and they will only be visible to a set number of users (those with approval rights, or those configured with permissions to see drafts), who will be able to see the content. This will allow for the content to be updated directly on the production site but still ensures that it is not displayed to all site users until it has been approved by the designated approver.
The one thing to remember when working with changes in SharePoint is that all changes to the site structure and layout done through the browser or through SharePoint Designer are considered customizations. Customizations are changes that are made and stored within the database. When the site loads, it basically loads the original and then applies your changes, or customizations. All customizations done to SharePoint are done against the live site and are not meant to be completed in a staging environment and then moved to production. This means that any customizations you make will be made against the live site. You may choose to first test the customizations in a test site, but in order to move them to the production site, you would need to complete the configuration again in the production environment. As an example, you may have a test intranet site, and you may restructure the navigation in that site and get approval from all the stakeholders on the changes. It may actually take you several iterations to end up with the solution that everyone approves. Once you have the final solution, you would then need to log on to the production site and go through the process of updating the navigation links. As you are making the changes, they will be immediately displayed on the site.
Note
Keep in mind that SharePoint supports many scenarios for custom development that can be deployed to the server and don't require making changes directly to the production environment. These changes, however, are done through custom development and are not within the scope of this chapter or this book. There are many great resources available to help you get started with custom development, so if you decide that customizations is not the route for you, there is no reason that custom development won't work. It is all about knowing the tools available and then picking the tools that will work best for your needs.
Information architecture defines the layout of content within the SharePoint farm. There are several different levels included, and in this section of the chapter, we will define each of these areas, as well as provide two different examples of common information architectures. Figure 18-3 shows part of the SharePoint containment hierarchy. The containment hierarchy starts with the base servers and continues through to list content and is used to map out the entire SharePoint environment. For simplicity, we are going to start at the web application level and not the server farm level. Figure 18-3 should be read so that the lower levels are included in their parent item. For instance, lists are contained in webs, which are part of sites that are part of a content database that is part of a web application.
Web applications are created within SharePoint to provide a location for creating and storing sites. Web applications correspond to websites within IIS and can be easily identified by their unique URLs. Each web application created within SharePoint will have a corresponding, unique URL, such as http://intranet.company.com or http://teams.company.com. Web applications are created by the SharePoint Infrastructure Administrators, typically when the farm is first configured. There are usually 3-5 web applications per farm, and they are usually defined and managed by the governance team. Consider the following example for a company that is going to use SharePoint for internal department collaboration, for cross-departmental collaboration, and also for their intranet. In this example, there could be three separate web applications, one for each of the different types of content.
Content databases are the databases stored within SQL that contain the content from the site collections. Each site collection can be associated with a single content database; however, many content databases can be associated with a web application. Content databases are managed by the SharePoint Infrastructure Administrator and they are never accessed directly by the end users, but instead are accessed indirectly through the browser. For the purpose of this chapter, it is just good for you to understand that each site you are working with will have its content stored within a content database.
Sites, also referred to as site collections, consist of a top-level site and any webs (subsites). Within a top-level site collection, you can configure settings that will apply to all webs within the site collection. Some of these settings include:
Site templates
Web part gallery
List templates
Master page settings
Site collection features
Site collection policies
These settings are settings that will apply for each web created within the site collection. Only users who have been given site ownership permissions will be able to see and update these settings. Figure 18-4 shows the menu options available for site collections on the Site Settings page.
In addition to the configuration settings that make up a site collection, each site contains one root web, called the root site. This is the top-level site in the site collection where you go to access the site collection settings. Remember, this is also a web, so any settings that apply at the web level can also apply at this level.
Webs are subsites that are created within site collections that contain content, such as lists, libraries, pages, and web parts. Like site collections, webs also have different items that can be configured for the web. Figure 18-5 displays the Site Settings page for the web. Notice that in addition to all of the settings you can configure for the web, you also have a link to the site collection administration. Keep in mind that this link is security trimmed and is only available if you have rights to access these settings.
Lists are containers within webs that contain content. Chapter 2 is dedicated to working with lists, so if you have any questions, refer to that chapter.
Items are the content store within SharePoint and the associated metadata. Examples could include documents, tasks, issues, or discussion threads.
As you begin building out your SharePoint environment, information architecture planning is typically one of the first tasks completed. This task includes looking at the content that will be added to SharePoint and determining how to best organize the content. The first and most important step in this process is to have a clear idea of the types of content that will be added to the environment and a clear understanding of how users will be interacting with the environment. If you proceed with the design of the site without understanding the content, it is almost guaranteed that you will need to adjust your design at a later date. If you have a clear understanding of what the overall vision for SharePoint is, then you can design a structure that allows for growth over time as you implement your vision. Once you know the content, you can then start mapping things to SharePoint. Typically, the web applications will equate to high-level types of communication, such as intranet or collaboration.
Once the web applications have been determined, the next step is to determine how sites and webs will be created within those web applications. For instance, take the intranet, since the content is mostly static and generally small, you might decide to put the intranet within one site collection. This would allow you to easily create a consistent look, feel, and navigation throughout the entire intranet for your users. On the other hand, collaboration is very different. Each group that wants to create a collaboration site is likely going to want to manage and control their settings for the site. They also will likely have content that is dynamic and large. Based on these factors, you may want to create our sites in separate site collections. This would allow you to segregate the sites from each other, and apply quotas so that you could easily manage the amount of space each site is using in SQL. Since the collaboration teams are separate teams, it is not as important that the navigation be consistent between the different sites. In fact, each collaboration team might want to configure and create a navigation structure that makes sense based on their specific needs. Figures 18-6 and 18-7 show diagrams of the preceding two examples.
Note
Keep in mind, as we have said earlier in the chapter, that your organization is unique and may differ from the examples we have described.
You can think of operations and infrastructure as all of the pieces that are part of the puzzle that keeps the environment up and running. This includes all of the servers, the network, and the applications that are required to run SharePoint. The list of included components can vary greatly depending on your environment; however, following is a list of several different technologies that could be in place within your SharePoint environment:
SQL
Windows Server
Active Directory
Exchange
When thinking of this list and how it applies to governance, you should be thinking of how you can keep all components working together for the good of the environment. This means that, in addition to applying SharePoint patches, it is also necessary to maintain patches for the other systems such as Windows Server and SQL. Just seeing this list, it should be evident that there are many different components, and keeping up with the management of all of them could become quite the chore for a server administrator. Governance policies should be put in place that can help reduce the level of complexity related to the management of these different components. Some common examples of governance in this area include having a standard downtime window to apply patches and having a test environment that allows administrators to fully test all patches prior to rolling them out to production. Also, keep in mind that sometimes patches can be released because of known security issues. These are typically released as needed and they do not have a specific schedule, so it is important that your governance plans also support this type of scenario.
Like most things within the organization, communication will be key to the success of any SharePoint implementation. Communication with the user community is essential for many reasons. Users can typically be divided into a few different categories. They are either early adopters who want to be the first to try anything or they are the late bloomers who want to understand all the facts before moving forward. Then, you have everyone in between. Communication is really just the glue that keeps them all on the same page. If your communication plan is articulated well, it can accomplish many great things within the environment. On the other side of the coin, if you don't put effort into an organized communications plan, then it is likely that there will be confusion and chaos throughout the implementation. No one will really understand where things are going and, since there is a lack of understanding, it is also likely that there will be a lack of support. Most users of the system will be very far from the core team that is implementing SharePoint, meaning they will not be part of the day-to-day decisions and planning. Instead, they will be depending on the communications you are providing for them that explain the overall vision and goals of SharePoint. The clearer and more articulate you are able to make the communications, the more likely you are to have support from those on the outside looking in.
When communicating with the user community, there are four questions that should be answered with each communication:
These questions will directly impact each person who receives the communication. They will be able to immediately relate to the reasons behind what is being implemented as well as information on how it will directly impact how they work. They will also have all the information pertaining to how the organization is planning to get them ready for the changes. Since they are given all of this information up front, much of the fear and uncertainty is removed, and they are likely to participate more willingly with all of the new changes that are being introduced.
Keeping these things in mind, you should be able to start to see how there should be guidelines in place that outline how the SharePoint team will communicate with the user community. Having this plan in place prior to any major releases will help ensure that nothing is missed during each of the major rollouts. In fact, the governance policies on communication with end users will ultimately end up acting as a checklist outlining what needs to be done with each major project release. And, by following a set of guidelines, users will become used to the consistency in the message and over time they will know exactly what to expect from your team with each rollout.
You can spend months or even years building a complex solution that solves many business problems; however, no matter how great the solution is, if users are not able to easily use the system, then the system cannot be considered a success. This is where training comes into play. Your approach to training within the organization could have a large impact on the success of SharePoint within the implementation and should definitely not be overlooked during the planning stages. If you are able to train your users on how to use SharePoint, then the SharePoint implementation will have a high likelihood of being successful. Training should be considered at the earliest stages of a SharePoint implementation. By looking at training approaches early on, you will be able to match the training approach with the overall vision of SharePoint within the organization. Think of it this way, SharePoint is a tool that will likely be used by many different users in many different ways. In one SharePoint solution I may simply be a reader, in another I may be an active contributor of site content, and finally in another solution I may be responsible for the administration of the solution. If I am trained on the administrative items when I am only a reader it is likely that I will not be able to retain the information because I was not required to use it at the time of the training. At the same time, if I am expected to be a site administrator and then I am only given basic SharePoint training, then it is likely that I will manage my site incorrectly or in ways that don't align with best practices. This would not be because I purposely went against best practices but simply because I didn't receive the training I needed based on the tasks I would be required to complete. All of this leads us to several key things that should be incorporated into the training plans within the organization.
Training should be based on what users will need to be doing within the environment. Each user should be trained based on the role they will be filling within the environment. These roles should also be separated so that users are only trained in areas that pertain to them. They can however easily be staggered so that a user who will be an administrator first completes reader training, followed by contributor training, and then finally would complete administrator training. In this model a user who would only be contributing to the site would participate in the reader and contributor training but not the administrator training.
Training delivery should be sensitive to when users will need to apply their learning to the solution. When training occurs 3-6 months prior to the system being released, then it is likely that the information learned in the training will be forgotten and users will struggle with the system as if they had not received training. The closer the training can be to the go-live needs of the users, the more effective the training will be.
The final pillar in SharePoint governance is the area of development. This area can have a huge impact to your environment, so it is essential that governance policies are created that help define how development will be used within your environment. Development is anything that is done through a custom solution that changes the way that SharePoint behaves out of the box. This can be anything from a third-party management tool to a custom application developed within SharePoint. Custom code is typically deployed to the environment using a solution. A solution is a .wsp file that is similar to a .cab file. This .wsp file is added to the server and then deployed to the server through the Central Administration site. Essentially, when the file is deployed, all of the changes or custom solutions are added to the server. Whenever the solution is retracted, the changes are undone.
In some cases, custom development can be the snowball that starts at the top of the mountain and then quickly gets out of control as it is rolling down the hill. One thing leads to another and, before you know it, custom development is the solution for everything! This is definitely not a situation you want to find yourself in, and one way to ensure that is to develop some governance policies that help you define when you will use custom development. These policies are not meant to be an end all decision when a request comes in, but instead guidelines that should be followed. If at any point a request comes in for custom development, it should be evaluated based against your governance criteria and then a decision should be made on how to best support the request. Listed below are some guidelines that can be incorporated into your governance for development.
Whenever a request is made for custom development, it is likely that the requestor has tried to do something with SharePoint and was unable to complete the tasks using the tools available to them. Since they were unable to complete the request, then the next step is to request custom development. When the request is made, a team of experienced users should review the request and ensure that no solutions are available out of the box. If no solutions are available out of the box, then the team should review the process or custom solution to see if there might be a different process that can be followed to achieve the same results. Often, if you can simply modify part of your requirements, then you may be able to complete your solution using out-of-the-box tools and remove the need for the custom development. If during the review no alternate solutions are identified, then a cost analysis should be completed that looks at the cost to create and maintain the custom solution. This cost analysis can then be used to help determine if you should proceed with the custom development.
If it is determined that a custom solution needs to be developed, prior to development a search for third-party tools should be conducted to ensure that you are not developing a solution that can be purchased. There are many different vendors that specialize in developing add-ons for SharePoint environments, that often fill the gap between what users need and what is available out of the box within SharePoint. Whenever possible, these solutions should be purchased and incorporated into your environment. By taking this approach, you will be greatly reducing the cost that would be required for you to build and maintain the custom solution.
If it is determined that custom developed solutions will be needed within your environment, then it is important that these custom-developed components be developed according to best practices and supported approaches. In most cases, this means that any custom code should be created within features and deployed to the server using solutions. Since this book is end-user focused, we will not go into detail on these components. However, as a member of the governance team, it is important that you understand that a solution is the primary method used for deploying custom development to the server.
Now that we have worked through the key elements of governance, we will move into some practical examples of how you can implement these areas in your organization. Remember that it is never too late to start implementing governance. If you are several years into your implementation or if you are just getting started, then governance can help you. If you are just getting started, you can start with a clean slate and implement policies from the start. If you are trying to employ governance in an existing implementation, then it may take a little more effort, but just keep in mind that every step towards implementing governance is a step in the right direction. In this section, we will cover some different strategies and best practices that can be incorporated into your governance strategy to help ensure that governance is working for you and is not just another layer or red tape.
In the first section of this chapter, we outlined several different roles that are common within SharePoint teams. These different roles all play a vital part in keeping the environment stable, and it is essential that each of these roles be represented when planning for building your governance strategies. As you get started with your team, it is important that each team member be represented in the development of the governance standards. Ideally, each role should be responsible for creating the different policies that should be included for their specific area of expertise. An example would be the help desk. The person filling the role of the SharePoint help desk would be the ideal person to manage and maintain the processes that need to be defined for how users go about receiving help with SharePoint. Using this approach allows each team member to really focus on the areas that they know best and not get tied down into being responsible for areas that don't fall into their realm of expertise.
As you have learned, it takes many different roles pulling together to build and develop a SharePoint environment. As the team is built and starts working together, it is likely that smaller subteams will be formed so that each role doesn't have to have an equal presence in each project. This allows for the key players to be brought on as needed, limiting their need to be fully committed to the SharePoint implementation. This approach is common; however, in order for it to be truly effective it is essential that all team members are able to get information about all current SharePoint initiatives. This will allow for the entire team to remain up to speed on all efforts, even if they are not actively participating in each roll out. This is important because so much information will be learned along the way and each new project or initiative is likely going to incorporate the lessons learned from the last project or initiative. If all the team members are up to speed along the way, then new projects can kick off and there is no need to spend time bringing everyone up to speed on what has happened on previous projects. Also, this approach helps in creating a quick decision process. Since everyone is up to speed on the project events, it will be easy to rely on team members to make decisions. Since everyone is aware of all that is happening, there will be no time wasted in bringing everyone up to speed so a team decision can be made.
One of the best pieces of advice that I can give you concerning governance is that it is important to get started. Even if you are only able to outline the plan and fill in the details later, at least you have a map of where you are going! Often I have seen organizations who decided to ignore the time required for governance planning simply because the project timeline didn't allow for development of the policies and procedures needed. This is a common scenario across organizations that should be avoided at all costs. However, if it must be done this way, then at a minimum, review the project and identify if there are any governance policies that would need to be created for this particular project. If so, create those policies within this project. Once the project is completed, you can then go back and create the additional policies and guidelines for the environment. If you simply forgo the governance planning, thinking you will come back to it, when you do, you will likely have to adjust the way you are currently doing things based on the policies you want to put in place. Overall, it would have been better to just start with those policies from the beginning. It is also likely that governance planning will become the key task that always needs to get done but that there is never time to complete. It would be infinitely better to build your governance policies as you go, based on need, than to keep putting the whole governance development on the back burner until you have time to dedicate to the planning effort.
As you begin to work through the required areas of governance you may be tempted to create the policies and keep them loosely recorded in meeting notes and emails between team members. I would encourage you to avoid this approach as much as possible and instead work from a documented and approved governance document. By taking the time to formalize and seek approval for the governance policies, you are laying the foundation for a solid implementation. Since all the policies are documented and approved, you will be able to fall back on these policies when things come up that clearly go against what was agreed upon. This will then allow you to either adjust the created policies to match the latest requirements or cause you to rework the requirements to match the stated policies. By having everything documented and approved, you are basically creating a road map for the implementation that will guide how you do things moving forward. If the information has been created but not formalized into a document, it is very hard to then use that information to identify when things are requested that go against your policies and would ultimately take your implementation way off track.
The final warning that I would like to leave you with is that the most dangerous role to your implementation is the "jack of all trades." This is the person who can fill multiple levels within the team and who is solely responsible for many aspects of the environment. This is usually the person who would be voted MVP on the team because without them, who knows where your implementation would be! The problem with this approach is that once that person moves on and is no longer available to the team, there will be a huge skill set and experience gap within the team. This gap could end up being the difference between a team that is continually building solutions to solve business problems and a team that is trying to revamp their skill set so that they can create solutions within SharePoint. There will always be one or two team members that carry a large load on the team and it is crazy to think that you could have a team where everyone did equal amounts of work. The point is not to tell you that the ideal team is one that is impossible to have, but instead to encourage you to always be building your team in such a way to mitigate the risks of one team member leaving. If you can build this into your team strategy, then you will not be caught off guard with team changes when they occur.
We have covered a lot of ground in this chapter! If you are just getting started with governance, you should now have a good understanding of everything that it takes to build a good governance plan. If you have already been working on SharePoint projects but don't have governance in place, it is likely that, as you read through this chapter, you identified with a lot of the warnings we gave about what can go wrong if you don't take the time to create a good governance strategy. I wanted to close out with a few simple reminders as you work through your implementation. First, remember that each organization is completely unique, and while best practices are good guidelines, they need to be incorporated into your organization based on how they will best work for you. Second, keep in mind that governance isn't developed overnight. In the ideal world, you will plan for governance before you implement your first SharePoint project; however, the real world doesn't always allow for such luxuries. The important thing to remember is that it is never too late to implement governance. If you are just getting started, simply pick your biggest pain points and identify what policies and procedures you could put in place to help reduce the pain and manage the environment more effectively. Over time you will begin to build the governance policies, and each new project will be created based on the policies you have in place. You can simply learn from the past and create policies that will keep you from committing the same mistakes again.