Microsoft SharePoint 2010: Governance Planning

Article
08/31/2016

Establishing an effective governance structure takes research, planning, precise execution, and ongoing evaluation and maintenance.

Steve Wright and Corey Erkes

Adapted from “SharePoint Governance” (Apress, 2012)

So your organization has decided to deploy a SharePoint-based solution. You’re looking at hardware, software licenses, networking and all of the other technical details that go into deploying SharePoint. At this point, there are just as many non-technical issues you should consider, but they’re probably not at the forefront of your mind. Perhaps they seem obvious or appear to be someone else’s concern. These include:

Who is the executive sponsor for this project; or, in other words, who is paying for this?
What are you trying to accomplish?
How will you maintain the system once it’s in place?
How will you make sure the system provides the services the business needs? How will you be able to tell if it’s not providing value?

All these questions lead to the need for governance. Unfortunately, answering them won’t get the system up and running any faster, and failing to answer them won’t prevent delays. This is why so many sites are deployed without an established governance plan. It’s also why so many fail. In a way, the relatively inexpensive startup costs and easy setup of SharePoint contribute to this problem. No business would consider implementing a multimillion-dollar datacenter without a clear idea of what it would be used for and how it would be managed.

Ideally, the executive sponsor should be the person initiating the system’s governance. This is the person providing the funding for the project, who has the authority to control the requirements. The sponsor therefore has a vested interest in seeing that the system is well-managed and returns value to the company.

The IT manager is often tasked with creating the SharePoint environment by someone else in the business. In that case, they should immediately identify the executive sponsor and engage them in the governance effort. Without the sponsor’s involvement, effective governance will not be possible because it will lack sufficient authority.

The next task is to establish the site’s vision. This statement describes why you’re creating the site and what value you expect it to return to the organization. There are many references available for writing good vision statements and many ways to write them. Here are a few suggestions to keep in mind:

Write the statement as though the system already exists and has achieved all its goals.
The statement should be no longer than one or two sentences.
The vision should be general enough to cover the entire purpose of the system, but specific enough to guide later decisions regarding its implementation.
The statement should describe the portal’s role within the organization and the value it intends to provide.

The vision statement will be different for an intranet, extranet or Internet site. It will vary depending on the reach of the portal across departments, divisions or the entire company. The vision should reflect the most important features that will provide value to the company without dwelling on the obvious. A vision statement describes what the site aspires to achieve on behalf of the business.

In addition to the vision statement, this may be good time to consider creating a mission statement. The mission statement is similar to the vision statement in that it helps guide the decision-making process. The difference is that a mission statement describes what the system is going to do, whereas a vision statement outlines what it’s going to be. It may be appropriate to consider the mission statement right after establishing the governance team.

Once you’ve defined the vision and the mission, you need to understand the scope of the governance effort. This goes hand in hand with the scope of the system. For example, if the site will serve as the intranet for one division within the company, the governance effort will focus on the needs of that division. The scope lets you say what is and isn’t relevant to the project, and focus on what is most important.

Start Communicating

Communication between the governance team and the rest of the organization is essential. At this point, it’s a good idea to begin opening the lines of communication. Formal communication and education plans will come later, but just get the word out for now:

Ask for volunteers for the governance team.
Ask for proposed content and functional requirements.
Ask for any and all ideas that might add value to the portal of the governance effort.

Governance Leadership

Now that you understand what you’re trying to accomplish and what you’re not, you need to assemble a group to lead the governance effort. This is the governance committee. Don’t let the word committee get in the way. If your organization’s culture views committees as bad things, call it something else. Some common alternatives are steering committee, leadership team, center of excellence and so on. Whatever its name, this group will set the policies and standards that make the system work.

Consider the types of people that should make up the governance team. These include IT, business and management leaders. Specifically, you need to determine the system’s stakeholders. These are the people and departments with a vested interest in seeing the project succeed. In searching for the system’s stakeholders, consider these questions:

Who is funding the system?
Who is accountable for the system’s success or failure?
Who will be using the system?
Who will be impacted if the system doesn’t meet business needs?
Who will spend time implementing or maintaining the system?
Who will be responsible for defining the information architecture of the system?
Who will provide and consume the content on the system?

It’s unlikely that all stakeholders will be able to commit the time necessary to actively participate in the governance effort. Instead, each area should appoint one or more representatives. These representatives should have the experience and authority to make binding decisions for their respective groups.

