Enterprise Content Management with Microsoft SharePoint: Content Control

After content is in the system, it’s time to put it to work. You might think this is the easy part. Functionally, it is much easier than the creation and capture portions of the ECM life cycle, but strategically, it’s very difficult. We have found many organizations that are several years past an initial SharePoint deployment looking back and realizing that the adoption of this technology has not really improved a business process. In many cases, it has either become a web version of a shared drive silo or a collection of mismatched sites that aren’t easily navigated by users.

As we mentioned in Chapter 1, an ideal EMC solution is a balance between the effort to capture content and the effort to consume or find content. The preceding chapter was all about getting content into SharePoint; this chapter is all about consumption and accessing the content you need in an intuitive and structured manner. After content is stored in SharePoint, you have to pay particular attention to how content is managed, who manages that content, and how the content will be delivered and consumed. Last but not least, you need to determine how the content completes its life cycle, through disposition or long-term preservation.

Management of content

When we talk about the management of content, we are not just referring to who is in charge of SharePoint. Yes, we will discuss how to make sure your content is being treated properly. But we are also talking about how to manage its value, the people who use it, and setting proper expectations.

Two extremes prevail when organizations start implementing SharePoint. It either is seldom used, or it’s used prolifically without governance. Being aware of both of these opposing outcomes will guide your ECM team’s planning and help determine where to focus their primary efforts. You can start by answering the following four questions:

1. Is your organization one that embraces new technology or resists?

2. Does your organization process work at a macro or micro level?

3. Are shared drives the primary source of information management today?

4. What other systems or processes are used to manage content today?

Being honest about whether or not your organization can embrace new technology is an important question. In general, younger organizations are more adept and open to change, adopting new technologies, and improving processes. This is also true about people, so being realistic about who, where, and how you will implement and be successful with change is vitally important. Be aware of signals that people are resistant to change. These signals can come in the form of availability for meetings, a consistent focus on exception processing during design meetings, and the use of phrases like “If it isn’t broke, don’t fix it” or “This is how we have always done it.”

It’s important to work within the confines of how your organization adopts and addresses change. Specifically, in question 2, we ask whether your organization processes work at a micro or macro level. What we mean is this: How are decisions made, and who can effect change in work processes most effectively? In some organizations, groups and departments are given a fair amount of autonomy to get work done in the most efficient manner, using the tools and techniques that suit them best. In other more structured organizations, everything is mandated from the top down and there is a great deal of command and control.

Depending on your situation, you need to know how and where to start scoping the management aspects of content in your SharePoint ECM solution. This will also help you determine what individuals need to be on the ECM team, which we will cover in Chapter 5.

Change opposition or support

We implied earlier that ECM is as much, if not more, of a people problem as it is a technology problem. Although we use common nomenclature for business processes, like “expense approval,” and for departments, like “accounting,” no two organizations are alike. Because of this, it’s important to use principles and methods to guide your ECM solution design and not necessarily defined steps or configuration outlines.

We have found that there are companies who love new technology and, as an aspect of the culture, cannot wait to get their hands on it. These types of organizations or groups will be very excited to start using SharePoint and will be your early adopters. You can leverage their enthusiasm, but you will need to contain it, because this is usually the beginning of how viral use of SharePoint starts. Without Information Architecture (IA) or governance, these users will adopt bad habits and the ECM solution will turn out poorly. When this group establishes a bad habit, it’s hard to stop it.

You might find that the organization in its entirety or in specific groups is very used to process and control. These control-conscious groups are welcoming and normally not opposed to systematic ways to organize information. If you look at their shared drives, they tend to be very organized already, which we hinted could help with IA planning we cover in Chapter 4. While this group will be great for adopting SharePoint for ECM in the correct way, they will be hard to get moving, and they tend to not like change.

The other interesting element in this group is the nature of their content; it is typically more transactional and repetitive, as opposed to unstructured information. Most organizations have one or more of these types of groups. Some common examples are in finance, engineering, operations, legal, and human resources. Also, many industries are very used to structured processes and governance such as healthcare, insurance, and financial sectors.

