Case Study: SharePoint Governance Lessons Learned

Christy Punch, Senior Intranet Strategist at SCANA Corp and Share Conference speaker tells us about the lessons she learnt when implementing a governance plan in her organisation and shares her tips on what (and what not) to do.

Times are tight. You'll have to make do. We hear it all the time in business and unfortunately there are not many organisations or industries that are exempt from hearing these phrases.

When faced with tight budgets and limited resources, sorting out SharePoint governance can be a daunting task. Especially if you're largely managing it yourself. But SharePoint governance is an important piece of the puzzle to get right and resource strain should not be a reason to forget about it altogether.

The good news is that it can be done with limited resources and virtually no budget. With some careful planning and strategic positioning, you too can create a solid governance plan that everyone can get on board with.

Here are three lessons Christy Punch with SCANA Corporation shared with us that she learned from putting together a SharePoint governance plan at her organisation that may help you when thinking about your own plan.

Do your homework  

Christy found that the best approach for her organisation was to do a lot of the work ahead of time and keep it very simple.

Based on her experience of managing the intranet and working with different people across the organisation, she developed and documented processes, guidelines, training plans, security levels and roles- all the elements she knew her intranet stakeholders were going to be concerned about. Christy made sure this governance documentation was simple and succinct. For example, the SCANA Corp. intranet guidelines for what content belongs on the intranet is only eight bullets long.

Once you have all your governance elements together, you’re ready to talk to the business.

Don’t get everyone in the same room  

One mistake Christy thinks a lot of people make is pulling 10-20 people representing each area of the company together in a room to decide on a governance strategy. What happens here is there are too many cooks in the proverbial SharePoint kitchen. Most people don't know where to begin, in fact most people don't even understand what SharePoint governance is!

Christy instead created processes and documented everything ahead of time before meeting with stakeholders. Then she met with stakeholders individually and walked each through the governance plans and documentation. She explained what they had set up and what risk mitigation plans were in place to address the stakeholder’s unique concerns. Christy then had each stakeholder sign the document to say they had seen it and that they gave their approval to go ahead.

A key consideration here is to make sure to explain how each part of the governance plan acknowledges their concerns and issues. What Christy found was that most stakeholders were so impressed that the team went ahead and did the work upfront and were willing to own governance. It made the governance buy-in process go very smoothly.

Have a retention policy 

 Christy told us that if they could have done one thing differently, it would have been to build a retention policy into the governance plan from the beginning. For example, what do you do with content that is no longer relevant on your intranet, but you need a record of it? What happens to that PDF form that’s been updated? Does the older version need to be archived?

This is one thing Christy and her team at SCANA did not do when they created their initial governance, but something they are currently trying to get in place before the upgrade to SharePoint 2013 next year. The company has existing retention policies for email, personal drives, and shared drives, but the team didn’t consider creating a policy for the intranet. Christy admits that it is an easy need to overlook, because when you launch your new intranet with updated and new content, you don’t really think you’ll need a retention policy.

Even with audits in place to keep content up-to-date and to ensure governance is being followed, four years later we make retention decisions on a case-by-case basis. Content is only growing and we realize that a formal retention policy is needed more than ever.

Three Common Mistakes with SharePoint Governance

Most organisations understand that a good governance policy is essential for any SharePoint deployment. So they create a governance plan. Done. Unfortunately that’s not the way it works. SharePoint governance is a complicated beast and many-a-plan has failed to be implemented because of lack of communication, over complication or producing an epic document that no one reads.

Let us outline three common mistakes people make with governance plans and how we can avoid making them.

1. People don’t know why they should follow your governance policy What often happens with 

SharePoint governance plans is that they’re produced (usually a lengthy document), uploaded to SharePoint along with an email to staff saying it’s there and they should refer to it for any SharePoint related guidance. This method of communication is what I call "toss it over the fence and hope that someone catches it". Do this and it’s very unlikely that your SharePoint governance document is going to be read, let alone followed.

Fix it 

Once your SharePoint governance policy is finished, make sure you communicate why you want people to follow this. Simply stating that people should follow it is not going to cut it. Telling people that they have to follow these policies just because is not going to be as effective as telling them if you tag your document it will make it easier to find later on. Or by following this policy you are helping us avoid legal issues.

Think about your own governance policies and what positive effects will flow from following them. Are there some time consuming tasks that can be sped up by following correct SharePoint governance policy? Will complying with these policies improve business productivity? Will it help staff build better working relationships with their colleagues? Most people have a commitment to making the business work as well as to their colleagues but only if they understand why they are doing it.

2. You make it hard for people to be compliant 

Complying with a governance policy is important, especially when there are legal ramifications. For example, one of the bigger issues especially in the US is that if you have a governance policy and you're not following it, you have created a big litigation risk. So one of the real reasons to focus on governance is to avoid the risk of not meeting legal requirements or having to spend a lot of money in the eDiscovery process when you get sued.

But perhaps people don’t know about this risk (see number one above) or the process for complying contains so many steps and is so time consuming that people are not going to bother with it.

Fix it 


Automate as much as possible to take the hard work out of complying with your SharePoint governance policy. Use templates so that all sites start with good governance built right in. When possible, use a third-party tool to make it easier to ensure compliance.

3. Your SharePoint governance policy is a beast of a document 

We’re really good at writing 100+ page governance documents. Even if you believe it’s a masterpiece and you can think of nothing better than pouring a good glass of red and settling in for the night to read it, I don’t know many people who would agree. It’s a shame because your governance plan actually contains valuable information that people need to know.

Fix it 

No one reads long documents so don’t create a SharePoint governance plan as a long, boring document. Think about creating small bits of consumable information. Wiki pages and quick guides are a great way to easily great small, visually appealing consumable bits of governance guidance.

But if you really want to make it easy for people, deliver your governance content in the context of where people work. For the most part, people won’t pay much attention to governance (or training) until they need to know how to do something. Try to go for “just in time governance”: small chunks of SharePoint governance information delivered at the moment you need it.

For example, if I’m creating a document, I’m probably concentrating on writing the document, not thinking about what file naming convention I should use. I’m only worried about this when it comes to saving my document. So ideally you want your quick guide about file naming conventions to surface when I’m about to save it. Like magic!

A simple, “no code” way to do this is to use Content Editor Web Parts (CEWP) on document library pages. CEWPs allow you to surface information “in place” for this kind of thing.

Although SharePoint governance plans can be seen as just a necessity, the information in your plan is extremely valuable and can help make life easier, not harder, for your users. Make sure you’re communicating the value to your users, making it easy through automation tools and providing “just in time” governance and training.



 

SharePoint Business Architecture

Architecture refers to the art of building. The word "architecture" has many meanings. Probably, the most understood meaning is "the art of constructing structures such as homes and buildings." The architect designs the blueprints of the home or building, taking into account factors such as design, space, light, materials, stability, load, and future needs.

Architecture is important because it accounts for the functional and nonfunctional requirements early on. Microsoft Office SharePoint Products and Technologies are powerful tools that increase collaboration and sharing of content. If implemented correctly, SharePoint can store and serve a vast quantity of information very well. However, without proper architecture and governance, a SharePoint deployment can become an unorganized collection of sites, links, users, and documents that hampers productivity and makes it harder to find information.

A good architecture plan and governance plan  lay down guidelines for deploying SharePoint as a solution to common business challenges. The architecture of SharePoint includes designing and allocating the hardware infrastructure needed to support the site, listing out the sites and site hierarchies that will serve the needs of the business, establishing users and roles that will be given permissions to the sites, establishing the relationships between sites, and planning for the needed site features, site customizations, and site and list relationships (which include how data will be rolled up and aggregated from sites and lists to provide an overview of information).

A good governance plan outlines the administration, maintenance, and support of the SharePoint environment. The governance strategy seeks to ensure that SharePoint is used in accordance with the designed goal and that best practices are followed to keep the portal manageable and usable. Best practices include processes for operation in the portal for tasks such as creating sites and lists, assigning permissions to users, using consistent naming conventions, and generally enforcing the guidelines.

When creating a building, architectural concerns include data gathering, planning, and the design of that building. The SharePoint architect must design the SharePoint building to withstand the test of time (meaning the architect must future-proof the implementation by building in robustness and resiliency) and, based on future client requirements, be able to expand easily (in other words, scalability with an eye on future upgradeability of SharePoint installation based on factors such as business need, hardware, software resources, and so on).

For SharePoint, there are three levels of architecture: hardware architecture, software architecture, and information architecture.

Hardware Architecture

To deliver a robust SharePoint 2010 environment, it is necessary to carry out technical design, which looks at all areas of SharePoint 2010 concerning the equipment it will run on or be connected to and systems and processes it will interface with. The following is a list of planning requirements:

• System requirements determining what is required to deploy SharePoint 2010.
• Services architecture determine what service applications are defined and how are they structured.  
• Logical architecture presents the design in terms of isolation. This planning task looks at farms, service applications, Web applications, content databases, site collections, sites, zones, MySites, and so on.
• Authentication examines authentication methods, such as claims-based authentication topologies.
• Server hardening this task focuses on server snapshots, ports, protocols, and the Web Server, Application Server, and Database Server roles.
• Business continuity examines the business decisions, processes, and tools put in place to handle a crisis. A crisis can affect the organization or be part of a local, regional, or national event. Business continuity and disaster recovery are huge areas in SharePoint and planning for them is an important part of ensuring a resilient and robust platform.
• Performance and capacity determines the process of mapping the design for SharePoint 2010 to a farm size and the hardware needed to support the business goals. 
• Virtualization SharePoint 2010 is fully supported when deployed in a Windows Server 2008 Hyper-V environment. This task examines the licensing and topology.