These team members will become mentors for users and advocates for the system within their part of the organization. Be sure that anyone to be included in the governance team is committed to the effort in both time and interest.

They should also be rewarded and recognized for their contributions. Participating in this type of activity can be time consuming when done well. It’s important that this time be factored into their overall workload and career plan. Asking anyone to perform this type of work over and above their normal 40-hour-a-week job will inevitably turn this into a low priority.

Set the Objectives

Like any project, SharePoint portal governance needs a set of well-defined goals or objectives. As with vision statements, there are many ideas about how to set goals. One of the most common approaches is to use the S.M.A.R.T. approach:

Specific. Objectives should specify exactly what is to be accomplished.
Measurable. Objectives should be quantifiable and concrete so you can objectively judge progress, success and failure.
Attainable. Objectives should never be set in such a way that they can’t be fully achieved. Setting a goal that is hard to reach is good. Setting a goal that is out of reach is pointless.
Relevant. Objectives should always contribute to achieving the mission and vision of the project.
Time-bound. Objectives should come with an expiration date. An open-ended objective is of little use because it never has to actually be met.

When setting goals for a SharePoint portal project, try to remember why you’re undertaking the project. The objectives should move the organization closer to achieving the vision while providing a measuring stick for gauging that progress.

Objectives for portal governance often map to the value provided to the business. These may include things like reducing the total cost of ownership, or TCO, for the system and establishing organizational standards and policies. You can meet these objectives by defining and implementing services within the portal for business users.

Another consideration when establishing governance goals is creating a balance between flexibility and control. Good governance requires a balanced approach. Too little control can cause a lack of focus and a waste of time and resources. Too much control can stifle innovation and cause the system to fall into disuse. One of the objectives of the governance effort should be to effectively strike this balance.

Assign Roles and Responsibilities

One of the primary purposes of governance is to ensure that everyone involved understands what is expected of them. This process begins by establishing the roles of each person or department and assigning responsibilities to those roles. Here are some common governance roles and the associated responsibilities:

Executive Sponsor. This project “champion” is usually associated with the part of the business providing the resources for the project.

Project Manager. This person drives the project forward and is often in charge of facilitating meetings, ensuring deadlines are met and communicating with the organization on behalf of the team.

Business Owner. This is usually a manager or senior staff member from one of the business units using the system. Business owners help establish system requirements and provide a channel for user feedback.

User Mentor (Coach). The mentor or coach is committed to helping users get the most out of the system and may perform formal or informal training, write blog posts, answer questions and do other forms of mentoring as needed.

Power User. This person is proficient with new content design and implementation within the portal and may or may not be technical, depending on the type of content they help author.

IT Manager. IT managers provide direction to administrators and developers associated with the system.

Application Developer. Application developers create customized functionality. This may include new Web parts, workflows, InfoPath forms and so on. Developers perform highly technical customizations beyond the scope of power users.

System Administrator. System administrators install, monitor and update the servers associated with the portal.

Support. Support resources are available to answer questions and solve problems when they are reported by end users.

Information Architect. This person helps the business owners define metadata, workflows, site structures and other components that control the information organization.

Web Designer. This person helps establish the look and feel of the site in conjunction with the information architect, and also helps developers and power users implement site design.

Site Owner. Each SharePoint site has one or more owners who control access to the site.

Site Designer. The site designer controls lists, libraries and other content within the site. Often, the site owner and site designer are the same person.

Site Contributor. A site contributor adds new or updated content to the site.

Defining responsibilities for the preceding roles may be as simple as creating a list and assigning the responsibilities for each role. While one role may be responsible for a task, other roles are often also involved. There are numerous variations on the definitions of these terms, but the general idea is the same.

As your governance effort begins, the list of tasks will be fairly short. As your system grows and issues arise, the list can be expanded as needed to ensure that everyone is comfortable with the roles of all involved.

Steve Wright

Steve Wright is a senior manager in business intelligence management for Sogeti USA in Omaha, Neb. Over the last 20-plus years, Wright has worked on air traffic control, financial, insurance and a multitude of other types of systems. He has authored and performed technical reviews for many previous titles covering Microsoft products including Windows, SharePoint, SQL Server and BizTalk.

Corey Erkes is a manager consultant for Sogeti USA in Omaha, Neb. Erkes has worked with a wide range of companies at different points in the lifecycles of their SharePoint implementations. He is also one of the founding members of the Omaha SharePoint Users Group.