What process do you use to provide new SharePoint site collections to your users?

A better way to create SharePoint sites is a topic that has been around as long as SharePoint itself.  There are many pain points to the process that any SharePoint administrator, and user for that matter, go through.  Let’s just start off by making the assumption that you want a little more control than what self-service site creation offers.  Some SharePoint experts have commented that self-service site creation in SharePoint is not an enterprise ready solution.  My next my post will go into more details on that topic and offer a solution that is enterprise ready, but in this post I’d like to share some of the problems from my experience and give our readers a chance to chime in. 

So let’s discuss what you do based on the above assumption that you require something better than SharePoint’s out-of-the-box self-service site creation.  

There are two primary pieces; the request/approval process, and the site creation.  Over the last decade as a SharePoint administrator, I saw my fair share of attempts at processes to master this.  For most team and project sites - the one’s that generally generate the majority of requests- you will want to do separate site collections. This is simply easier to manage, set quotas, lockdown securely, and a multitude of other advantages over simple subsites.  Site collection creation happens in Central Administration.  So for every new project or any new set of collaborators, a new collection is required.  This means the info needs to get passed to your SharePoint administrators as they are the only ones that should have access to Central Administration.  

There are too many options for how you get the request to the SharePoint administrators to discuss in detail in this article.  I’ve seen everything from paper forms filled out, then passed around to managers for approval, then dropped off at the administrators desk, to a simple SharePoint list with approvals that eventually makes its way to the administrators.  I’ve also seen the help desk or business owner team utilized for starting the process that gets passed around.  The common denominator is the request going through some approvals and ending up with the administrator.

SharePoint administrators are a valuable asset with better things to do than creating sites, honestly.  It’s a waste of their time, and a waste of the company’s money based on the average salary of a SharePoint Administrator.  However, with SharePoint’s out-of-the-box design, it’s a necessary part of the SharePoint administrator’s job.  

So, as an administrator, how do you go about provisioning new site collections?   One approach is to create the site collections manually each time, adding the appropriate access based on the request form received, and then notify the requester when complete.  That’s in the simplest form of site collection creation.  What if you need certain features activated, a custom branded template, or a certain subset of lists and other custom settings?  I’d guess the simplest form version takes 15 minutes to complete by the administrator (not counting all the time to obtain the request,  receive the proper approvals, and communicate back to the requestor when finished).  I’ve worked in places where the site setup involved much more and took upwards of 2-4 hours to do all the setup to meet the requirements.  It doesn’t take much math to realize just how much time it takes do manual site collection creation, and what that costs you in terms of real dollars spread over a year.

Once this pain is realized, you start to think of ways to automate this.  PowerShell would be the most common way to automatically provision the site.  It’s not the most difficult task ever, and can be worth the investment time.  You could create a SharePoint list, write some PowerShell to receive those inputs, and have your site provisioned.  Unfortunately in my experience, that’s not an area of expertise many SharePoint administrators have.  The more you want to do to the site, the more complex the PowerShell script gets, and thus the more skilled your administrator needs to be.  

In my experience, pleasing business site owners is a very difficult task - one that really doesn’t end.  Once you stop being the site provisioning bottleneck as the SharePoint administrator, by scripting the process, the business site owners are happy.  Unfortunately, that is generally short lived.  Once automated, there are more and more requests to customize that site creation process.  It becomes increasingly complex and time consuming to go through the entire dev, test, roll-out process.  You’ll likely look back at the monster you created, and the amount of time you spent on it, and wonder why you didn’t just stick with manual creation.

Site provisioning and governance are major topics at any company that has a SharePoint environment.  Unfortunately, the topic generally hovers around the fact that they don’t have a great solution for either.  My next post will discuss an option to handle both for you, quickly and easily, without writing any code.  Not only will it handle the site provisioning and governance piece, but also the entire process, beginning with the initial request and approvals needed.

I’d love to hear from you in the comments, on some pain points, or successes, with your site request and provisioning processes.