Both types of groups, if already using shared drives as the vast majority of the content world does, believe that they have a system for organizing content and that it’s just fine. Whether a knowledge worker admits it or not, their slice of the shared drive pie is a dumping ground for content. Sometimes it’s organized, and at other times it was created while on a conference call. The net result is a system that they know because they built it, but one that does not serve the overall organization well. To understand how people might want to use your SharePoint ECM solution, it’s important to understand how content is being stored in these shared drives today.

How users currently manage their content is a good indication of how they will want to manage it in SharePoint. Habits are very hard to change, and if a person has been doing a particular job function for many years, they are used to adopting workarounds to get the job done. At the first sign of any struggle, a user may revert to old habits, such as looking for a workaround or complaining that the new system just doesn’t work. This is compounded by daily stress and workload that make the burden of using a fancy ECM solution even higher.

The four questions we asked at the beginning of this chapter were not outlined to establish any specific components of your implementation. Rather, they are meant to generate introspection so that you will begin to understand where your problem areas will be. You should use this knowledge to identify what groups will provide opposition or support for your ECM team’s planning of a successful implementation and extension of SharePoint. The next step is to use this information to address the specific areas of the Management portion of the content life cycle. The following outlines the primary areas to consider for who manages the content. Please keep in mind that the management of content is not the same thing as who manages the security or access levels to the content.

• Security

• Document types/retention schedule

• Document audits

• Managing bad habits

• Policy creation and implementation

Who manages content?

As a best practice, we recommend that the individual(s) in charge of managing content in SharePoint should not be the same people who maintain SharePoint, typically the IT department. In fact, depending on how large your deployment is, you can and should have many people who are responsible for managing content. The more people who are active managers of content, who understand the principles and benefits of your IA, the better chance you have of maintaining control of your information.

SharePoint as the ECM platform is the responsibility of the IT department, from the server and storage infrastructure to the farm installation and configuration. Their involvement or, rather, responsibility should stop at the site collection level. This is typically a blurry line, where IT responsibility ends, and your IA and general ECM governance begins. Below the site collection, an individual(s) who has a vested interest in the success of ECM in your organization should manage your ECM solution.

In many organizations, this person is the Records Manager, Content Manager, or Information Architect. Some small organizations don’t have the luxury of such a position for budgetary reasons. Even some larger organizations haven’t identified the need for this specific position. There are a variety of reasons why this might be the case—for example, there is little regulatory oversight or the organization has never been party to litigation. In such cases, you have to consider appointing a team that is responsible for the content or, if the organization is large enough, individuals in each functional unit, often referred to as Super Users.

This is challenging in many organizations because both IT and the Content Manager or Super Users have, or should have, a stake in the ECM solutions performance. For example, it should be a defined part of their regular responsibilities or tied to a Managed Business Objective (MBO). In some cases, this can create challenges between IT and the Content Managers because they often do not have the technical know-how to take over at the site collection level.

The first problem is usually addressed by creating synergy between Content Mangers and the IT staff. Both should be on the ECM Committee, which we will talk about in Chapter 5, and both should be bound by the common goal to make the ECM solution work, both technically and operationally. In most organizations, this works out well, but it also always helps to draw a clear line in the sand stating that IT is responsible for everything up to site collections and the overall performance and uptime of the farm and that Content Managers are responsible for everything below site collections.

The second problem is much harder to address, and organizations can really address this issue only when they identify and recruit the required staff well, before SharePoint is selected as a platform. Many organizations luck out and can identify users in each function who aren’t in IT but are technically savvy and eager to be a part of this exciting new technology initiative. As for officially titled Records Managers and Content Managers, it is good to make sure that they have sufficient SharePoint experience and training. A rule of thumb is that it takes about one year with hands-on experience with SharePoint to really begin as an administrator.

Security

