It’s been over five years since I first heard of the words ‘portal governance’ and I remember being completely bewildered at its meaning or purpose. At the time, I was working (competing?) with a colleague to get our ‘portal’ businesses up and running. He was focused on IBM Portal and I was the SharePoint guy. I can still remember his excitement on landing a three-week project to build a governance plan for a new customer. That first envious conversation inspired me to dig deep into the world of governance and now a week doesn’t go by where I’m not applying or defining some important governance principles.

These days, governance is much more common and many of my clients have heard of governance and are doing their best to implement governance concepts. There are many great sites devoted to SharePoint Governance, from Microsoft TechNet to Joel Oleson’s Blog. Even with this plethora of information so readily available, I am surprised by the number of different connotations governance has amongst my SharePoint clients. Very simply, SharePoint Governance can be defined as a system of management to control the deployment and use of SharePoint in your organization. Those of us who have implemented SharePoint know the nature of SharePoint implementations is to rapidly proliferate throughout organizations. When SharePoint is fully deployed and takes hold, usage skyrockets and sites begin popping up everywhere. Without an appropriate plan for managing this growth, it can become out of control very quickly. Another way to look at it: Governance is like a good city plan of zoning and building codes that keeps your SharePoint implementation looking more like Chicago’s uniform grid of streets and less like the urban sprawl of San Antonio.

Governance is often confused with other aspects of a good SharePoint design: infrastructure design, branding, taxonomy and information architecture, just to name a few. Training and communication are also often mixed in with Governance. While, all of these things are very important, it’s my experience that a good, simple governance plan should be viewed independently from these other design or planning elements. SharePoint governance plans can and should touch on aspects of controlling things like branding, but governance itself should be raised up a notch and tackled on a broader level. For example, SharePoint provides the ability to apply themes to individual Sites. A governance plan can declare when this is appropriate, and when it is not, but a UI design should define the themes themselves.

At its core, a governance plan is a manual or guidebook that describes precisely how SharePoint administration, maintenance, and support should be handled to control the growth of SharePoint implementations. It draws the line of ownership between the technical folks putting together the system and the business groups who are using it. A governance plan defines the ‘building codes’ for how you should use SharePoint, and for how you can’t or shouldn’t. Because SharePoint introduces new ways of sharing information, collaborating, and implementing business processes, there are unique considerations for governing its use. For example, as SharePoint usage grows naturally, more and more people end up relying on the information in SharePoint to do their daily jobs, and SharePoint becomes more ‘business critical’. Some organizations are ready to accept SharePoint in this role—some are not. A governance plan will define the usage rules that will enable such growth, or specifically curb it until an organization can support it. A good governance plan, then, ensures SharePoint is managed and used in accordance with its designed intent to prevent it from becoming an unmanageable system.

To make this a bit more real, let’s review ‘what’ should be governed in a SharePoint implementation, ‘who’ should be doing the governing, and ‘why’ it is important to define this information up front:

What is governed?

To make our Governance Plan understandable, we need a model for how the different types of SharePoint fit together, so we can address the different types of sites and content we are concerned with. We also need to define the ‘building codes’ (usage policies and procedures) that will not only keep out inappropriate use but also will provide a more consistent and usable system in the end.

The model below shows how the number of sites in most SharePoint implementations, especially those related to Intranets, form somewhat of a pyramid. Like all things hierarchical, we have a few number of high-level sites at the top, and the number of sites grow as you add divisional portals, team sites, project sites, and even My Sites.

The important part of this model is to realize that the site and portals at the top are usually mostly pushing content and usually require tight governance. As you move down the model, 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. Sites on the lower half usually need to be provisioned quickly so people can collaborate efficiently. Those on the top are visible to many more people and require a bit more planning. So, the trick is finding the right place for the horizontal line that separates the controlled sites from the ad-hoc sites in your organization.

Who is the Governor?

With the appropriate individuals in your organization involved at the right level with well defined responsibilities, you’ll have the ability to make the necessary decisions not just initially but throughout the life of SharePoint at your company. This includes tech-savvy business people and business-savvy technology resources working together to define and enforce your plan.

The best governance plans I’ve seen break the roles and responsibilities into two groups: A Strategy Team, and a set of Tactical Teams. The Strategy Team should be a balance of business owners and technology leaders. In this team it is critical to have active involvement from Executive & 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 need to understand how the business is growing, and where it could be growing. In the end it’s about leveraging SharePoint to improve on business processes.

On the other hand, the Tactical Teams, as their name suggests, are focused on things like operations, portal and site administration, functional ownership of specific sites, and building the framework and features of the portal. The tactical teams build the infrastructure (hardware, OS, etc.), provide the relational database support and required connectivity, and support SharePoint’s Active Directory needs. These teams are also responsible for global SharePoint con
figuration, site provisioning, administration, and maintenance.

As the diagram on the right shows, the addition of a governance committee brings the Strategy Team and Tactical Teams together. While the Strategy team may only meet on a quarterly basis once SharePoint has been deployed, the governance committee is an extension of the tactical teams and meets regularly to make the necessary decisions to keep your SharePoint implementation moving. They are concerned with request for new high-level sites, requests for customizations or configurations, oversight and scheduling of operational changes, and a whole lot more. This committee has representation from all the tactical teams, and also overlaps into the strategy team providing good representation and communication flow.

Why is this so important?

A good governance plan adds a ton of legitimacy to your implementation and to your overall plan. Defining governance rules, roles, and responsibilities helps tremendously to get the business to provide the resources you need to make your implementation a success. A governance plan will describe the business-critical nature of your SharePoint implementation and provide the evidence for the necessary people and money investments.

Conclusion

A few final words of advice: Focus on developing a complete governance plan early in your implementation. Focus on WHAT needs to be governed and controlled and WHO is part of what team. Also, remember you are not John Adams or Benjamin Franklin. This is not a new form of government you are creating. Keep it simple and focus on what really matters to you. The overall success of your SharePoint implementation hinges on maintaining control while being bombarded by requests from everybody in your organization (and their brother), and your governance plan will give you that control.