Software Architecture

The software architecture of SharePoint is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. So decisions to be made include determining what components of SharePoint are needed, what will be visible, and the structure of SharePoint. For example, is SharePoint going to be treated as an out-of-the-box solution, slightly modified with internal applications, or will it include third-party additions? Will it simply need just team site components (for example, the free SharePoint Foundation version), or do you need more service application, enterprise content management, or metadata features, such as those provided through SharePoint 2010 Enterprise?

Software architecture examines SharePoint from a site and solution planning perspective, taking into consideration site components, security, governance, enterprise content management, Web content management, managed metadata, business intelligence, data and processes, access services, quota management, and social computing.

As an example, suppose that you’re going to implement SharePoint in an organization that already has SharePoint but needs to expand. They have a third-party tool providing some functionality that the client finds useful. From scoping the information architecture, you found how much usage it gets, how the data is used, how it flows, and so on. From further investigation of the software architecture, you find that the relevant tool cannot grow with the service. This means revisiting the functionality in terms of the information architecture and finding an alternative, which then drives the software architecture.


Information Architecture

Information architecture involves studying the type and amount of information used within an organization, organizational structure, information flow, process flow, and more. This is an extremely important aspect of the Plan phase. Without it, SharePoint is not defined to meet the client requirements, because information architecture leads to SharePoint user strategy in terms of content management. Identifying the organizational information and management information goals combines the work of information analysts and business analysts, coordinated by the project Manager and feeding back to the SharePoint architect.

Large organizations have documentation plans and methods of managing their data across the organization (for example, retention plans and archive plans), and some use information analysts to manage, coordinate, and categorize how members in the organization deal with information. Additionally, organization face legal and regulatory compliance requirements that directly influence how data is retained long term. In the United States, for example, the Sarbanes-Oxley (SOX) Act established record-retention rules in July 2002. It is highly recommended any company have a records-retention policy that complies with regional and national laws.

Another benefit of a good records-retention policy is a decrease in storage costs.The information analyst details from the ground level the organizational data concerning information standards and policies set out by the business. Information architecture establishes information control and compliance policies so that accumulating information is done in a well-managed way and does not create data chaos.

SharePoint 2010 provides enterprise content management tools that can help lower costs associated with the control and storage of information, decrease complexity, and increase user participation relating to content control. Combining SharePoint 2010 with Office 2010 takes information management to a higher level by extending information control from the desktop environment to SharePoint 2010 sites and content.

The aim of information architecture in SharePoint is to reduce the manual end user actions related to metadata, to scale policies and processes across all types of content in an organization, and to increase compliance and transparency. To meet this goal, there must be an examination leading to the creation of an organizational taxonomy. During the Design phase of the SharePoint project, the information analyst (working with the SharePoint architect) creates a taxonomy for the organization by examining metadata and information policies.

The business analyst can provide, through the collection of user requirements, an understanding of what the typical content life cycle is in the business. This shows how end user content becomes managed content. Typically, managed content begins its life as temporary information created by the individuals in the organization, leading to work in progress (and this means multiple individuals working on the same content) and in the backdrop of retention and disposition (business teams or individuals deciding on whether documents should be archived and what their state is, either approved, published, or other). SharePoint 2010 provides tools to ensure the content life cycle can be designed and adhered to. Enterprise content types, document sets, information management policies, metadata, term sets, and content organizers can be established using SharePoint 2010 document management features. 

Here are some basic procedures for setting the information architecture for SharePoint 2010:

• Carry out an investigation and inventory of existing content.
• Classify the content by performing the following tasks: Look for definitions of structure, policy, and defaults; Identify organizational-level content by enterprise, department, and team; Define what “general use” content is.
• Organize content into enterprise content types and document sets, keeping the following factors in mind: Content types are where there are definitions of structure, policy, and defaults; Content types can inherit from other content types; Document sets are where the work spans multiple documents.
• Decide where information management policies apply. When doing this, be sure to consider access permissions, auditing, user restrictions (for example, no printing), retention, and deletion.
• Decide on applicable metadata by performing the following tasks: Define customized columns, and associate them with documents and lists; Define any cases where the system or user might take different actions based on the characteristics of an item. Note that the characteristics of the item are metadata; Find out what common things users will want to sort or filter items on; Find out what words or phrases users are likely to tag items with; Use Choice or Lookup columns in SharePoint 2010 sites; Use the existing taxonomy if the organization has one.
• Map the physical flow of the document, including the sites, lists, and libraries where the content will be physically located throughout the document’s life cycle.