If you have ever attended a SharePoint event, you know that one of the most common topics or common subjects within a given topic or track is security. This is both good and bad. The good news is that there are many individuals out there who know a lot about SharePoint security. The bad news is that the number of sessions at any conference on a particular topic is a gauge of how complex that topic can be.

Our approach is different. When it comes to ECM security, the best principle is that less is more, so keep it simple. This is one of the many areas of building an ECM solution in SharePoint that could result in planning paralysis.

We know and can recommend that simple is better because indirectly, while you are designing a fantastic IA (covered in Chapter 2), you are determining security. That’s right: security users and groups are very similar to IA. And fortunately, IA in SharePoint indirectly helps determine your security structure. So with a well-designed IA, part of the security work is already done for you. Now let’s cover the two basic types of security in SharePoint: repository level and document.

Repository

Repository level security is the shared responsibility of the Content Manager(s) and IT. The repository level security should map to functional or departmental security groups in your organization’s active directory. Active directory most often is where users and access levels are assigned. Typically, users are added to groups based on their department or function. Most organizations have this well established, which also means it cannot be changed. Although every organization is different and therefore every active directory forest, tree, and domain structure is different, the goal is to have these high-level functional groups align with the SharePoint repositories.

As we explained in Chapter 2, repositories are both the logical and physical location of content. The top-level repository is the web application, also known as the site collection. The next level is the site, and the final level is the library. The number of web applications is roughly determined by the size of the organization and the amount of content. While it’s certainly possible to have multiple content databases, in this book we will assume that there is one content database per web application.

This means that the site collection is the first point, or envelope, that you can apply security to. For ECM, three general principles to follow for security are as follows:

1. Never assign user level security.

2. Never assign security lower than the site.

3. Never break inheritance lower than the site.

In general, one of the biggest challenges of security is the administration of it. Alarm bells go off in every organization when the security topic comes up; multiple people want to take ownership, and frankly, it becomes overthought.

When you think about it in simple terms, it’s rare to find an organization where everyone in a department or group can’t see all documents. Of course, there are exceptions; for example, Executive Management. However, the proposed approaches for IA that we outline in Chapter 4, will show how this is addressed by having a specific site collection or site for the organization’s leadership groups.

Therefore, the primary consideration is the groups, what the groups are applied to, and cross-functional sharing.

The ideal scenario

Based on our experience, we propose that each group gets assigned their portion of the IA. For example, the Human Resources security group gets assigned to the HR site collection or, for small organizations, to just a single site. The Engineering security group gets assigned to the Engineering site collection for large organizations or to a single site for small organizations. The manager of both of these functions should belong to a separate security group called Managers, and that group should be assigned to the Managers site collection for large organizations or to a single site for small organizations.

Our goal is that you begin to see a pattern emerging that will become very clear in Chapter 4 as you work through the practical examples. You should also be able to guide each group as they build out their portions of the IA by using the examples and templates we provide in this book.

This will also allow you to adhere to principle number 1, which is to never assign user-level security. With this method, you should never have to apply ad hoc security to individual users in the organization. The primary reason that we do not want you to do this is because managing it is very problematic, if not impossible. Without a third-party management tool, it’s impossible to know where these ad hoc users have been assigned. It is also very difficult to make sure, when security is no longer needed or when the user is no longer with the company, that the user can be or is removed.

Team site

Cross-functional projects/repositories needing many users to be involved should be created in a separate site collection for teams. In this site collection, the root-level security is the entire organization, and the team leader will solely determine the individual team site security in an ad hoc manner.

This seems like an exception to the rule, and it is. But the concept is still within the principles of ECM. The result of the project—that is, the individual team site—is the document that belongs to ECM. Therefore, the team site itself is a sort of record. The team site collection is an ECM system for all projects, and because projects have short lives, the project and all activity within that project live and die there.

The biggest challenge with this approach is to make sure that team sites are deleted when the project is over and, if the result of the project was a document, that the final document ends up in the approach function in the organization. For this, in SharePoint 2013, we recommend using the new site disposition functionality, and in SharePoint 2010, we recommend looking at third-party tools or relying on the team leaders, via policy, to clean up after themselves.

