Not a hardware, software, or people resource solution. It is an organizational strategy and methodology for documenting and implementing business rules and controls related to your client’s data. It brings cross-functional teams together to identify data issues impacting the company or organization.
The below is an article written over a year ago, updated against various books and articles I’ve written to be essentially SharePoint version agnostic. Also, please be aware that Microsoft published in November 2013 a set of Governance Articles and Tips for SharePoint 2013 – this is brilliant, as this encapsulates the very essence of what I have been stating in reference to core SharePoint Service Delivery and Adoption. In this article you will find great resources about governance in SharePoint 2013. Learn about governing IT services, information management, and application management.
Check out this article for more insights
Anyway, onto the article!
Building Governance is through defining working practices and policies; done through working with business and technical interfacing teams, who develop SharePoint solutions that solve information challenges. And you do all of this through a Governance Committee made up of decision makers across the business. These people work with their teams to conduct research, analysis, and implementation of SharePoint.
SharePoint governance planning adds legitimacy to a SharePoint implementation. Defined governance rules, roles, and responsibilities in the Plan phase ensure the business is provided with the resources to make the SharePoint implementation a success. A SharePoint governance plan describes the business-critical nature of the SharePoint implementation and provides the evidence for requesting the necessary people and money investments.
Governance in SharePoint is crucial. Governance never works without business involvement. Your project team should not define governance procedures unless sanctioned by the business.
Before continuing to explain how to build SharePoint governance, I should point out that SharePoint governance can be made simple or complex. The bigger your SharePoint implementation and the more resources used, the more complex the governance plan should be. The Governance Committee should be formed at the start of the Plan phase of the project. The key reason for SharePoint governance is not to force users to do certain things on SharePoint. SharePoint governance provides communication and education. SharePoint governance provides a face to SharePoint and can be used to introduce the platform to the client, because the formation of the SharePoint Governance Committee embodies the vision (as described in the SharePoint Quality Plan) the client has of SharePoint.
The top priority of the Governance Committee (once formed) is the creation of the SharePoint Statement of Operations. That output is the face of SharePoint and is a continually updated document.
Governance and Culture
Successfully implemented SharePoint governance planning depends on the culture of the organization, because it needs to define the rules applied to the management of SharePoint and the rules applied to content when people work with the platform. For example, company ABC might allow any user to create sites on the SharePoint production platform, whereas company DFE might request that users make a help desk call to have a site created. Some people will say, “It’s better for users to create their own sites on SharePoint,” and I would not wholly disagree with that. However, if that type of access to SharePoint is left unchecked, there is no way to control the growth of the SharePoint platform. There are many other areas in SharePoint related to the use of data, where it is stored, and who has access to that data.
Here is a list of areas in SharePoint where, in my view, decisions about data or site management need to be reviewed:
- Can users access information via Web Folder clients? This is the ability to see or access SharePoint via a mapped URL back to your Microsoft Office client software. For example, company ABC might allow users to map a drive letter to a document library on a SharePoint site and to manage files through the use of Windows Explorer.
- Can users create and manage their own Web sites?
- Is distributed administration provided through technical staff only or through a combination of business and technical staff? The geographical distribution of the company might affect the level of support supplied if the SharePoint implementation follows the regional spread of the company. For example, if you are considering having one administrator responsible for a regionalized SharePoint installation, something is going to slip. How are records and documents described (how is metadata used) to ensure descriptions are consistent across departments, divisions, and agencies? Metadata is the description of physical content. The grouping of metadata is carried out by the information architect at a global level and then regionalized into site administrators at department, office, and group levels. Collation of this material is key to defining the aspects of search and to content scoping. Metadata is also a crucial aspect of Enterprise Content Management (ECM) and lends it itself to the categorization of functional site material.
Tip
For more information on Enterprise Content Management, you’ll find a lot of good articles at http://blogs.msdn.com/b/ecm/
- Should end users be trained on how to administer sites before they need to manage them? Do you need to train the trainers so that a cascade of training can be provided? Check the service delivery and the support model—for example, if your support model includes end users as the first line of SharePoint technical support and administration, your training plan must include that also.
- Who will assign users and permissions in SharePoint 2010?
- Who will create and approve content for sites?
- Who will secure sensitive information?
- Who will be able to create new sites?
- Who will be able to publish content to Web sites?
- Who will be able to customize sites?
What Does SharePoint Governance Look At?
SharePoint governance typically examines the following items:
- SharePoint 2010 farm structure and quality. What level of SharePoint topology has been defined: the connectivity, resilience, and performance levels?
- Web structure and content format. What kind of sites are being provided, where are they being provided, why are they being provided, who are the owners, what are the content levels, what is the taxonomy, and what metadata will be used?
- Subarea design. What kind of data flow, content control, and site structure will be used? Who is responsible for defining that?
- Conceptual design. What framework is in place to structure sites (for example, managed paths, logical separations at the site level, and so on)?
- User group management. Is there a user group for SharePoint or an IT user group that requires SharePoint input? Or should one be formed? What are the rules concerning its operation?
- Quality management
- Risk management
- Subcontract technical management
- Development and design cycles
- Configuration management, including documentation
- Verification of the portals
- Acceptance
Governance Is Not a New Form of Government!
The SharePoint Governance Plan will focus on what needs to be governed and controlled and who is part of what team. This is not a new form of government! It needs to be kept simple, understandable and focus on what really matters. The overall success of the SharePoint implementation hinges on maintaining control while being bombarded by requests from everybody in the organization. The governance plan facilitates management of SharePoint. SharePoint governance outlines the maintenance, administration, and support for the organization’s SharePoint environments, and it helps identify lines of ownership for both business and technical teams. To make the SharePoint Governance Plan understandable, you need to have a model that describes at a high level how the different site types of SharePoint fit together. You need this level of definition to address the different types of sites the organization will use.
Usage policies and procedures also need to be included that not only state inappropriate use but also provide a more consistent and usable system—for example, acceptable use, training strategy and SharePoint 2010 “Statement of Operations” guides.
The Model
The following figure shows a few of the site types that are included in a typical SharePoint implementation. Like all things hierarchical, there are a few high-level sites at the top; when you travel down the pyramid, the number of sites grows as you add divisional portals, team sites, project sites, and even MySites.
The important thing to note about this model is that the site and portals at the top consist mostly of published content and usually require tight governance. As you move down the pyramid, governance becomes looser and the purposes are more related to team collaboration than corporate communication.
Also, more temporary or short-lived sites exist on the lower half, and the permanent sites are more common as you move up the pyramid.
Sites on the lower half usually need to be provisioned quickly so that people can collaborate efficiently. The sites on the top are visible to many more people and require a bit more planning.
As part of the build of the Governance Plan, you should list the key hosts within the segments of the pyramid. This gives the governance team real data to associate with each of the relevant areas.
Who Governs
You need to assign appropriate individuals in the organization with defined responsibilities in the governance team. Individuals with the ability to make the necessary decisions—not just initially, but throughout the life of SharePoint—should be part of or connected to the governance team for SharePoint.
The best approach I’ve found for building a governance team is to start with the lead steward. This individual (or more than one) should be selected by the SharePoint client (with some consultation from you). Having the client pick the lead steward ensures that the lead steward will work hard and allocate the time needed; it also means that the steward has exposure to upper management and likely has some clout within the company.
The key part of this is the clout or recognition the lead steward has inside the company. You’ll need that lead steward to leverage that visibility to build the stewardship council.
Your lead steward is from the business side, has many connections within the business, has executive support, and likely has the leadership ability to put together the SharePoint Governance Committee. The path to follow, at a high level, can be summarized as follows:
- Identify the lines of business involved.
- Find a business leader from each line of business (LOB).
- Secure 5 percent of the time of these leaders for the Data Governance initiative. Use executive support as leverage if needed.
- Have one-on-one meetings with the business leaders (prior to any large meetings) to show the value of the program, and how you can help them!
- Have a kick-off meeting to get the initial buzz going.
To balance the SharePoint Governance Committee, the committee should be composed of business and technology individuals in the organization. By combining these, you get them to work together to define and enforce a SharePoint governance plan.. The Governance Committee is made up of two groups: the Strategy Team and the Tactical Team.
As the following figure shows, the Governance Committee brings the Strategy Team and Tactical Team together (Site Administration, Functional Owners, Portal Administration, Development Team and Operations Team—representatives of which collectively make up the Tactical Team). Although the Strategy Team will meet only on a quarterly basis after SharePoint has been implemented, the Governance Committee is an extension of the Tactical Team and meets regularly to make the necessary decisions to keep your SharePoint implementation moving.
The Governance Committee is concerned with requests for new high-level sites, requests for customization or configuration, oversight and scheduling of operational changes, and a whole lot more. This committee must have representation from all the areas of the Tactical Team (Site Administration, Data Owners, Portal Administration, Technical, and Developers), and also overlaps into the Strategy Team. This structure provides good representation and communication flow.
Strategy Team
A good Strategy Team includes a balance of business owners and technology leaders. This team has active involvement from the SharePoint client, executive and financial stakeholders, IT and business leaders, security and compliance officers, development leaders, and information workers.
This team is charged with finding the right balance between technology and the business, and between centralized control and decentralized empowerment. They drive the deployment from a strategic perspective and provide the overall insight and direction needed by the tactical teams. They are constantly looking for synergies where SharePoint can help the organization operate more effectively or efficiently.
They understand how the business is growing, and where it could be growing. In the end, their role is about leveraging SharePoint to improve on business processes.
Tactical Team
The Tactical Team, as its name suggests, is focused on operations, portal and site administration, functional ownership of specific sites, and building the framework and features of the portal. The tactical team builds the infrastructure (hardware, operating system, and so on), provide database support and network connectivity, provide security, and support all of SharePoint’s features. This team is also responsible for global SharePoint configuration, site provisioning, site administration, and SharePoint maintenance
—
That’s the section dealt with – for more, get the books: