The Five Pillars of SharePoint Governancefiles.meetup.com/3361232/WPA FivePillars SharePointG… · · 2012-10-11The Five Pillars of SharePoint Governance ... Practice What You

The Five Pillars of SharePoint Governance

Written By Chris McNultySharePoint Strategic Product ManagerQuest Software, Inc.

WHITE PAPER The Five Pillars of SharePoint Governance

1

Contents

Abstract .......................................................................................................................................................................... 3

The Governance Challenge Today .............................................................................................................................. 4

What is SharePoint Governance? ................................................................................................................................ 5

A Definition .................................................................................................................................................................. 5

“Governance Documents” ........................................................................................................................................... 5

Industry Frameworks ................................................................................................................................................... 5

A Tale of Two SharePoints .......................................................................................................................................... 5

One-Co: Focused on Guidance ............................................................................................................................... 6

Two-Co: Focused on Control ................................................................................................................................... 6

Comparing the Two Guidance Frameworks ............................................................................................................. 6

Understanding Resistance to “Governance” ............................................................................................................... 7

How Much Governance is Needed .............................................................................................................................. 7

The Governance Pyramid ........................................................................................................................................ 7

A Formula ................................................................................................................................................................. 8

Key Factors .............................................................................................................................................................. 8

The Five Pillars of SharePoint Governance ................................................................................................................ 9

An Analogy: Shopping Mall Governance .................................................................................................................... 9

The Five Pillars of SharePoint Governance ................................................................................................................ 9

Security .................................................................................................................................................................. 10

Auditing .................................................................................................................................................................. 12

Reliability ................................................................................................................................................................ 12

Usability .................................................................................................................................................................. 13

Supportability ......................................................................................................................................................... 15

Operations and Management ..................................................................................................................................... 16

Maturity Levels ............................................................................................................................................................ 17


2

Governance is a Program, not a Document .............................................................................................................. 17

A SharePoint Maturity Model ..................................................................................................................................... 17

A SharePoint Governance Maturity Model ................................................................................................................ 17

Moving Up the Governance Maturity Scale ............................................................................................................... 18

Establishing and Sustaining a SharePoint Governance Program .......................................................................... 19

Core Governance Processes .................................................................................................................................... 19

Establish Stakeholders ........................................................................................................................................... 19

Gather Requirements ............................................................................................................................................. 20

Develop Governance Framework .......................................................................................................................... 20

Implement Governed Operations ........................................................................................................................... 20

Measure Results .................................................................................................................................................... 20

Evaluate Success for Next Steps ........................................................................................................................... 20

Questions that May Arise .......................................................................................................................................... 21

Key Elements of a Governance Plan ......................................................................................................................... 21

A Tip: Practice What You Preach .............................................................................................................................. 22

Conclusion ................................................................................................................................................................... 23


3

Abstract Governance means something different for each organization; it even means different things for people within an organization. Implementing a governance plan can be just as messy as defining one. In this paper, we’ll review why governance matters, explore how to define it, and offer a framework for shaping and establishing your SharePoint governance program.


4

The Governance Challenge Today Governance is the hottest buzzword for enterprise SharePoint systems today. Everywhere you turn, consultants, authors and analysts offer prescriptions for governance best practices. And, as you might expect, there’s a lot of debate about what constitutes effective governance.

Why does SharePoint governance matter, and why is it a challenge? SharePoint governance is important primarily because the platform is so popular and so important to the enterprise.

When properly designed, with clear information architecture and streamlined page designs, SharePoint is easy to use. Therefore, SharePoint is often adopted quickly by users and grows quickly. But its newer elements, such as social networking and keyword tagging, generate the most interest, and are highly user intensive. As you might expect, these are the areas with the least enterprise usage history, and probably the greatest need to establish rules to sustain adoption.

Unfortunately, however, SharePoint growth is seldom planned and controlled; rather, SharePoint tends to take off like a flock of startled birds, with an explosion of sites, application and content, taking off in all directions with no discernible common direction or purpose. The resulting unmanaged chaos is a bane to both user productivity and sustained usage. Without standards within and across sites, site developers waste time reinventing controls and displays that could be re-used across sites, and users waste time due to poor architecture, and base decisions on “wrong” version of documents. The resulting frustration can impede broader SharePoint adoption; in fact, in a recent Forrester report, 41% of those surveyed cited lack of governance as a key impediment to adoption, second only to technical complexity.1

Note that governance and adoption is not a “chicken-and-egg” problem, where it doesn’t matter which comes first. It’s true that adoption furthers the need for governance. But without governance, it’s hard to get the adoption you need in the first place. So in the most successful SharePoint projects, governance isn’t a luxury tax imposed after the fact – it’s an essential, ongoing program from day one.

In addition to hurting user productivity and adoption, lack of governance also can open the door to legal or compli-ance exposure. Documents may be deleted or retained with no clear conformance to established retention timelines. User activity may open up even broader ranges of messages and communication to subpoena, or create potential liabilities when there are no frameworks for “proper” use.

1 SharePoint Adoption: Content And Collaboration Is Just The Start. Forrester Research, Inc., September 2011.


5

What is SharePoint Governance? A Definition SharePoint governance is important. But exactly what is SharePoint governance? Microsoft provides a succinct definition on TechNet:

“Governance is the set of policies, roles, responsibilities, and processes that guide, direct, and control how an organization's business divisions and IT teams cooperate to achieve business goals.”2 (emphasis added)

But what does this mean in practical terms? How do you go about defining these policies, roles, responsibilities and processes, and in implementing and sustaining a governance program?

“Governance Documents” I’ve seen more than a few organizations describe their SharePoint governance as detailed and sophisticated. When asked, they commonly pull out a lengthy Microsoft Word document that details every aspect of their technical infrastructure – database names, service accounts, web applications, and web.config customization – as it existed when the environment was built a year earlier. Often, this file is described as the “governance document.” But, as we will see, this is not a good model for effective SharePoint governance.

Industry Frameworks Governance as a whole is reflected in many standard IT management frameworks, such as the following:

• ITIL – Information Technology Infrastructure Library (http://www.itil-officialsite.com/home/home.aspx )

• COBIT – Control OBjectives for Information and related Technology (http://www.isaca.org/Knowledge-Center/COBIT/Pages/Overview.aspx)

• CMMI – Capability Maturity Model Integration (http://www.sei.cmu.edu/cmmi/)

• MOF – Microsoft Operation Framework (http://technet.microsoft.com/en-us/library/cc506049.aspx)

These frameworks can be a useful primer if your organization has no enterprise technology governance.

A Tale of Two SharePoints Although each organization’s governance plan will be unique, the basic principles should be recognizable across most SharePoint enterprises. It may help to consider the experiences at two similar U.S. multinationals I’ve had the pleasure to work with over the years.

2 http://technet.microsoft.com/en-us/library/cc263356.aspx. For additional SharePoint governance material, see http://technet.microsoft.com/en-us/sharepoint/ff800826.aspx.

http://www.isaca.org/Knowledge- Center/COBIT/Pages/Overview.aspx

http://www.isaca.org/Knowledge- Center/COBIT/Pages/Overview.aspx


6

One-Co: Focused on Guidance

One large financial services organization (let’s call it “OneCo”) implemented SharePoint 2003 as its enterprise intranet and document collaboration solution. Some of the hallmarks of OneCo’s plan for “running” SharePoint included:

• Enterprise-level global steering committees • Business sponsors engaged as project sponsors • Simple reproducible training offerings for site owners • Predictable service levels and SLAs for uptime, recovery and incident resolution • Clear self-service process for requesting new sites, with documented timelines and expectations for produc-

tion and test usage • A clearly defined cost chargeback model that encouraged migration and customization • Documented change control procedures for reviewing, communicating and applying significant modification

to production environments • Alignment with other enterprise systems for help desk support and incident/problem management

Two-Co: Focused on Control

For OneCo, this was a good start at an acceptable governance framework. But this framework was woefully inade-quate at another similar financial services firm (“TwoCo”), because the two firms could not have been more different in their use of SharePoint. Hallmarks of TwoCo’s governance plan included:

• Mandatory requirements for required training and certifications before site creation requests would be processed

• SLAs for how many months lead time were required for site creation • Strict policies about what was forbidden in team sites (e.g., versioning, blogs, wikis)

Comparing the Two Guidance Frameworks

When representatives of these two firms met, their governance discussion was fascinating. OneCo expressed almost its entire governance plan in terms of guidance; TwoCo was focused on control. They had almost no common stories to share. Questions from OneCo included:

• How do we get even more people to use SharePoint? • What other business processes can we automate in SharePoint?

And questions from TwoCo included:

• Why isn’t more of your governance plan documented? • Should there be a formal user certification and training plan? • And (my favorite) what else should we turn off in SharePoint so we don’t get in trouble?

Understandably, each of these firms faced different challenges as their SharePoint environments matured. It’s very simple to suggest that OneCo had it “right,” but that’s an oversimplification. In time, their concerns shifted to manag-ing performance and capacity as the environment grew rapidly. In addition, the loosely enforced guidelines around non-production systems led to more than a few recovery requests for critical documents that were accidentally deleted from “test” systems. Some policies were clearly defined, but others were only documented as part of kickoff presentations, or not at all.


7

TwoCo faced challenges from their business users about speed-to-market for getting new sites – but almost no complaints about system performance or uptime. And every policy they had was clearly documented. Finally, governance was established upfront, rather than as a response to rampant, undisciplined usage.

Understanding Resistance to “Governance” Governance sometimes gets a bad reputation in SharePoint. There are a few reasons. One is the word itself: although its meaning is loosely shared among practitioners, it can be confusing or alienating for folks who don’t work with it on a regular basis. In some organizations, the word itself scares off business users, so they don’t stay engaged in a governance program.

A second issue is the “bad cop” scenario. In this, governance is seen exclusively as a controlling force, reining in users who are just trying to do their jobs. This is a narrow interpretation of governance, and can reflect a damaged technical culture that needs to nurture its trusted relationships. In these situations, users try to see how much they can get going before someone stops them, or they get resigned to being shut down eventually, so they never even start using the system.

A final challenge is balancing technical and business needs. It’s become de rigueur to talk about governance for technical issues: web sites, messaging and social solutions. In addition, economic and regulatory factors, such as options pricing, Sarbanes-Oxley, and the recent global recession, have led to extensive discussion about reforming corporate management and boards of directors. But all too often, important business needs are not clearly defined; for example, who determines business criticality? Often, the right questions aren’t being asked, or they’re being posed to the wrong people, or the questions aren’t understood as they are phrased. IT organizations are often left to guess or infer business needs, which of course does not help the organization achieve effective governance.

How Much Governance is Needed Having the right amount of governance is a delicate balance between usage and control, and between business and technical needs. Governing the wrong behaviors or assigning the wrong “weight” to needs (too much OR too little) creates real setbacks.

The Governance Pyramid

In many publications you can find a “Governance Pyramid” like the following:


8

This pyramid expresses a simple concept: the most prominent and trafficked portions of your SharePoint world usually require the most governance. Single-user SharePoint systems are unlikely to need much in the way of governance; user guidance, control and direction are pretty simple when you have only one person to cover. (But even though single-user sites need less governance, don’t assume they need none at all.)

A Formula

We could also express the amount of required governance as an arbitrary formula for G:

! =

!100 ∗max (log ! , 1)

100 ∗ !!

Where:

• C is the volume of content expressed in GB. • U is the number of users in the environment. • td is the % of tolerable unscheduled system downtime.

Again, it’s an arbitrary formula. I’m not really advocating that we calculate a value in “govs” of how much governance is appropriate for a given SharePoint environment. But it does tell us that an 8000-user environment with 600 GB of content and a high degree of business criticality (99.99% uptime) with a G score of 956.1 probably requires more care in its governance than a 40-user environment with 30 GB of data and a 99.9% uptime requirement [G score of 8.7].

Key Factors

It’s overly quantitative to calculate this value for all environments. And if you’re not a math whiz, we advocate the consideration of several factors in determining how much governance is appropriate:

• Environmental size and complexity • Usage • Business criticality

The key point to remember is that larger sites with more users and business impact need more attention than smaller ones.


9

The Five Pillars of SharePoint Governance An Analogy: Shopping Mall Governance Supreme Court Justice Potter Stewart famously remarked in the 1960s of a particularly hard-to-define legal concept, “I know it when I see it.” So let’s consider an example of a highly adopted, well governed community-oriented endeavor as a loose analogy to SharePoint governance. Ladies and gentlemen, I give you the American shopping mall experience.

Americans have strongly “adopted” the shopping mall. The Roosevelt Field Mall in Garden City, New York, for instance, covers over two million square feet, and more than 20 million people shop there annually. Why are malls like this so highly used? Believe it or not, governance is a critical factor. Without governance, few would dare set foot in the mall. There would be no guidance about how to enter the building. Suppliers and merchants would be fearful about letting unsold merchandise remain on premises after hours. Even the food court might descend into a chaotic hellscape of health risks, dirty tables and stolen seats.

At first blush, it may not seem that a shopping mall has “governance.” There’s no steering committee and no shopper training. However, the mall is governed by a blend of laws, rules, regulations and social conventions. Some of these concern daily operations like cleaning, signage and transaction security. Some are training-oriented, like new hire orientation. And some are more long-range, like the local ordinances and lease contracts for adding a wing to the mall. Here are just some of the “rules” that malls follow:

• Rules are posted and enforced by staff on the premises. • Hours of operation are clearly posted. • Unsold merchandise is stored safely and securely in places where visitors lack access. • Stores are able to generate reports on daily sales and credit transactions as needed. • Heat, light, plumbing and sanitation utilities are almost continuously available. • Central customer service desks and multiple maps provide guidance to shoppers, as do staff on sales

floors. • New hires are given training by the mall as well as by their own stores. • The design and location of the mall makes it as simple as possible to arrive, park, browse and find

products and services for purchase. This happens with little explicit guidance; it runs by social conven-tions, signage and learned behaviors.

The Five Pillars of SharePoint Governance These elements fit into to what we call the Five Pillars of SharePoint Governance:

1. Security – The policies and procedures to protect your SharePoint from security incidents 2. Auditing – The policies and procedures to track user, content and configuration compliance 3. Reliability –The policies and procedures to prevent end user productivity interruptions in SharePoint 4. Usability – The policies and procedures to maintain SharePoint’s usability 5. Supportability – The policies and procedures to fix what goes wrong in SharePoint

Let’s draw a few analogies between browsing for sweaters in a shopping mall and browsing the intranet.


10

Pillar Mall Example SharePoint example

Security Unsold goods are locked up overnight. Users are kept out of privileged sites without authorization.

Auditing Secure credit card transaction histories are available.

Reports on content changes by a particular user are available.

Reliability Open 10am-10pm 364 days a year. High (>99.9%) availability.

Usability You can find the perfect sweater. You can find the perfect PowerPoint doc.

Supportability Frequent “You are Here” signs are posted on public mall maps.

Links to video how-to library are consistent across SharePoint.

Analogies are helpful introductions. But let’s look more deeply at each of the five major elements of SharePoint governance.

Security

What is Security Security is the most common reason that organizations come to understand their need for governance. Since the release of granular permissions in SharePoint 2007, the platform has allowed finely calibrated permissions to be applied to individual documents and items, as well as to web pages and whole sites. Over the years, SharePoint has also added a growing range of complex authentication schemes, moving beyond Active Directory and LDAP to flexible, multi-mode claims based authentication. As a result, it’s easy to arrive at a security scheme that’s dizzyingly complex, with highly individualized permissions. How can we navigate this environment?

Key Questions to Ask The most important determination about security governance is a policy decision: What should users be allowed to do or see in SharePoint, and what should be restricted? Similarly, how do those policies get applied, modified and monitored? The core elements for security governance are:

• User and administrative authorization • Content permissions • System-level security

Understanding and working in line with the rest of your enterprise technical culture is essential. For example, your company may have multiple projects running simultaneously internally. It’s fairly common for each project to get its own SharePoint site. Outside the immediate project team, who should have access to the site, and how do they get it? This is an essential governance challenge, and requires the consideration of the following questions, at least:

• Should people outside a project have access to each project’s team site? Do they even care? • What information on a given project can be kept open, and what information needs to be protected? • If a project can be restricted, who should determine which users get access – the project manager, the

project sponsor, IT, the users’ manager? • What’s the process for requesting permissions?


11

• It’s hard to determine the right responses to these questions without evaluating current levels of system security. For example, what can any random member of the “Domain Users” group see in a given site?

Understanding the relative openness of information security is important. In some cases, existing practices may be misaligned, and SharePoint is positioned as the opportunity to fix long-standing poor security on legacy file shares, public folders and other collaborative stores.

Achieving a Balance in Restricting Access I can’t stress enough how important it is to get the security balance right. It’s important to consider the different ways that people discover content in SharePoint – search, social newsfeed, forwarded bookmarks – in addition to tradition-al browsing. As a result, “security by obscurity” is no longer effective. Many of us have heard horror stories about companies who “accidentally” shared employee annual reviews with the whole company, or posted client information on a public web site. For example, a government agency accidentally posted 20 years of personal information on over 200,000 individuals in 2010 by storing them on a server exposed to the public.3

On the other hand, a security model that’s too restrictive can lead to problems with being unable to find desired information when needed, which can hamper SharePoint adoption. Users can also feel “hemmed in” by “not being able to do anything” in SharePoint. But keep in mind that even organizations that describe themselves as “open” can benefit from the inherent guidance provided by reasonable levels of security. If all sites and content are wide open, user navigation and searches can lead to overwhelming results and navigational complexity. Likewise, if users can post content anywhere in SharePoint, they will eventually post everything everywhere.

Operational Issues Once the governance framework has determined the right policies and procedures for system security, it falls to operational tools to help figure out where content is overexposed or underexposed; and how an “overprivileged” user got those permissions.

Even when the security balance is “right,” it’s meaningless without communication. All stakeholders, including users, need to understand not only what security is in place, but how to request, approve and implement changes. Likewise, when changes are needed – for example, removing “extra people” from a Site Owners group – those changes require communication.

Integrating with System Software Security governance often takes for granted the baseline security of system software: Windows, SQL and Share-Point. Microsoft constantly provides security updates and patches, and governance needs to work cooperatively to allow for efficient delivery of these updates. The need for enterprise change control, even in regulated or restricted environments, must be balanced against the need to defend the base system of attacks and exploits. One enterprise was unable to deploy any system updates in more than two years because security patches weren’t explicitly permitted under their overall IT governance without hundreds of person-hours in testing and documentation. Another gap is found in complex environments. Manual checks for patch levels on large server farms can be easily over-looked by overtaxed system administrators without proper automation and monitoring.

3 “Mesa County weighs damage from security breach of sheriff's files.” Denver Post, 4 December 2010. http://www.denverpost.com/news/ci_16779791.


12

Auditing

What is Auditing? Transparency is a powerful aid to governance, and auditing is the key to transparency. It’s often thought of as an adjunct to security, but proper auditing and reporting covers far more than security; site actions and system opera-tions are equally important.

For SharePoint, auditing provides clarity around:

• Content access and activities • User actions, system activities and performance • Who, what, when, why and how the environment changes, or is changed, over time

Most of the other pillars cover governance implementation and operations that are steered by governance. However, auditing is intrinsically part of governance. Activities needed to be measured – through auditing – if they’re going to be guided or controlled. For example, you may implement the fairly obvious governance policy that users shouldn’t store multiple copies of documents in SharePoint. But it’s really hard to automatically prevent users from uploading the same document to multiple site collections, which can lead to a related policy about eliminating or restricting the use of My Sites. Using management tools to see where duplicate files are being created can channel your policies in the right direction. Perhaps duplicate files are not the issue if you still see runaway content growth in My Sites; maybe it’s due to versioning or nonstandard file types.

For highly regulated environments, auditing is absolutely essential. Audit records may be required as part of litigation or to comply with regulatory systems such as SAS70, Sarbanes-Oxley or HIPAA. In addition to looking at content changes, the SharePoint-oriented enterprise will need to audit system changes, configuration and deployment to assure that all changes are made appropriately and by authorized staff, and that unapproved changes and unauthor-ized staff do not have impact on production systems.

I’ll expand later on the need to implement governance as a program, not as a one-time document. One of the key attributes of a program is frequent evaluation of standards and policy adherence by stakeholders. Having a simple, fast way to deliver focused reports is essential to motivating and sustaining business engagement as part of your program.

Reliability

What is Reliability? System availability and performance are essential when positioning SharePoint as a highly available enterprise class application platform. Reliability should be seen as a goal shared across systems design, SharePoint operation and governance policy. It accelerates user confidence.

At its core, “reliability” means:

• Preventing or avoiding incidents of degraded or unavailable SharePoint services • Ensuring system resilience for rapid recovery with minimal data loss in line with business needs and re-

sources (usually economic) • Assuring that established practices for system actions are observed


13

Testing and Deploying Changes Early in its lifecycle, SharePoint may be a stand-alone, wide-open environment. But under governance, enterprises usually articulate a goal that all changes be tested and then approved before deployment. In these more mature environments, organizations usually deploy independent SharePoint systems for development, testing and produc-tion. Isolated environments protect production regions from untested changes and code.

However, in the SharePoint world, multiple test regions can pose operational challenges. In SharePoint, many elements that might be consider “code” on other platforms, such as data structures, forms and workflow, live as part of the content database. Moving those changes into production isn’t as simple as copying the database, since it would overwrite the current production content.

Operational Challenges Running this kind of environment presents operational challenges too – how to compare different systems and synchronize changes among them, for example. Approving and releasing updates in a standardized, repeatable manner is important to make sure that things work identically between testing and production. Many organizations take what’s called the “swivel seat” approach to SharePoint deployment. An engineer performs extensive manual configuration of lists, content types, forms, workflows, libraries, web parts, etc., in a test system – and then swivels his or her chair around and manually duplicates the same constructions in the live SharePoint farm. Too often, this leads to pilot error, or to a system whose operation depends on undocumented configuration steps known only to the developer who installed the solution. An automated approach to approving, packaging and deploying changes eliminates most opportunities for error.

Federation of Roles and Responsibilities Highly mature governance usually entails federation of roles and responsibilities. One of the most common principles is the developers shouldn’t have administrative access to production, and that releases should be installed by release engineers. Similarly, end users need to be kept away from development systems to remove the option of “provelop-ment” – running production from development systems. Auditing helps discover variances in intended permissions; security tools help administer these permissions. In the end, these policies and procedures enhance SharePoint reliability.

Usability

What is Usability? At the November 2011 Gilbane Conference in Boston, Massachusetts, one speaker on SharePoint adoption asked why we were talking about adoption when we should really focus on user satisfaction. “Adoption” can happen solely by forcing browsers to launch the SharePoint home page. But really meeting and exceeding user needs are the heart of the SharePoint mission.

Usability encompasses a broad set of mission statements for SharePoint. Among these are:

• The system performs sufficiently to achieve business goals. • Users are able to use that performance to meet their needs. • Essential information from other systems is consolidated and available on the SharePoint platform.

System performance and interface responsiveness, in addition to reliability, have a significant impact on user’s perceived ease of use. Governance, using Microsoft’s definition, fosters cooperation to achieve business goals.


14

Site Development and Customization One key to ensuring usability is asking these questions: Who should be allowed to customize SharePoint, and what sort of responsibilities and skills will they need? Sometimes it’s appropriate to allow users greater power to customize their sites. But SharePoint development can have a steep learning curve, given the complexity of the platform and the interface, along with ASP.NET, jQuery, SQL and the rest. Therefore, sharing development “power” more broadly carries with it the responsibly to flatten that learning curve and accelerate time-to-market. Using tools and templates can help users improve their sites, while freeing up SharePoint developers to work on solutions that are truly unique and honed to particular business needs.

Information Architecture The fitness of a SharePoint site is also embodied in its information architecture. Structures that map more naturally to shared understandings of common logical grouping are more intuitively navigated. Similarly, just as shopping malls offer maps and guidance, SharePoint needs to provide navigation and interface frameworks that are shared across multiple sites so that user patterns adopted on one site easily transition to multiple user destinations.

Information architecture needs to be an adjunct to usability. Technical limitations or bad user habits can accidentally reduce the usability of the site. For example, without any archiving or information lifecycle management, obsolete content remains in the same place as live information, obfuscating information readily sought by users. Similarly, poor storage management can lead to arbitrary archives or imposed hierarchies and make critical information harder to find. Governance needs to lead technology here, advocating for techniques like common taxonomies and flexible metadata usage.

Incorporating Legacy Information Information architecture is fantastic. But you need information inside that architecture. Even with all the new functions that have grown into SharePoint, almost all enterprises make heavy use of document-oriented content management. Many governance plans aspire to have “one version of the truth.” To achieve this, it’s important to get information into the architecture correctly and properly, swiftly transforming it from legacy sources to well-designed, properly classified SharePoint libraries. Leaving legacy document stores intact and relying on users to perform their own ad hoc migrations as they work with documents only increases the likelihood that the documents are never found or that when they are found, they are the wrong version.

Usage Patterns and Conventions SharePoint governance must define and model acceptable usage patterns for all system stakeholders. What’s acceptable is driven by business goals and norms, and should reflect the overall operating culture. For example, if it’s acceptable for users to add personal details as part of an instant message status (“off to dinner with my cousin”), the same guidance should extend to social microblogs. More directly, conventions about file naming and versioning need to be explained.

User Training A system may be properly customized, well architected, and content rich. But people still need to know how to use SharePoint. Policies and procedures, once defined, need to be acculturated. Technical education takes many forms. Train-the-trainer, formal classes, online videos, phone and IM based questions, FAQs are all part of the toolset. One area that demands further attention is launch and kickoff activities. At Microsoft’s SharePoint Conference in Novem-ber 2011, Jeff Teper, Corporate Vice President, Office Business Platform at Microsoft, shared numerous user stories in the keynote about how “I didn’t know you could do that in SharePoint.” Sometimes, that’s because no one ever showed the users how to do a given task. During SharePoint rollouts and kickoffs, you may find an eager audience at


15

peak willingness to be shown the way. SharePoint, like many Microsoft products, offers multiple paths to do things such as saving documents or sending links from email. It becomes the responsibility of all stakeholders to understand the range of possible approaches and provide clarity by steering users practices that will be right in each particular business and operational context.

Understanding SharePoint’s Limitations Finally, although SharePoint can do many things well, it doesn’t do all things equally well in all contexts. For example, SharePoint provides simple contact lists, which can be linked to documents, calendars, and tasks to comprise a basic contact management system. There may be a business goal of tracking all of a firm’s contacts. In some firms, SharePoint’s functionality exceeds those of comparable systems (Excel, Outlook, Access), and governance may establish SharePoint as the preferred or exclusive primary record about external contacts. However, in other firms, especially those with enterprise CRM/xRM suites such as SalesForce.com, Microsoft Dynamics CRM, or Siebel, good governance may entail discouraging use of SharePoint as a contact management system.

Supportability

What is Supportability? Supportability is a close partner to usability. It reduces the time lost to ambiguous or degraded access. At its core, it’s about resilience and response to incidents. Supportability doesn’t exist in a vacuum, either. But it begins from governance. As result, a properly governed SharePoint system provides:

• Rapid recovery from unavailable systems or deleted data • Clear guidance about what is supported and who support is provided • Accurate information about system and site configuration to guide incident response staff

Documentation and Reports Current, highly available documentation about system configurations, changes, and known solutions helps ensure consistent responses when things go wrong. Having to rely on personal memory or “hero” contributors is unsustaina-ble over time. Even out of the box, SharePoint supplies tools to enable user self-support (search, FAQs); shared support (forums); and formal support (task/ issue lists or links to more formal service ticket systems.)

Operational reports are a powerful force multiplier. For example, search logs can help us understand common user questions and make sure our automated and self-service support options contain the most relevant answers. Similarly, automated ways to review current configurations and most recent changes are essential to solving more complex support issues and escalations.

Disaster Recovery and Everyday Recovery One obvious area for support is disaster recovery. “Don’t have a disaster” isn’t a realistic plan. SharePoint solutions can be engineered to be highly available, but this can entail higher costs. Accelerating recovery time while minimizing potential data loss is essential. Leveraging regularized enterprise backup becomes the essential operational adjunct to this governance facet.

That’s great for big disasters. But is IT responsible for personal disasters – accidental deletions, saving the wrong version of a file, etc.? This sort of policy is often a second-wave part of a governance program. Procedures and tools for recovery – or self-service recovery – can all be designed once the plan is agreed.


16

Operations and Management Governance is distinct from, and yet bound to, both adoption and operations. Technically speaking, a SharePoint site can operate and be managed, regardless of governance or adoption. But in practice, governance establishes a rationale and a framework of policies and procedures that empowers both operational management and usage.

Many of the same tools and techniques used as part of sound operation are echoed in governance. But governance and operations are not the same thing. If we reflect back on our earlier definition, governance is expressed as cooperative roles, policies and procedures to achieve business goals. Although, ultimately, all IT operations exist to serve business goals, there are other aspects of SharePoint operations that most immediately serve technical needs. Looking at the five pillars, we can see a blend of these business and technical goals. For instance, auditing exists predominantly to support business processes and decision making. The reliability pillar, on the other hand, supports immediate technical objectives to further the business policies that guide the SharePoint platform. It’s an oversimplifi-cation, but probably a useful one, to think of governance as focused on business goals, whereas operations as stressing technical criteria.


17

Maturity Levels Governance is a Program, not a Document Governance doesn’t mean “backing up the SharePoint farm.” Governance begins with awareness that users need deleted file recovery, leading to a policy decision that may be based on cost analysis, audit report and logs. Once the policy determines that there needs to be operational support for single-file recovery, good governance also creates the procedure for requesting recoveries and user education about the process. Over time, a governance program will evaluate how well the process works and determine if and when self-service recovery is needed, for example. That’s an essential dimension to governance – it’s a program, not a document.

A SharePoint Maturity Model Sadie van Buren, an author and community leader, has published an extensive and well-received SharePoint maturity model at www.spmaturity.com. The van Buren model considers multiple aspects of SharePoint maturity, such as collaboration, search, infrastructure, publication and staffing. Each of these is mapped to a CMMI-derived, five-stage model:

• 100 – Initial • 200 – Managed • 300 – Defined • 400 – Predictable • 500 – Optimizing

A SharePoint Governance Maturity Model In the van Buren model, governance surfaces explicitly only at the 300 and 400 levels. Therefore, I’d like to propose a complementary five-stage maturity model for assessing SharePoint governance maturity:

• 100 – Initial: No governance at all. • 200 – Managed: Ad hoc training available, usage rules and guidance are similarly variable. Business

needs are presumed by technical stakeholders who act as sole governors of usage, on behalf of enter-prise business units.

• 300 – Defined: Business goals are clear. Policies, roles, guidance and procedures are documented but not uniformly shared or used. Governance stakeholders are known but meet and communicate irregu-larly.

• 400 – Predictable: Business goals are commonly known and documented. Stakeholders meet and/or communicate regularly. Governance standards are well shared, reviewed, followed, and in some cases enforced. Governance success is measured by repeatable quantitative and qualitative criteria.

• 500 – Optimizing: Governance standards exist and are reviewed and adjusted over time; there is intel-ligent automation of governance practices like security request and site retirement. Governance becomes self-sustaining. The principal goal of the governance stakeholders is to review results, resolve exceptions, and implement new tools and techniques for SharePoint governance.


18

Moving Up the Governance Maturity Scale Be realistic in your assessment about current governance maturity levels in your organization. Leaping from 200 to 500 is seldom accomplished in a short time. Progress, not perfection! It’s better to move up one level in six or twelve months successfully than it is to allow overaggressive maturity plans to fail.

You don’t need to govern everything. Selecting the right elements makes it easier to sustain stakeholder enthusiasm. Expressing governance through tangible elements in terms that all users understand is vital. At Quest Software, our internal enterprise usage of SharePoint had the challenges you might expect in a 3600-person, global organization. Here is how our governance strategy was established t:

“The key for our governance strategy was to focus on the things that we could enforce through the system: dials, configurations, permission settings and so forth. We knew we could enforce those things and hence we could support those things within SLAs. The other part of our governance strategy is to develop best practices for our site collection owners, site owners and other power users. We developed help desk SLA times around whether they followed the un-enforceable best practice guidelines: If they did, then we have a process to address their issue; if not, then their request falls outside of any SLA required times.” - Bill Chiou, Manager Business Applications, Quest Software


19

Establishing and Sustaining a SharePoint Governance Program By now, we’ve established a broad definition of governance. We described its major pillars and its relationship to technical operations and management. It should come as no surprise that we view governance as a cycle of continu-ous improvement, rather than a single implementation. Rome wasn’t built in a day. Or to continue our shopping mall analogy, the Mall of America in Minneapolis, Minnesota (the largest mall in the United States) wasn’t built in a day either. Nor can any effective SharePoint governance program be implemented in a one-time, one-day burst of activity.

Core Governance Processes Governance typically cycles through multiple core processes. Although each of these activities warrants its own white paper, we’ll introduce the major elements:

Establish Stakeholders

Although SharePoint often begins as an IT initiative, SharePoint is really business software for business users. Just as successful SharePoint implementation projects need to engage a cross section of business owners, it’s important to make sure that governance gives voice to business goals, operations teams, technology management and users. Stakeholders may be fluid through the years, but stakeholder engagement should remain constant beyond the original implementation project.

Establsh stakeholders

Gather requirements

Develop governance framework

Implement governed

operations

Measure results

Evaluate success for next steps


20

Keeping business sponsors engaged can be a challenge for some organization without a tradition of business steering and governance. It helps to ensure that governance reviews, meetings and communications are focused and efficient to sustain engagement.

Gather Requirements

Governance begins with an understanding of business goals. Over time, it also transits to include tactical needs and system capabilities and constraints. Shepherding this process is complicated. Working with business and technical disciplines requires education, tact and careful translation to assure that all governance decisions are made in consideration of commonly understood goals.

Develop Governance Framework

Policies and procedures are the key outputs of this activity. Turning governance requirements into effective, enforce-able policies and procedures is a complex process. The governance pyramid discussed above can help you prioritize the areas and sections of your farm that require the most attention. Policies and procedures should be documented as much as possible.

Implement Governed Operations

This is another huge endeavor. Training and communications are parts of this process. Procedures should be automated to the extent practical. Matching the tactical execution to the governance strategy requires perception and cultural awareness. Practical governance works across multiple user scales – from individuals through an entire user ecosystem. It also may vary from broad usage guidelines to tightly controlled and restricted policies. Parts of implementation may involve additional software tools or custom development. It may also lead to new technical training and operating practices.

Measure Results

Sustained governance programs require some degree of evaluation. In 200/300 level governance, much of this evaluation is based on qualitative or narrative feedback, but as higher levels of maturity are reached, statistical evidence can be gathered, such as monthly site requests compared to actual site creations.

Evaluate Success for Next Steps

All governance programs require ongoing evaluation to determine if they are effective in channeling SharePoint to help achieve business goals. Again, it’s not going to be perfect at first, but if stakeholders are able to make honest appraisals of their success, they can determine next steps. One of those next steps may be identifying additional stakeholders. In that case, continue back to the top of this list!


21

Questions that May Arise How you structure these activities is going to be particular to your organization – although, as noted above, Share-Point itself should play a large role in supporting effective collaboration. Your collaboration about governance is going to surface interesting questions that rarely come up at the beginning of a deployment. Here are two I’ve heard recently:

• “Our sales force is going through a lot of turnover – can we minimize the risk of information leakage from offline access to our product literature in SharePoint Workspace?”

• “Our security team usually deploys patches to servers. Our DBAs recently built their own SharePoint system to learn more, and we just hired a new SharePoint engineer. Who should install SP1?”

Here are the answers that came up from each company’s governance process:

• We should look at all their rights to determine what makes sense; SharePoint Workspace is only one piece of the puzzle.

• It depends, but SharePoint patching is different from other Microsoft updates. Let’s figure out a plan for communications and deployment that fits with other systems.

These answers clearly don’t work in all organizations, and they may evolve over time. Dialog and evolution are essential elements of sustaining your governance program.

Key Elements of a Governance Plan Finally, your governance plan must include the following elements – the 5 “P”s of your governance program:

• People – There should be a clear list of the named stakeholders who are involved in determining and approving the overall governance plan. Specific, named people.

• Purpose – There must be at least a mid-level set of business goals. By “mid-level,” I mean a level of detail that’s more specific than a mission statement. For example, “maximizing stockholder value” is probably too broad to help shape SharePoint governance; “enabling international sales team to collabo-rate from remote locations and across national boundaries” is a better business goal to shape governance.

• Policies and procedures – Policies and processes comprise the heart of a governance program. For less mature organizations, these may be generally known and expressed casually. More mature organi-zations will embody these in documents and web pages rather than shared anecdotes and advice. This material is also often reviewed in training as part of new employee onboarding and in-service programs. The most advanced firms embed policies and procedures into automated, self-guided processes for ac-tions like requesting a new SharePoint site.

• Products – Software tools – purchased, self-developed, or configured – provide the technical pillars of governance, and help to implement and enforce a governance plan. Some of the most common tools include security auditing and reporting, configurations, and policy-based workflows that give organiza-tions a picture of the current state of their system. Other software tools can greatly reduce the amount of time spent managing, migrating and customizating SharePoint, as well as make it easier for you to implement and enact your governance plan.

• Partners – Governance is a business process. You’ll need to work across the borders between busi-ness and IT, and between management and users. In addition to forging internal relationships and partnership, consider the wealth of available expertise in the SharePoint community among consultants, authors, trainers and other partners. You may have never implemented a SharePoint governance plan before, but many folks have years of experience. Remember, governance is NOT a product you can just install. The efficient answer is to engage focused subject matter experts.


22

A Tip: Practice What You Preach Noted historian Crane Brinton spent much of his career comparing and contrasting revolutionary movements. In Anatomy of a Revolution, he noted that the organizational structure of the revolutionary moment becomes the form of government for the new regime itself. If you have an openly selected legislative body running your revolution, you’re more likely to get the U.S. Congress at the end, for example, than if you organize the revolution around a single strongman and a military tribunal.

What does this mean for SharePoint governance? Simply put: practice what you preach. The governance committee needs to live by its own policies and procedures. For example, I consulted with an organization whose governance policy mandated that all documents and projects should be stored in SharePoint for effective collaboration. However, the governance team just collaborates with email. They had a hard time establishing their policies because they set a weak example, and struggled to understand the practical implications of using their own policies.

Organization culture is another crucial consideration. Culture should reflect preferred modes of action and interac-tions in any group. SharePoint governance should never stand in opposition to culture – rather, it reflects and even enhances any team’s mission.


23

Conclusion SharePoint governance is expected to remain a critical focus throughout the SharePoint world in the coming years as the user population, content size and functional options all grow. Proper SharePoint governance is an aid to broad adoption and technical management. Without governance, SharePoint becomes unusable and unmanageable.

Although the need for governance is undeniable, a lack of clear understanding about the meaning of governance can stall implementation efforts. Governance needs to reflect the five core pillars: security, auditing, reliability, usability, and supportability.

Finally, governance needs to be approached as an ongoing process that has its own maturity levels. Structuring SharePoint governance for continuous evolution is the best way to ensure sustained SharePoint adoption and user satisfaction.


24

© 2012 Quest Software, Inc. ALL RIGHTS RESERVED.

This document contains proprietary information protected by copyright. No part of this document may be reproduced or transmitted in any

form or by any means, electronic or mechanical, including photocopying and recording for any purpose without the written permission of

Quest Software, Inc. (“Quest”).

The information in this document is provided in connection with Quest products. No license, express or implied, by estoppel or otherwise, to

any intellectual property right is granted by this document or in connection with the sale of Quest products. EXCEPT AS SET FORTH IN

QUEST'S TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, QUEST ASSUMES NO

LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS

INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,

OR NON-INFRINGEMENT. IN NO EVENT SHALL QUEST BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE,

SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS

INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF QUEST

HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Quest makes no representations or warranties with respect to the

accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product

descriptions at any time without notice. Quest does not make any commitment to update the information contained in this document.

If you have any questions regarding your potential use of this material, contact:

Quest Software World Headquarters LEGAL Dept

5 Polaris Way

Aliso Viejo, CA 92656

www.quest.com

email: [email protected]

Refer to our Web site for regional and international office information.

Trademarks

Quest, Quest Software, the Quest Software logo, AccessManager, ActiveRoles, Aelita, Akonix, AppAssure, Benchmark Factory, Big Brother,

BridgeAccess, BridgeAutoEscalate, BridgeSearch, BridgeTrak, BusinessInsight, ChangeAuditor, ChangeManager, Defender,

DeployDirector, Desktop Authority, DirectoryAnalyzer, DirectoryTroubleshooter, DS Analyzer, DS Expert, Foglight, GPOADmin, Help Desk

Authority, Imceda, IntelliProfile, InTrust, Invirtus, iToken, I/Watch, JClass, Jint, JProbe, LeccoTech, LiteSpeed, LiveReorg, LogADmin,

MessageStats, Monosphere, MultSess, NBSpool, NetBase, NetControl, Npulse, NetPro, PassGo, PerformaSure, Point,Click,Done!,

PowerGUI, Quest Central, Quest vToolkit, Quest vWorkSpace, ReportADmin, RestoreADmin, ScriptLogic, Security Lifecycle Map,

SelfServiceADmin, SharePlex, Sitraka, SmartAlarm, Spotlight, SQL Navigator, SQL Watch, SQLab, Stat, StealthCollect, Storage Horizon,

Tag and Follow, Toad, T.O.A.D., Toad World, vAutomator, vControl, vConverter, vFoglight, vOptimizer, vRanger, Vintela, Virtual DBA,

VizionCore, Vizioncore vAutomation Suite, Vizioncore vBackup, Vizioncore vEssentials, Vizioncore vMigrator, Vizioncore vReplicator,

WebDefender, Webthority, Xaffire, and XRT are trademarks and registered trademarks of Quest Software, Inc in the United States of

America and other countries. Other trademarks and registered trademarks used in this guide are property of their respective owners.

Updated — January, 2012


25

About Quest Software, Inc.

Quest Software (Nasdaq: QSFT) simplifies and reduces the cost of managing IT for more than 100,000 customers worldwide.

Our innovative solutions make solving the toughest IT management problems easier, enabling customers to save time and money

across physical, virtual and cloud environments. For more information about Quest solutions for administration and automation,

data protection, development and optimization, identity and access management, migration and consolidation, and performance monitoring,

go to www.quest.com.

Contacting Quest Software

PHONE 800.306.9329 (United States and Canada)

If you are located outside North America, you can find your local office information on our Web site.

EMAIL [email protected]

MAIL Quest Software, Inc.

World Headquarters

5 Polaris Way

Aliso Viejo, CA 92656

USA

Contacting Quest Support

Quest Support is available to customers who have a trial version of a Quest product or who have purchased a commercial version and have

a valid maintenance contract.

Quest Support provides around-the-clock coverage with SupportLink, our Web self-service.

Visit SupportLink at https://support.quest.com.

SupportLink gives users of Quest Software products the ability to:

Search Quest’s online Knowledgebase

Download the latest releases, documentation and patches for Quest products

Log support cases

Manage existing support cases

View the Global Support Guide for a detailed explanation of support programs, online services, contact information and policies and

procedures.

WPA-FivePillars-SharePointGov-US-KS