This approach addresses the need for cross-functional work, keeps the principles of ECM in their designated functions, and makes IA and ECM management flexible. Figure 3-1 shows an example of a project team site used as a cross-functional repository for the Projects team site.

The final two principles we established for repository security were never to break inheritance below the site level and never to assign groups lower than site level. Both are established because of the fact that security is very hard to manage, and as soon as management is lost, it’s a rapid downward spiral in security and sprawl issues. This is especially true with the new share functionalities present in SharePoint 2013. Therefore, to keep security very clear and administration clean, we recommend that security be applied only at the lowest repository envelope, which would be the site collection for large or document-heavy organizations and a single site for smaller organizations. After this has been enabled on these repositories, it should not be broken out any lower.

It is even possible to get item-level security, and while it sounds fun, it’s not. We have yet to find a fully justified use case for when item level security is right.

Site administration and recycling

In addition to repository security, the following SharePoint-specific security considerations will be important to understand and plan for when implementing your ECM solution:

• Site collection

• Site administrators

• Recycle bin

Who has access to administration functions on the site and, more importantly, the site collection is an important consideration, primarily because of the risk it could impose on the stability of SharePoint. A site collection and site administrator have the ability to modify security, enable and disable features, navigate to terms sets, modify content types, and so on. Without malicious intent, it’s very easy to change something small, such as a content type, and harm the user’s ability to use the system.

The process we recommend is to have no more than three site collection and site administrators. If at all possible, assign only site collection roles, and no ad hoc site administrators. Your ECM solution, when established, should not change often, so the need for a site administrator should be minimal. The group of three should include two Super Users or Content Managers and an individual from IT–most likely the farm administrator. The purpose of three is redundancy and accountability. In the governance section of Chapter 7, we will talk about tracking these users and changes.

The recycle bin in SharePoint has special considerations at the site and site collection level. The recycle bin is where documents go when they have been deleted. By default, recycle bins are set up in two stages. This means that there are two recycle bins: the site recycle bin and the site collection recycle bin. The settings for this are found on the web applications settings page in central administration, as shown in Figure 3-2. It’s possible to turn off the second stage recycle bin, and it’s also possible to set a purge date for when the recycle bin is cleared: by default, 30 days.

This method is useful because it’s not uncommon for users to delete a document in the site and, on day 31, realize that they should not have. The consideration that needs to be made is who can restore, empty, and administer the recycle bin? Typically, the same three site collection administrators we outlined are the same who have access to administer the recycle bin. There are also two separate types of bins at each level: the end-user recycle bin and the administrators recycle bin.

It is also good to plan the limit size of recycle bins and to have a policy for when, if ever, they are emptied separate from the defined purge period. Ideally, organizations will establish a time period and adhere strictly to this rule because, as we will see in Chapter 8, following your own policies is critical for remaining compliant.

Document

We have established security to the repository, so now it’s time to consider what a user can and cannot do with the documents that are stored in the repositories.

On a site and library level, you can manage different types of security groups. These groups, separate from those in Active Directory, determine what can be done on a document level. For example, you can decide which users can edit documents and which users can only read documents. These settings should not be viewed as tools for producing content; rather, this is the security that happens on the repository. They should be viewed as a way to protect the content of documents from unfortunate editing by the wrong people.

You will find many approaches and views on this. Unfortunately, most organizations mimic security levels in their active directory. This is OK, but it usually results in too many groups to manage. Then there is the approach to consider just the types of activities that can happen to a document. For example, a user could perform any one of the following activities:

• Design a document Provide the ability to view, create, delete, approve, edit, and customize.

• Edit a document Make modifications to existing documents and delete them.

• Contribute to a document View, create, update, and delete existing and new documents.

• Read a document View and download existing documents.

• View only This is similar to read, but you cannot download.

• Moderate a document View, add, update, and delete items.

