Governance is more than just a 10 letter word

As Microsoft continues to expand the capability of SharePoint so does the complexity for the architecture and integration of the system for enterprises of all scale. What I have noticed from my attendance at various SharePoint conferences both paid as well as the Saturday events, the level of expertise for the “SharePoint Guy/Gal” lags far behind what is needed for a successful implementation. I am not in any way knocking the person but rather the fact that on the curve of learning to mastering, it appears that many people are being thrust into the implementation before they have  accumulated the knowledge necessary to not only overcome technical obstacles for getting the software bits installed and running, but also the ability to draft/publish/communicate the do’s and don’ts for the businesses fancy new IT system.

Fortunate for all, there’s a vast ecosystems of “experts” readily available to help you through all aspects of your SharePoint engagement including the draft and publication of your organization’s Governance plan. When I speak about Governance, I want to specifically throw out any discussion about the operational aspects of managing the environment. I am not saying that developing your backup strategy and service level agreements are not important – which they really are not.. Your customers want the system available 24×7 and they want you to be able to restore to the point before they had a problem. But really you have a few three really important decisions to make about your environment:

1. What level of access will you be giving to users?

By far, this is perhaps the most important decision that you and your team will ever have to make. First off, if you start out giving users “full control” and then water it down to something else you are going to be fighting a Braveheart style battle. My recommendation for getting started with SharePoint would be to create the following groups/roles:

a. Business Power user – I would take full control and strip out create subsites, create groups, manage permissions, etc.
b. Contributor (without delete) – same role as contributor but take away the ability to delete
c. Read-only/Visitor – out of the box
d. IT Support – somewhere in-between the Business Power user and Site Collection Admin/Full Control

The trick for the business power user would be to make that group the owner for the Contributor & Visitor groups to that the business can manage the membership for those groups.

2. Will you establish quotas or let SharePoint become a dumping ground?

Some may feel this falls under the “operations” category of their Governance plan, what you really need to figure out is how rapidly do you think your users are going to fill SharePoint up with content? Then even more importantly, do you want any sort of “governator” in place that helps stop a site collection from growing to the Microsoft supported 100 GB limit which generally is a real pain in the ass to support in case you ever have to backup/restore it. I personally strongly recommend quotas for the simple reason that they are conversation starters. When you put a limit on how big a site collection can grow, you will force a conversation when a user hits that limit. By having that conversation you can better understand how the business is leveraging the platform and consider any improvements to either your service or their processes.

Another important “quota” to consider is what is the maximum file size that you will allow to be uploaded into SharePoint. Keep in mind this is another one of those gems that Microsoft publishes the maximum is 2GB but in all practicality, the limit I would recommend would be no greater than 250 MB. Typically from what I’ve seen any file that is over 100 MB is typically not meant for collaborating on. It is usually a PowerPoint Deck with high resolution images where the original creator is not aware of compression technologies.

3. What type of Development/Customizations/3rd Party Tools will you support?

Perhaps one of the most comical parts of deploying SharePoint is that moment where you realize that you will often requires 2-3 ISV’s to help fill the gaps and make it usable in your enterprise. It is typically a few months after the finance folks finish patting themselves on the back after battling with Microsoft Licensing to get all the terms & conditions of your Enterprise Agreement all wrapped up. In addition to the ISV’s you are going to find yourself in a situation where pockets of users will want to customize SharePoint. At first it is a logo here or some fonts there, but eventually a user is going to have a “requirement” that SharePoint “does this”. That will be the moment when you get introduced to even more SharePoint “Experts”, your neighborhood friendly SharePoint Developers. If your environment is 2010 then you’ll need to guide them towards either Farm (GAC) or Sandbox solutions – or if in 2013 you’ll likely want to explore the new App model.

The number one piece of advice that I can give you is to try and establish your Development standards as a “use out of the box first” and visual studio developed solutions second, especially as you continue to grow your knowledge as to what SharePoint does provide as part of your multi-million dollar EA agreement. The one caveat that I want to say is throwing a bunch of javascript into a content editor webpart is not really leveraging out of the box. 🙂

The number two piece of advice I can give you is to do a snapshot of performance before/after you receive custom code from your development teams. I cannot count the number of times where I have received code from offshore that caused response time to double or triple.

I am sure there are people that can point out other “important” topics, but from my experience those are the top 3 that should be addressed early on in your governance discussions.