The Two Faces of Governance

A perennial hot topic in SharePoint discussions is the need for governance. Ask 10 SharePoint experts about structuring a deployment and the one thing they'll all agree on is the need for governance. But I think what is typically referred as governance is really an unfortunate mashup of two different things, and those two things need to be treated separately to be effective.

Microsoft defines governance as "the set of roles, responsibilities, and processes that you put in place in an enterprise to guide the development and use of a solution based on SharePoint". That makes sense. But it mistakenly groups technical development and use into one document. In my experience, those two things are worlds apart in practical terms.

The development of a SharePoint environment, from requirements gathering to ongoing support, is primarily a technical exercise conducted by technical people. The use of SharePoint typically revolves around businesses process performed by business personnel. This crucial distinction is lost on a lot of people. Even Microsoft's own governance plan template lumps both groups into one document. But the needs of these two groups are markedly different and should be treated as such.

The technical aspects of SharePoint, as with most complex technology projects, absolutely require the creation of detailed documentation. There are myriad technical details that must be thought through, planned out, and implemented in a tightly choreographed dance to ensure minimal business impact. The information architecture and design of the SharePoint sites must be developed and implemented. Technical support resources must be developed and put in place. These folks are charged with the care and feeding of the beast, and deal with SharePoint as SharePoint, a complex system that needs to be organized and maintained in a predictable way. This behind-the-scenes detail work is well suited to extensive documentation and the typical governance plan is adequate to meet the need.

The business aspects of SharePoint are a very different animal. Here, the users don’t deal with a piece of technology, they engage with a business process. It's not SharePoint, it's the HR Onboarding application. A finely crafted SharePoint governance document full of policies and procedures will get the same attention as every other user manual they're handed. They just want to get on with their job.

And that's the heart of the matter: for the technical team, SharePoint is their job. For business users, it's not. For the techs, the governance plan is the bible to keep their system running. For users, it's just another distraction keeping them from their job.

So what do we do?

Luckily, most companies already have the answer: training. The user governance documentation should really be written for the training department (or a training firm brought in), not the end users. Trainers are the ones who know how to distill the document down into lessons the users will understand and absorb. The governance needs to be presented in terms of how will it help them do their job and make their life easier. Even though it's in reality top-down, it needs to feel bottom-up. In short, the end users need to be convinced they own their tool, and that doing things in a certain way will be in their best interest. It's a tricky balance for the trainer to maintain, but that's why they're professionals. Yes, as part of the training effort some user documentation should be created to reinforce the learning and serve as  reference, but success hinges on ensuring the policies are internalized, not just documented.

In the end, a governance plan which isn't followed is even worse than not having one, so properly planning the implementation of the user governance plan is a crucial part of planning the deployment as a whole. And here it serves us well to understand the affected audiences. Give the detail to the people who need the detail: the techs. User governance is a training exercise, not a publishing effort.