There are a few special actions that are reserved for custom solutions and web services that we are not covering in this book. All of these options distill to the ability to create, delete, modify, read, download, approve, and customize.

Because we have isolated document-level security as a way to protect the content of documents, we have included a decision tree in Figure 3-3 to illustrate a process of defining document-level security.

Even between experts, this approach can be quite controversial. The reason for such a radical approach is to maintain the ease of administration that SharePoint needs to have so as to ensure that the platform is adopted and extended. We believe that most organizations will have the requirement for the minimum level content security groups, which are Full Control and Read-Only.

Document management

Also at the content protection level are the check in/out functions and the versioning functions. Checking out a document is a very important yet simple tool in ECM that ensures that as a document is being edited by a user, the editing process is not impacted by another user who views the document.

If you use default settings in SharePoint, it is up to the user to check out documents and to make sure to check them back in, at which point they should also add comments. Because it’s at the user’s discretion, you will find that when they own the content, they will tend to use this feature, because all users are sensitive to the additional work that could be created if someone else saves a version while they are editing. However, it’s not guaranteed, so we recommend that you enforce that whenever a document is being edited, it is automatically checked out. As shown in Figure 3-4, you can do this on a library level in library settings and by selecting versioning settings. You can select Yes for the option Require Documents To Be Checked Out Before They Can Be Edited?

A side effect of this important feature is users forgetting to check documents back in. This should first be addressed with training, and eventually there will be enough social disruption around popular documents that users will make it a habit. Administrators do have the ability to force checked-in documents. We have even seen some unique customizations that run on a daily basis to find checked-out items and remind users to check them back in via email. This is another people and technology problem that is better to address with people first.

While in the versioning settings, we have something else to look at here. The next important consideration in protecting content, and a very common ECM feature is versioning. There are two types of versions, as we noted in earlier chapters. The first type is major versions, and the second is minor versions. A major version is everything to the left of the “.”, and a minor version is everything after. For example, if a document has version 3-2, it has major version of three and a minor version of 2. Both sides of the decimal can be essentially infinite. Therefore, version 3-125, the 125th minor version of major version 3 of this document, is possible but not advised.

The first consideration is whether you should use versioning. In our experience, it’s hard to find an ECM scenario where versioning is not a necessary feature. This helps make sure that the activity associated with the edits to a document is well contained and that you can revert to old versions if you need to. We did a study that shows that about 1 in every 20 documents has a need to be reverted back to a previous version. Only if documents are read-only, if you have technical limitations on your content database, or if you are advised by legal counsel (because every version is admissible content and available for eDiscovery) should you consider not using the feature.

When an organization has decided to use versioning, it must consider whether or not to implement minor versions. It’s rare for an organization to have a need for minor versions unless they have implemented publishing. Publishing is the process of taking major versions of content and publishing them to other users in the same site or to intranet/extranet sites. This allows major version of documents to be published while the creator of the document can continually modify working versions. In most cases, organizations need only major versions. Unless you have strong documented reasons for doing otherwise, we recommend sticking with major versions only.

The final item to consider for content security is draft item security. It is possible to limit which users or groups can see draft versions of documents. In ECM, we feel that any setting other than “Any User who can read items” is dangerous. Does your organization use drafts and, if so, why? We find that most organizations, unless utilizing publishing features in SharePoint, don’t need to use the draft feature in most cases. If you are utilizing drafts, because this is such a subtle feature, it’s very difficult to document whether or not there is a special security consideration. As a result, if multiple editors are collaborating on a document, with some having draft privileges and others without, the problem of lost content will not be easily identified. It might be necessary at times for people without proper edit security to know about the existence of draft content. For these reasons, we recommend that, when using drafts, you should allow everyone to see the draft versions that exist.

We have outlined all the considerations for managing document repository security, ensuring integrity of the content, and special considerations as it relates to working with content in ECM. Now that your users have captured the content, your ECM solution is managing it because of the IA the ECM team put in place, and the users are putting the content to use. In the next section, we will explore the best practices associated with productive use of content.