The chasm between SharePoint Governance and Management…
I recently read a post by Dan Holme on Governance for SharePoint, that I wanted to share.
In the post Dan is pointing out the trouble many business are having with separating governance from all the other thing they need to do to maintain a reasonably well managed SharePoint service. This is how Dan put’s it:
(You can read the full post here: http://www.sharingthepoint.org/blog/Lists/Posts/Post.aspx?ID=4)
“Governance is, without doubt, the buzzword of the day in the SharePoint space. Unfortunately, there is a lot of noise around governance, and the word has become overloaded with perspectives and guidance that cover the gamut from strategic management to project management to design and architecture to service delivery. Governance has become the “catch all” for anything that an organization believes it needs or is missing to make SharePoint successful.
In recent months, I’ve tried to frame the discussion of governance in order to provide some structure as well as sanity to the noise and hype. In my recent keynote at SharePoint Connections in Amsterdam, I laid out my perspectives on what governance means—from the business to the technical layer—and provided tools to help organizations move forward thoughtfully and effectively on their SharePoint journeys. In my opinion, governance is not about documenting everything and the way everything will be forever and ever; but is more about establishing a process that enables the organization to move forward, with each step and each new solution adding to the organization’s understanding of its information and service management requirements.
Where governance ends, management begins. While service governance defines the people, processes, policies, and technologies that deliver a service such as SharePoint, too often organizations stop when the governance document is complete. They discover—all too painfully—that it’s not realistic to simply “expect” that governance policies will be followed consistently, if at all. Therefore, it’s critical to consider how to make the service manageable in a way that enforces governance policies and, if possible, automates the implementation of policies.”
Excellent points – matches my experiences very well… So where exactly does governance end and management begin?
When implementing governance around SharePoint, it seems to me that the most efficient way it to look at governance as a practice. Instead of building governance documents as a part of the SharePoint implementation project, you will probably be better of establishing a governance practice.
So what it that, then? The governance practice is an organization that delivers on excatly the things Dan is mentioning. But the practice is a “living organization” that will not only define policies, but will also maintain them on a set schedule, and report status of each and every policy and how policy controls are doing.
And with the Policy Controls, we are starting to overlap management territory. First of all…There is NO need for a policy if we dont have the means to control it. So Policy Controls must be a mandatory part of your policies. But executing a control is an operational task that must be conducted by someone. That’s why you have a governance practice (it’s not just a board).
Some controls are made using management tools (and some are not). But even if it is a management tool that identifies a policy compliance issue, it must be reported back into your governance practice, as any failed control will expose a risk to your ability to deliver value with SharePoint. And at the end of the day, you are doing governance to manage risk, right?
So – what I wanted to get across here is, that there is a very fine line between management and governance, when it comes to SharePoint. SharePoint is a very broad platform – which is a big part of it’s succes – and in many companies SharePoint is used in completely different ways than the it-folks expected it to be, exposing a major risk to the business. If you want to overcome that- and stay in control – it is not a question of functionality, but more a question of your ability to define the service you provide, and maintaining a practice to control every single aspect – business or technical – of it.