Look up the word “governance” in wikipedia and you’ll find sentences such as “It relates to decisions that define expectations, grant power, or verify performance. It consists either of a separate process or of a specific part of management or leadership processes. Sometimes people set up a government to administer these processes and systems.” Ok, that’s not terribly vague. Now, trying to put that into SharePoint terms the following come to mind:
- Business Continuity
- Customization Policy
- Deployment Model
- Governance Model and Policy
- Governance Board or Committee
And on and on. If you take some time browsing through the SharePoint Governance site on TechNet, you’ll find a wide range of topics as well as multiple sample governance plans in the content and links therein. Point being, the single word of “governance” quickly expands to cover a wide range of topics. If we’re not too careful when selling or delivering governance, we can easily get caught up in trying to cover every angle and aspect and can end up creating a true Government bureaucracy that rivals Washington D.C. Not a good thing for SharePoint to be successful.
Because SharePoint Governance covers such a wide range of topics and companies have varying priorities and strengths/weaknesses, governance is defined differently for any given company. There is no “one size fits all”. This makes it quite difficult, if not impossible, to provide an accurate list of topics that must be defined in order for the governance check box to be marked as complete. Another complexity is that if governance is done right, it never is complete. It’s living and grows with the organization.
Whether you are in consulting or are a driving force for SharePoint within a company, this makes selling the concept of governance difficult. Maybe to clarify a bit, it’s difficult to sell governance to leadership and have a clear definition of what will be delivered.
To give an example, I recently completed a governance project (the inspiration for this post) where the definition of what was to be delivered was defined up front down to the governance topic level. That was great for both estimating level of effort and defining expectations with management up front, but due to the variations mentioned above, that plan needed to be flexible. It wasn’t. It was near impossible for a PM to track actuals back to specific tasks listed in the governance definition because as the process of discovering the governance needs of the organization progressed, those tasks needed to change.
How to be successful then? First and foremost, get executive commitment. This is one SharePoint topic where I think it must come from the top to be successful. If the executives show support and dedication, and back up that statement with funds and a project to ensure its success, the entire company will see that commitment and organization and be driven to meet expectations. Second, define scope by listing areas of focus instead of specific policies to include in the governance plan. For example, operations, user training and experience, and the definition of the governance process are all items that must be touched on and the detailed definition of which comes through the process of defining governance. List them in the scope, and deliver by holding stakeholder meetings and make recommendations based on the needs and capabilities of the organization. Finally, there is the discussion of time and cost. As a rule of thumb, I’d recommend three to six weeks. At least three to get to the point where governance has been defined enough to be able to kick off a governance process, and up to six to make that process more refined and solid to eliminate some of the vague areas that will exist if only a three week effort. Following the initial effort is where the executive commitment really pays off as the process involves the right people at the right frequency to ensure the governance process and policies grow and change to meet the organizational needs.