By Monica Crocker, CRM, PMP, CIP, edited by Robert Smallwood
Microsoft's SharePoint® server product dramatically altered the content and records management (RM) markets. Previous to SharePoint, solutions were somewhat cumbersome, managed large quantities of documents, and required extensive implementation effort for each business application. SharePoint provided an enterprise level platform for the remaining small-volume, ad hoc solutions.
At a basic level, it is a collaboration platform, but it is often leveraged to be a content repository as well. If properly implemented, SharePoint can reduce duplication of information, automate business processes, serve up a common lexicon for categorizing information, provide a social media platform, give users access to current and historical e-documents, dramatically reduce network traffic loads (by cutting the number of e-mails with attachments), and stop the growth of shared drives. It can also provide a secure platform to support bring-your-own-device (BYOD) mobile programs and other mobile solutions.
Given all its stated capabilities, SharePoint can be used to help organizations govern their information. But, in order to achieve those benefits, the implementing organization must take a structured approach to the deployment of its SharePoint environment. The 2006 amendment to the U.S. Federal Rules of Civil Procedure require American organizations to produce any and all “electronically stored information that is relevant, not privileged, and reasonably accessible.” Similar legal requirements exist in Canada, the United Kingdom and Europe, Australia, and other developed countries. Information stored in SharePoint often is included in the “relevant” information that must be produced. So SharePoint should be deployed in a manner that makes all information contained within it findable, accessible, securable by a legal hold notification (LHN) and available for production in a timely manner.
For SharePoint deployments, an ounce of prevention truly is worth a pound of cure. Since every SharePoint environment includes corporate information, organizations can avoid a lot of headaches and future information governance (IG) risks if they invest time and deliberation in planning how they will deploy SharePoint. These plans should be based on the business objectives for SharePoint that are tied to the organization's overall business objectives and include making all the necessary IG policy decisions before rolling out the solution to users.
SharePoint itself is a tool; it is not a panacea for poor IG, and simply deploying it will not resolve business issues or compliance problems. When it comes to managing business records, “Like any RM solution, SharePoint alone will not solve your needs unless it is used to support clearly defined [business] processes.”1 Therefore, IG policy development and business process analysis are critical in the planning process.
SharePoint often is expected to perform content management and records management, and also support e-discovery requests and legal holds. But sometimes, instead of solving records and IG problems, they become worse in an ungoverned SharePoint environment, since users often:
The unacceptable result of this lack of governance is that, instead of being a platform that can positively transform business processes, SharePoint actually can make it more difficult for people to do their jobs. And if users decide that SharePoint is actually making their work harder, they will begin to revert back to old, familiar (disorganized) ways of managing their information. In other words, they may continue to keep duplicate documents on their local C drives, go back to their existing shared drives, and keep sharing information by attaching documents to e-mails.
The SharePoint governance model should make it clear where and how users should both store and find information. A well-governed SharePoint environment provides enough consistency in how information is categorized to support sorting and filtering of search results so that users can quickly narrow results to the specific information or documents they need.
But keep in mind that a SharePoint governance model needs to be tailored to your organization. It will not work if it does not fit with your culture, technology standards, and staffing resources.
There is no such thing as one set of SharePoint governance best practices that every organization can adopt. Rather, developing a SharePoint governance model involves determining the appropriate answer to a series of questions regarding your organization's business goals, resource limitations and policy constraints. Once the initial plan is developed, it should be validated against a broad sample of use cases for the system.
As with any initiative that requires behavior change or additional effort, you will encounter resistance. The nature of the resistance will depend on the culture of your organization and the personalities of the individuals involved. Some of the SharePoint-specific objections you should be prepared to counter include the premise that nothing in SharePoint is a record or that the very nature of SharePoint dictates that it should just be turned on and allowed to spread virally. Others are that “Users won't follow those procedures” and “Governance is too much of a burden to the user.” And then, of course, there is all the standard user resistance to any system change implementation.
As with any initiative that requires behavior change or additional effort, you will encounter resistance when implementing a new SharePoint system.
Too many organizations deploy SharePoint without putting the necessary effort into planning how this technology tool will be governed. The result is similar to what is often found with e-mail or network shared drives—scattered information and documents with no organization or governing policies. Only the situation is worse, because SharePoint has more types of content and quickly collects an even greater volume of information. At the highest level, all these types of content are part of SharePoint: sites, pages, libraries, and lists. And there are many subtypes within each of these content types. For instance, the list content type includes announcements, calendars, contacts, tasks, discussions, issues, surveys, and custom lists. And the site content type includes “MySites,” which allows users to store a vast array of content, including their own documents (which could be personal and/or work related) and social content, such as tags and ratings of content on other sites.
Another contributing risk factor for SharePoint is that, to a large degree, it is self-provisioned. This means that, while the environment typically is deployed by central information technology (IT) staff, business users usually are given the authority to create new repositories for information within that environment without IT intervention. This allows SharePoint to function as a dynamic collaboration platform.
Because of its nature, in an ungoverned SharePoint environment, you may have:
In sum, lack of governance can significantly diminish the business value and increase the risk of your SharePoint deployment.
This is more than a mess. It is a costly mess, because the organization is not achieving the maximum business benefit from SharePoint. Further, retrieving information during e-discovery for legal proceedings will be fraught with search and retrieval challenges and will be more costly and less efficient.
However, even if you have already started your SharePoint project or need to deploy before you feel your governance model is complete, you still can implement some IG strategies. That is, late is better than never, and gradual implementation of governance is better than none at all.
As with any well-managed project, the first step in a SharePoint deployment is to draft a project charter that defines the scope, budget, timeline, and business objectives for your SharePoint environment.
The next step is to draft a project schedule that includes copious amounts of time for the up-front planning effort necessary to create the SharePoint Governance Model. Have the project executive sponsor sign off on this timeline so that he or she understands that the project will include time to think through key issues prior to deployment and why that is critical for your organization.
Then assemble your governance team. Include someone who understands the organization's culture and the business objectives for SharePoint (such as a business analyst), someone who understands the technical aspects of SharePoint (like a system administrator), someone who understands the compliance aspects of SharePoint (such as a compliance officer, records manager, or legal counsel), and someone who can help implement the training and communications plan (perhaps from the human resources department). And, most important, make sure your governance team has the necessary authority level to determine the governance approach.
Critical to success in SharePoint deployments is consulting with users about their processes and needs.
Governance decisions can be very controversial and require documentation.
The SharePoint governance model planning process necessarily involves consulting with users about their collaboration, business process, document usage, and information storage needs. If the governance structure interferes with their ability to do their jobs, users will start creating and storing documents without knowing what rules to follow, or why the rules exist, and they will find their own work-arounds to satisfy their business requirements. For instance, if you restrict file size requirements too much, users still will store large files somewhere—perhaps unsecured in the cloud. If you do not allow certain file types and users need them, they will find another place to store them where they might be difficult for other users to find. And soon you will have all sorts of variations of folder and file systems and scattered documents and information, which results in the aforementioned information chaos scenario.
Regulatory and compliance factors also must be incorporated into SharePoint governance decisions for most organizations. Therefore, the process must include RM staff for guidance on crucial RM issues and legal staff for legal and compliance requirements.
Finally, create a formal SharePoint governance model “document.” Do not rely on meeting notes or design documents to reflect the decisions made during governance discussions, though it may be valuable to keep those as a way to retain the reasoning and decision paths that led to the final model. Governance decisions can be controversial, so the governance model selected should be explicitly stated in a dedicated document and officially “approved” by the appropriate stakeholders.
Start from a high level, with strategy and corporate governance issues. Develop a problem statement in your project charter so that you know what you are trying to accomplish, and then develop measureable, time-constrained business objectives so progress and success toward milestones can be measured. Next, be sure to align these objectives with your organization's overall vision statement or strategic plan. Aligning the technology with business considerations is key to a successful SharePoint deployment.
First, develop a problem statement and formulate business objectives for the SharePoint deployment. Then align those objectives with your overall Strategic Plan.
In order to identify specific business objectives for SharePoint, you may find it useful to conduct some focus group sessions with thought leaders from across the organization. Some examples of questions you might ask are listed next:
Look for these themes in survey responses that might apply to your organization:
Understanding the organization's current information management challenges allows the SharePoint governance team to identify business objectives for SharePoint and ensure that each individual governance decision supports accomplishment of the business objectives while at the same time supporting compliance with IG policy.
Once business objectives are formed, use them to define the guiding principles for the SharePoint governance model. It is prudent to lay out the guiding principles early in the governance document, since they provide a framework for everything that follows. Decision categories that can help shape the guiding principles are:
Each of these guiding principles should be linked to any appropriate organizational policy or applicable law. In addition, they all should be linked to the business objectives for SharePoint. For instance, this could be a guiding principle:
Every site and page in SharePoint must have a clearly identified owner and a backup owner.
This sets a standard for the project team to follow, which helps end users identify the authoritative copy of information and addresses the governance issue regarding orphaned content.
After business objectives are formed and sharpened and guiding principles are established, determine the scope of the SharePoint deployment: Just where are the boundaries of information you are going to govern? Any governance model likely will cover sites and pages and documents. But will it also include specific types of content, such as calendar items, announcements, discussions, and lists? Which specific documents will be governed in SharePoint (all/only those declared “records”/only those that are flagged as “final”)? How will documents be managed in the different stages of their life cycle (delete anything that has not been modified for a year/move anything declared final to an archive)? How will your organization address e-discovery requirements? Which document and content types are not governed in SharePoint? For instance, some organizations govern down to the “X” level (e.g., three levels deep in the site structure) but not below. Some choose to manage content on MySites while others simply impose a storage size limit on MySites.
Once business objectives are formed, use them to define the guiding principles for the SharePoint governance model.
Be sure to clearly state the selection criteria for storing information in SharePoint.
These are the types of questions you should be asking, not only from an IG perspective but also to optimize future system performance of SharePoint. Better processes and fewer documents means faster performance when you are in the heat of the business battle.
Your governance model needs to address the two issues related to scope:
Exactly what information will be stored and managed in SharePoint? And, of that, which information or documents rise to the level of being records?
The selection criteria for storing information in SharePoint must be clear to all system users and administrators. They need to know not only what file sizes are allowed but also what file formats are permitted—or prohibited—as well as size limits for lists, libraries, and the entire site itself.
You must determine how your organization's IG policies relate to SharePoint. Microsoft has structured SharePoint so that every piece of information is a “content type.” In addition, the tool allows you to configure RM policies/actions at various levels in the system; you can set them at a site collection level, a site level, a library or list level, or all the way down to the specific item level. Every particular instance of every content type could have a retention schedule and resulting actions associated with it, but that might be a lot of overhead for very little payback. What do you manage and what do you not manage? Examples of things you might not manage are work flow configurations, views, searches, and page templates. Examples of things you probably want to manage are documents and lists.
Your IG policy section should answer these questions:
Any existing retention schedules must be translated into defensible disposition policies within your SharePoint environment. Finally, specific processes for managing business records must be established.
For instance, if your SharePoint charter identified “sharing administrative information such as meeting agendas and minutes” as a primary objective of your deployment, you could create standard libraries for “administrative” documents on each division's site, create an “administrative record” content type to categorize any document in that library, and associate the retention policy for that content to all those documents. This method would automate the purging of all administrative documents after the retention period has expired.
At some point in the SharePoint governance model document, you also need to address if and how you going to use document IDs and how major and minor versions of information are used and retained. For example, you could decide not to keep any previous versions of meeting agendas but to keep previous versions of policies for a number of years after they are superseded with new versions. The IG policy section is a good place for those items.
Clear roles and their associated responsibilities for contributing to, maintaining, and utilizing the information in SharePoint must be established during the governance planning process. Only by spelling out who is responsible for what are you able to expect that your SharePoint environment will continue to follow the governance model.
Questions to ask with regard to definition of roles and responsibilities include these:
Some examples of possible SharePoint roles within a given organization are listed next.
The roles and responsibilities section of the SharePoint governance model will need to describe how users can request a site and how they get support for their sites, including the support escalation process. For this purpose, a service-level agreement (SLA) that outlines the basic support levels, time frames, problem escalation processes, cost allocations, and other issues related to service is useful. Wherever possible, create an SLA and refer to it so that users have clear expectations regarding how long it will take them to get a new site or get support for an existing site.
Guiding principles provide the “what” of SharePoint governance. Roles and responsibilities define the “who.” The governance model, or a separate set of procedures referenced by the model, also needs to describe the “how” of governance. Most important, it should detail the process of requesting and creating SharePoint sites. Also critical, the model must include a process for decommissioning sites. Further, as the ownership of the site may change in the future, the process of transferring site ownership must be established and standardized. In addition, more specific processes, such as those for migrating information into SharePoint, must be created. If a business record is created, you need a process to manage it accordingly, whether that is by sending it to a central records repository to complete its life cycle or by managing it in the library where it originated. When legal holds are required, standard processes must be established to produce information requested during e-discovery. A demonstrated ability to produce trustworthy information—information that can be proven to be authentic and unaltered—is an absolute requirement. All these processes must be designed to be as efficient and low cost as possible.
While guiding principles provide the “what” of SharePoint Governance, roles and responsibilities provide the “who”—that is, who can store information, access it, and make changes to the system.
Your training plan needs to recognize that a given individual may fill more than one role on different SharePoint sites.
A well-defined training model as part of your SharePoint governance plan shows that your organization gave users the rules about SharePoint usage and the necessary tools to comply with those rules.
The training section of your SharePoint governance model should break down the overall training strategy: train everyone, just train site owners, or simply refer users to training resources. This section should explain the process for requesting training. It also should describe or include a reference to a detailed training plan. The training plan describes the ways training will be delivered and how training content will be created. It should include a level of detail sufficient to identify the different types of training (site owner training, information custodian training, user training, basic training, advanced training, etc.). As you define the training plan, remember that any given individual may fill more than one role; one person might be an owner on one site, a contributor on another, and a reader on many. So the training plan should allow people to get all the training they need, without having to endure the same training modules (such as “Introduction to Our SharePoint environment”) multiple times.
An important training consideration is that SharePoint is a popular technology right now, and individuals with SharePoint skills are hot commodities in the marketplace. Therefore, in order to eliminate any single points of failure in your SharePoint roles, make sure to cross-train key roles to ensure that more than one person can perform critical functions.
Your communication plan for SharePoint governance needs to take into account that you are asking people to change the fundamental way in which they manage much of the core information they use to do their work. So your communication plan needs to clearly state that the proposed SharePoint governance model:
Your communication plan needs to recognize that you are asking people to change the fundamental way they access and manage documents.
An understanding of the SharePoint governance model should make it clear to users what the organization intends to do with SharePoint: the business drivers behind the deployment. It also should be very clear what users are expected to do and the training they will receive so that they can work well in the SharePoint environment. Every person assigned a SharePoint role should be able to review the communications regarding governance and understand how, exactly, it will impact them.
CHAPTER SUMMARY: KEY POINTS
1. Don Lueders, “It's All About the Processes,” June 18, 2009, http://sharepointrecordsmanagement.com/2009/06/18/its-all-about-the-processes/.
* Portions of this chapter are adapted from Chapter 14, Robert F. Smallwood, Managing Electronic Records: Methods, Best Practices, and Technologies, © John Wiley & Sons, Inc., 2013. Reproduced with permission of John Wiley & Sons, Inc.
18.191.195.183