Don’t get confused with the actual built-in SharePoint Site Templates, it’s not what we’re talking about here. When we build a SharePoint Governance Plan, we need to clearly identify what kind of sites can be requested and what their definitions are. By that, I mean their intended purpose as well as what they come with in terms of features and policies. Don’t expect to see « Team Site » « Blank Site » « Publishing Site », we are making this governance plan for the business and to help them by providing guidelines on how to use this enormous platform.
- Part 1 – Building a SharePoint Governance Plan in the Real World
- Part 2 – You need a logical architecture in your SharePoint Governance Plan
- Part 3 – Designing Site Requests in your SharePoint Governance Plan
- Part 4 – Site Template Definitions in the SharePoint Governance Plan
- Part 5 – User Training and Agreement in the SharePoint Governance Plan
Understand why you are using SharePoint for your business
Remember, we are not building this SharePoint Governance Plan for ourselves nor are we doing it strictly for IT. SharePoint is there to help the business and that’s what the Governance Plan is there for, to help the business use the platform. If we plan to make different business site templates available for our users, we first need to know what they would need it for. My experience shows that it’s best to start with one or two and let it grow with time, for you to see how people are using SharePoint or what they need from it.
Notice I said « business site template »? A common mistake, made especially by us geeks, is to instantly think of SharePoint site templates. But fact is, it doesn’t matter. Since the Governance Plan is to help guide the business to better utilize SharePoint in some way, it’s important not to confuse our business users with SharePoint terms.
So before you go any further, make sure you know what you plan to do with SharePoint.
I am serious, it may sound like a ridiculous question, but more often than none I meet customers that do not have a clear vision of what they are doing with SharePoint. Usually it’s the ones that have the license through some other Microsoft offering. « No, I know what we want and that’s to collaborate » is not a valid answer. Try to explain it to me, if you can explain to me what you want to do with SharePoint and how that’s going to help your business, than move on to listing the business site templates you will need. You can always start with Discover Sharepoint Guide
Start by listing the business site templates in your Governance Plan
The SharePoint Governance Plan will have a lot more information than just the Title and Description of your site templates. However, for now that’s what we should start with to get us in the right direction. Depending on your business need, list the site templates you plan to work with in your SharePoint.
An example of site templates in a governance plan could be:
- Team site
- Community site
- Project site
- Ad hoc project site
- Sandbox
- Application
A site for members to collaborate on documents and help the members produce content amongst themselves.
A site meant to produce content or publications for the entire company instead of just the members like a team site does.
A site for members to collaborate for specific long-term projects.
A site for members to quickly create and collaborate on usually short-term projects.
A site meant for users to test any kind of actions before applying them in their own production site.
A site tailored to a specific business process that usually requires custom development.
I cannot stress this enough, it’s not because they are called Team Sites or Community Sites that they refer to the SharePoint Templates. These are simply what they planned to be named in our business, that’s what the Governance Plan is here for, to help us set these guidelines. As an example, the Team site, Community site and the Sandbox site could all be using exactly the same SharePoint template with differences only in permissions for each of them. At this point, the SharePoint Site Template we plan to use is irrelevant and in most cases, I barely even mention that in my SharePoint Governance Plan.
**Note: Something I don’t mention enough in this SharePoint Governance series of articles is that each step should be done by specific people. Remember when we identified the Roles and Responsibilities in Part 1?
Governance Plan should include site management policies
This step should and most likely will be different for everyone. In a SharePoint Governance Plan, we usually have a section that details the available site management policies. What exactly do I mean? For me, these are the named policies I can refer to, that details out what can or cannot be done in the site to manage it. An example could simply be defining if the owner can create his/her own lists and libraries. Depending on your organization’s culture and level of SharePoint maturity, you may only need one or two policies. From experience, try to keep the number of policies as low as possible. I know it will be difficult, especially when business users will come asking for exceptions or the right to create those lists and libraries. It’s inevitable, but that’s why the Governance Plan and the Committee exists. One is there to set the rules and the other to make sure it is enforced.
When starting out my new Governance Plan, I’ll usually have only two Site Management Policies defined. And I begin with the one that controls as little as possible, the uncontrolled policy. There, I describe what is allowed as well as not allowed in a site that uses this site management policy. The beauty of this is that the policy is not linked directly to your template, yet. In the future, you can have users choose a site template and offer a site management policy to go with it.
Here is an example of my uncontrolled site management policy:
Allows the site owner to do the following:
- Manage user access to the site
- Create and delete sub sites
- Create and delete content types and site columns
- Create, manage and delete lists and libraries
- Site Owner is responsible for content published
The following cannot be done by the site owner:
- Delete the Site Collection
- Activate or Deactivate Site Collections Features
- Change the Master Page
- Create and delete new Permission Levels
- Change the Search Schema
Obviously these will change based on what you are trying to accomplish with SharePoint and is why I asked you to start by understanding what you plan to do with SharePoint, what is it for. You can do a similar activity for the controlled site management policy. Depending on your organization you may need others, but I encourage you to keep it to as few as possible.
My Controlled site management policy will usually be very restrictive and managed by a special well trained and experienced team. But this can be changed and should always be defined in the Governance Plan.
At this point in the governance plan, I’ll also add some roles and responsibilities if they are tied to or changed depending on the site management policy. For example, I’ll add Information Architecture, Content Creation and Security Management as part of roles in which their responsibility may change based on the site management policy. Content Creation responsibility might be for the Site Owner in an uncontrolled site, but to another group or person in a controlled site.
SharePoint Site Retention and Deletion in the Governance Plan
Set expectations from the very beginning, make sure the business users of SharePoint know exactly what happens to their site in the future. Here, I usually define the different possibilities by giving them self explanatory names not unlike what we just did in the Site Management Policies. Of course, at this point it’s important to understand what can be done by SharePoint before you start setting rules that cannot easily be upheld. Don’t get me wrong you can use free tools for Governance to find all Sites that haven’t been modified for 60 days or been created 3 years ago, but start with simple things you can do and manage.
Start by naming and describing these Site Retention and Deletion policies, but keep it simple. Remember it all comes together at the end and needs to be easily consumed by a business user going through the site request himself. The technology aspect of this does not need to be included in the Governance Plan.
Here is an example:
- 90 Days Delete: Sites created with this retention rule will be deleted 90 days after their creation.
- End of Life Read Only: Specially targeted to Project Sites, site will be placed in read only once the project is finished.
- 90 Days Lockdown: Site will be locked down after 90 days of no activity on the site. Administrators will manually go through the locked down sites and delete.
Of course, you can create as many rules that fit your organization. The Governance Plan serves as a guideline, but also as a reference or go to document to find all of this information quickly and easily.
Remember that your Governance Plan can be a Wiki, thus allowing visitors to quickly jump through hyperlinks and find all this information. It also allows you to create it in phases and not all at once.
Putting it all together as SharePoint Site Template Definitions in your Governance
To be able to get to where we are now, we’ve made sure we understand the need for SharePoint and what we plan to do with it, listed the site templates, defined site management policies and even retention rules. We can now create our Site Template Definitions and serve it to our business users in a format that can easily be read and understood. In my next article, I’ll talk about the user agreement as well as putting the Site Requests and Site Template Definitions together into your process in a way that makes sense. For now, you should be able to create an easy to read table with all the information, one that fits your organization of course. Once you have this, you’ll be able to decide whether the information is sufficient or if you’ll need more.
You may start to realize why it’s also important to have someone who knows how SharePoint works to build a Governance Plan. Setting these guidelines can be easy enough on paper, but how will they be technically created to fit the need is another story. A shameless plug, but I will because it’s free right now, is the Sharegate Governance tool. You can easily make sure Sites, Lists and Libraries or Documents respect some your policies.
I’ll leave you with this, remember the SharePoint Governance Plan is not a documentation of how you want people to use your platform. It’s a set of guidelines, that will help them understand how to use this platform in the best way possible to ensure the organization benefits from it in the end. Because it’s such a vast platform, it’s important to help them understand what they get or what to get depending on the need. At this point in time, you have a way to show them the different Sites they will be able to request as well as what they will get with it. This small change can already have tremendous impact on the adoption and success of your implementation.
If you can visualize your Site Request form with fields asking the business user or whomever what site he wants. Then for that person to quickly jump with a hyperlink to the Governance Wiki that shows this table for him and understand what it is and what it comes with, but most importantly what can or cannot be done for each.
