Probably my favorite part of building the SharePoint Governance Plan, designing how Site Requests will be handled. It simply touches the geek in me, which is why I love it so much. This process, though simple to the user must be well thought out prior by us, building this plan. Remember, we’re on a quest to Build a SharePoint Governance Plan, but without the headaches and complexity we are often told to include.
Before you begin, understand that building a Governance Plan is a process. Therefore, I do recommend you start this series from the beginning where I explain Roles and Responsibilities as well as how to build a Logical Architecture:
- 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
And I can never stress this enough, a SharePoint Governance Plan does not need to be a Word or PDF document. It can just as easily be an Enterprise Wiki built as you move along with the project linking the pages together. In my experience, it is often been a waste of time to try and build it all secretly and come out months later with a 300 pages document.
Why do we need to manage SharePoint Site Requests through our Governance?
Let’s pretend your SharePoint is ready to go live, you have a few Site Templates available depending on what your colleagues plan to do with SharePoint. We’ll cover Site Templates in the next part, but for now just bare with me. Your Site Templates may include different Retention Rules and/or policies as well as back up and many other options that will vary. Obviously, these people asking for a SharePoint Site don’t know about your templates nor do they know the difference between Site Collections, Sites and Pages. What they do know and what they will ask is what they plan to use it for and that it’s called a SharePoint Site or a Team Site. Remember, just because they call it a Team Site doesn’t mean they should receive a Team Site Template. Communication and a good understanding of the needs behind the request is what’s important here.
Our goal is to deliver them the right type of SharePoint Site based on their needs.
In the governance plan, we don’t actually write the thinking that goes behind all of it or how do we choose which site to give to whom. Remember, we can keep the governance plan simple, but still provide useful information to those seeking it. You, the team as well as Power Users need to know that there is a Site Request and what to expect in terms of flow. Usually this part of my Governance Plan will simply mention how requests are initiated (form or email), who it has to go through and who will make the decision. In some cases I’ll include what the user will need to do to accept what has been chosen for him, like accepting a User Agreement for example. In this article, I’ll try to go over the details of the Site Requests and how to build it, but remember that in the SharePoint Governance Plan we simply put a summary of the process or flow of the site requests.
Collect the right information from your SharePoint Site Requests
What are the questions you should ask? Again, this is not part of the Governance Plan itself, but is part of the Governance process. We need to make sure that the rules and policies are enforced but this can easily be done by providing the right type of information to those that need it. When your colleagues will ask for a new SharePoint Site, what will you ask them?
Important: Remember that they will call everything a SharePoint Site or Team Site, those are the buzz words they learned but it does not mean that’s what they need.
So what should you ask? Well, I don’t have the answer but I can help you by giving you the ones I often ask and help you figure out what to ask in your environment. It’s important to see that the questions should and are different in every SharePoint environment. Someone in a military context may need to ask if any documents containing technical data for example will be uploaded. Questions like these will vary based on the context and help us understand the need to provide them with the best solution possible.
Depending on the type of Sites you have available, you will want to direct your questions to help you identify which will be the best fit. Start by looking at what makes your Site Templates different. Again, I don’t mean SharePoint Site Templates, I mean your business Site Templates. Technically, they can all be SharePoint Team Sites, but each with different Content Types and Retention policies for example.
Some questions may be as simple as:
- Name
- Phone
- Department
- Manager
- Site Name
- Desired Date
- Desired Administrator
- While other questions may help you better understand the actual requirements:
- What will the site be used for?
- Collaboration
- Project
- Community
- Publications
- How long will you need it for?
- What type of documents will you be working on?
- Have you done the provided SharePoint Training?
Based on your previously built Logical Architecture in the SharePoint Governance Plan as well as the different Site Templates identified and their policies, you will be able to ask the right questions.
As much as possible, we want to be able to know exactly what kind of site to give them based on this form without any back and forth. Of course, in some cases all they need is an extra library with views or a page. It’s important to understand what they are trying to do, that’s why human interaction in this process is often inevitable.
Ways to build your SharePoint Site Requests for the Governance Plan
And this is where the geek inside of me thrives, how do we build this SharePoint Site Request form. My only advice, don’t go crazy with the geek inside of you. It’s tempting to spend months building a solution but it might not be what you need. There is only one important thing here, and that is understanding what the requestor actually needs to be able to deliver it. I’ll cover a few different ways you can build this form, but only choose the one that fits your needs.
This may sound silly but a simple email to the right person that can approve can still be the right way to do it based on the organization. Outlook supports forms and you can easily build what you need. The obvious benefit is the time it will take to build this solution, little to no effort is required. You might even have the questions on a page that asks to send the answers via email and you are good to go. The drawbacks however are in the lack of automation and management of incoming requests. They are nothing but emails after all.
InfoPath and PDF Forms
An easier way to make sure the requestor answer the right questions properly, is using forms. You can build your own, either by using InfoPath or PDF. Do note however that InfoPath has its days numbered. The advantage here is in offering a well designed and easy to fill out form and still controlling how the information is sent. An email would be free form and require you to analyze each individual emails to understand the need. Whereas a form can quickly collect the information and provide a good overview. Forms can be filled out either on the web or sent by email.
SharePoint Lists
The obvious choice in many ways. A SharePoint list or document library could be exactly what we need to store and manage SharePoint Site Requests. You can easily create columns as well as a design the form in which they will be displayed to collect information. You can then easily add a Content Approval Workflow or build your own to make manage these requests. If you have the expertise, you can go as far as automate Site Creation based on what is inside of this list and even build custom solutions driven from it’s content. And this does not have to be all done at the same time, it can be added later on in the project, which makes this option one of my favorites.
Custom Development (Solutions, Apps, etc)
Though this can be included in many ways to our previous choice, SharePoint Lists, I added it because given the resources you could build your own mechanism with anything. For one of our customers, we’ve gone as far as creating a Tenant App in Office 365 that would do just that.
It all comes down to what makes the most sense given the requirements.
Plan the approval process for the SharePoint Site Request
Once you have the questions that will help you understand the requestors need for a new SharePoint Site as well as the form itself to submit the request, you’ll need to configure who and how to approve them. In other words, once your colleagues take the time to fill out the form and explain why they think they need a new SharePoint Site, how will you address these? Though, technically we will need to continue our SharePoint Governance Plan and identify our different Site Templates and what they will offer, this is where a decision is made and a site is either given or not.
This approval process for a SharePoint Site Request can either be manual, with someone actually reading and understanding the forms submitted or automatically. Though in many cases, our wish is to automate this process completely, I find it hard not to have someone go through each to better understand the need and see if a Site is actually what they need. Too many times have I seen SharePoint Sites get created when I simple List or Document Library with the proper configurations would have done the job. And this bring me back to my first article in this series, identifying roles and responsibilities. Who will be in charge of reviewing these requests and making the final decisions?
In the SharePoint Governance Plan, delivering Site Requests
After all, we are trying to a SharePoint Governance Plan here. The Site Request forms and the process around that is a part of the project by itself and is very important to do, but is not and should not be in the Governance Plan. My SharePoint Governance Plan always includes a small section for the Site Requests, where it clearly identifies every part of the overall process. For example, I will usually say that when a user needs a new site inside of SharePoint, a request must be submitted to « insert where this will be initiated » by « insert method to fill out the request ». Then, « insert person identified in roles and responsibilities to review the request » will do a brief analysis of the request to see whether or not a site should be created. Once approved, the correct site template will be « manually or automatically » created and available to the requestor once a User Agreement has been read and approved.
This about sums up what it looks like in my SharePoint Governance Plan. Keeping it simple so that anyone looking for guidelines will be able to understand the process without going into details of how the Site Request is made. However, it doesn’t make it any less important to properly plan what questions will be asked and how to deliver this Site Request Form.
- 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
