Maybe it’s the fact that I’m over in Europe on the continent for the first time in my life. Maybe it’s the fact that I’m listening to German and thinking of all of the languages that I don’t know. However, somehow my thoughts drifted across the old Greek Mythological figure of Pandora. The short of the story is that Pandora opens a box containing all of the evils of the world — and hope. The story ends with Pandora having opened the box and realizing that once let loose there’s simply no way to get all of the evil back in the box.

I was recently emailed to ask how to convince an organization that they need some SharePoint Governance. The answer I gave was to look at the Governance articles I written (Many of them are linked from the Microsoft TechNet SharePoint Governance Resource Center) and know enough about them to ask the client how they’re going to deal with a particular topic. I walk clients through governance conversations all of the time. I walk them through first with those questions — and then I move on to providing best practices, cautions, and advice about how to develop the best possible system with the least possible cost. I tell most folks that governance isn’t rocket science, it’s just a matter of knowing what things you want to manage. In fact, one of the definitions of governance — and the one I like best — talks about managing risk. That’s pretty simple — we do work on governance to mitigate the risks that empowering the end users brings.

For the most part I encourage folks to work with as little governance as possible so that they don’t stifle the enthusiasm of the users for using the platform. That works well for most things and most people. Whether you have a guideline on what files can be uploaded or not probably doesn’t matter for most situations. However, there are a handful of things that if you fail to govern up front you’ll create nearly irreversible problems. Here’s an incomplete list of things that you want to have a handle on right away — and why:

• Server Configuration Management — I’m an old server guy, I’ve managed servers for organizations. I know what happens when you begin to suspect a server. You replace it. The amount of troubleshooting and problem solving necessary to figure out what the problem is generally isn’t worth it. With simple services you can quickly recreate the services that the server offers up and move on — however, SharePoint isn’t that simple. You can’t just tell all the users that you’re going to demolish SharePoint and start over. Because of this I advise every client to maintain good (not tight or perfect) control of the servers so that they don’t have to worry about rebuilding their farm. By the way, most of the time this means that developers don’t have access and all code is deployed via a SharePoint Solution (WSP) file (See Using SharePoint Solutions to Deliver Server-Side Solutions)
• Unsupported Things — There are a fairly small set of things that Microsoft doesn’t “support.” Direct access to the databases, changing data in the databases, modifying out of the box files (with a few very small exceptions). Once you’ve done these things it’s possible that you’ll never be able to recover. For instance, modifying the database. Once it’s modified you can’t really unmodify it. Overwriting out of the box files can be undone — with care. However, most of the time if you modified a system file you did it to solve a problem (in a specific way) that couldn’t be done without modifying the file. In this situation, getting back to a supported state may be difficult, or impossible to do while still solving the same problem for the business. This is a very difficult spot to be in.
• Site Definitions — As the Microsoft Patterns and Practices SharePoint Guidance and a flurry of recent blog posts (Joel, Eric), and my article have indicated you may need to create site definitions — but they make it equally clear that you should only do them if you need them — and they should be done in a specific way. Here’s the problem with site definitions. You can’t change them. I mean this from the perspective of changing from one site definition to another and also changing the functionality of the site definition once it’s deployed. Changing from one site definition to another isn’t supported because the core of the site is created during the site creation process and there is no way to go back and re-do that process. Also, once you’ve deployed a site definition and sites have been created, you’re not supposed to ever change that site definition. If you need to change the way that the site definition behaves, you’re supposed to feature staple to that site definition.

I’m sure that I’ll get several comments from folks who will tell me other areas of governance that really need to be in place up front to avoid long term problems. So what long term problem do you think you should have avoided by having better governance up front?

Installing SharePoint is a good thing — but if you’re not planning appropriately for the user interest — you can be opening Pandora’s box.