If You Build It: Working Toward User Adoption of SharePoint

Summary: SharePoint user adoption doesn’t just happen; below is a list of actions you can take to ensure user adoption and a successful SharePoint implementation.

Long ago in graduate school I took a few courses in the application of systems theory to social organizations. This was before I changed career paths. The only programs I had written at the time were in FORTRAN for the physics courses I taught. I found the topic of systems theory fascinating. What I found more interesting, however, was one professor’s attempts to tie systems theory to the experiences he had in designing and implementing social intervention programs.

He, along with numerous others, was very instrumental in introducing large-scale vaccination programs in dense urban and remote rural areas of the United States during the 1930s and 1940s. I can still recall him recounting his utter surprise at the failure to achieve the targeted vaccination rates. Despite the extensive planning and forethought and all the efficiencies and feedback loops that he and his fellow workers designed into the system, they fell far short of expectations. Yet it wasn’t just the system that this professor was analyzing; it was the human element.

Today, many of us are very familiar with the basics of systems theory whether applied to social organizations or not; the field is over 60 years old. We might not be consciously aware that we are working with those principles but we incorporate them into what we do, how we think and how we plan—on an almost daily basis.

So what does all this have to do with SharePoint? Well, SharePoint user adoption is all about the human element. It ought to be one of your chief concerns if you are about to implement or have just begun implementing SharePoint. If you implemented it some time ago and you didn’t consider this, it’s not too late to do so, but you might find yourself nodding knowingly in assent as you read this.

Why should you be concerned about user adoption?

Nothing holds the key to a successful implementation of SharePoint and a realization of the ROI you calculated more than user adoption. That’s a fact. All the capacity planning, the well choreographed migration, the exquisite workflows, the elegant information architecture, all will mean nothing if user adoption fails or even falls short of its critical mass.

"We aren’t seeing the adoption we want; how can we improve it?" is a question that, surprisingly, I hear more often than I should. At least more often than I think I should. Don’t misunderstand; there are many organizations that have done a very thorough job of thinking about and planning for maximizing user adoption.

That’s the point.

Organizations that have seen very successful SharePoint implementations have planned and developed strategies that encourage user adoption. Those who have followed the "If you build it, they will come," approach, however, have been disappointed. Why? Are there barriers to broad user adoption of SharePoint? Well, in a sense yes, but they are easily overcome if planned for appropriately.

Think about the business reasons behind your implementation of SharePoint. There are many, many possibilities but boiled down, they more than likely include increasing efficiencies in the human-based processes and activities that comprise the work that is accomplished in your organization every day.

What do you know about people and about SharePoint that could impede adoption on the scale and with the rapidity that would indicate success? Here are a few items that come immediately to mind.

• People don’t like change. SharePoint is all about change – it’s a new way to work. It really is!
• People don’t like uniformity. SharePoint provides a structured way and "place" to work.
• People don’t necessarily like to share their work. What’s the name of the product here?

Of course these are general statements that do not apply to any given individual but we are talking about your organization as a whole.

Let’s pick just one of these points and explore it a bit. People don’t like uniformity. Consider this for a moment. How many different types of pens are used in your company? I bet it’s not one. I bet there are at least five or six. Some people could not care less about the type of pen they use but others have to use a particular type. If pens don’t do it for you, then consider pencils, or notepads or screen-savers, or the mouse you use or the keyboard. (For me personally it’s the power adapter I use with my notebook computer.) Now imagine that for efficiency’s sake a new approach is taken and there’s only one type of each of these available; only one type of pen, pencil, notepad, etc. The law of large numbers is against you here. It’s likely that there will be people who will not like the selected pen or the pencil or the whatever. Result? They will find ways to get what they need and they will avoid adopting the new pen, etc.

If people will do this for pens, imagine how they’ll act with a new system in which they are supposed to spend the better portion of a day working!

Are there characteristics that suggest people would be drawn to SharePoint? Definitely. Here are a few.

• People are inventive.
• People like to solve problems.
• People like to be recognized for their contributions.

How do you mitigate the potential barriers and leverage the human factors that are conducive to adoption? There are many ways and many approaches. Actions you can take to help you effectively mitigate those barriers and encourage adoption follow. These are critical steps you should take and many of them leverage SharePoint’s extensive capabilities.

Recognize that SharePoint is an application platform and a system of applications not a simple, single web application.

Many, if not most, web-based applications in use today are single focused. Time and expense reporting, benefits management, payroll, sales, and order processing are some examples. Even "integrated" web applications are often simply menus of hyperlinks to independent pages and their associated code. SharePoint, however, can easily be looked at as a set of inter-related applications. Its web-based user interface is deceptively simple and as a result it’s easy to miss the true integration it provides. If you look at SharePoint as an application system and platform, and if you convey that to the rest of your organization (in non-technical terms of course), people will be inclined to use it as such and to look for ways to exploit that integration.

Understand that SharePoint provides a reconfigurable structure that should evolve and adapt as needed and those closest to the work often know the needs before anyone else.

The IT Leader's Guide to Multicloud Readiness

This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.

Download the Guide

I’m going to get some disagreement on this but if you don’t allow users to create their own sites, you have closed the window on a primary benefit of SharePoint. I’m not advocating that everyone in the organization have the ability to create new sites, but keeping that in the province of the IT group isn’t the correct alternative. An organization I know of created a paper form and a manual workflow that were used to request new SharePoint sites. The form collected all the information that the IT department needed to create a site. Since IT didn’t know if the site was justified or not the workflow required business manager approval, once approved IT created the site and filed the form. The average request took a few days to process (anyone surprised?) and before long there weren’t many requests for new sites. Instead new lists and libraries were created in the existing sites (people are inventive). These eventually became disorganized collections of unrelated items, however, and difficult to use. Performance started to drop in some sites where the number of items in lists started to approach 5000; well beyond best practices.

If you step back and take a look at the whole process, there is no fundamental difference between what was implemented and, as a better approach, simply allowing one or two key people in each department to create new sites when necessary; not much difference at all except perhaps having confidence in those key people.

If you’re worried about ending up a few years down the road with the same problems you have today in your file shares, plan and configure the settings built into SharePoint that help you avoid this. There are many! Don’t hamstring your information workers and definitely don’t create a paper-based site creation process!

Recognize that SharePoint provides the group equivalent of the windows desktop – and not everyone works the same way (remember the pen?). Employees need to be able to organize their workspace according to their preferred ways of working.

Don’t remove the Personal Permissions from the default permission set given to the Members group. Stated a different way, make sure that all permanent employees have Personal Permissions assigned to them. These permissions provide the ability to perform the actions summarized in the table below. With these permissions each employee can arrange and even add web parts and customize list and library views to meet their preferred working styles and needs.

Targeted web parts are powerful but focus on groups of people not individuals. Make sure your employees know how to perform the actions associated with these permissions and encourage them to create their "own space". (This is completely different from the My Site feature.)

If you are wondering what will happen to the pages your implementation team spent so much time designing if employees can customize pages, recall that their abilities to customize shared web parts is limited. They can’t delete them at all and only settings in the Appearance and Layout groups are available.

What is likely to happen though is that given the ability to create personal views of pages and personal views of lists and libraries, they will use SharePoint more and therefore be exposed to the content your team included as well as find ways to use SharePoint you never even considered (people are inventive).

While you are making sure these permissions are assigned to your SharePoint users, make your support group’s job a little easier by disabling the Close option for all web parts. In my opinion this should be disabled by default for every web part since it causes many calls to the help desk but for some reason the default has always been Allow Close beginning with the 2001 version of SharePoint. Along the same lines, for all exposed web parts, disable Allow Hide.

Make Search work well.

SharePoint Search, as it’s configured by default, doesn’t generally supply the kind of results that are extremely useful for your employees. Investing the time to make some very minor configuration changes can make Search a very powerful tool however – employees will actually use SharePoint just to execute searches if you configure it properly.

If you leave the default configurations unmodified however you will likely find few employees using it. If search doesn’t work well or employees don’t use it, how will they locate those documents and list entries they’ve been adding to SharePoint? If they can’t find them, they’ll stop using SharePoint to store them.

You also have to revisit Search. Keep an eye on the Search Usage Reports. If you don’t like them the way they are presented in the SharePoint Shared Services administration pages, take a look at the usage reports in SharePoint Designer.

Include training and job support tools in your implementation plan.

Merely because SharePoint is browser-based with some very slick Microsoft Office integration points doesn’t mean people will intuitively understand how to use it. This is true even for the technical professionals in your organization. I once saw a business analyst, a few weeks after SharePoint had been implemented in his company, saving a file in a document library. He named the file AcctingSpec v2. When I asked him why he added the v2, he replied that the entire department used that method to keep different file versions just like they did in the files share they used to use! I looked in the doclib and there they were: 100 or so files differing in name by only an appended number! When I showed him SharePoint versioning he was amazed – and dismayed. You can guess how the rest of the organization was versioning their documents.

Versioning is not something that users of file shares are accustomed to using. SharePoint is replete with features and capabilities new and unfamiliar to many people. There are so many of these features that you cannot assume people will discover them on their own. Even if you could, how much time would it take for that to happen?

Rapid adoption is your interest here not just rapid implementation. Training takes time, but it’s time that can be highly leveraged. Include it in your implementation plan and make refresher and advanced sessions available after implementation too.

Quick Reference Cards (QRCs) are great except they can’t usually be found when they are needed. Remember those "QRCs" that fit around the keys on keyboards? They were clever attempts to make sure the QRC was always available; tough to read the 2 point print though!

What could you use as a QRC for your SharePoint implementation? What about SharePoint itself? If you add a Help URL in the Advanced configuration properties of a web part the web part’s dropdown menu will display a Help item (Figure 1) that displays the link in a new window. A site dedicated to providing the functions of a QRC can be linked to from any web part.

Figure 1

Help site owners collaborate.

If you actually allow business unit information workers to have full control over the sites and possibly site collections they use (highly recommended), you ought to create a site just for them. They need to collaborate among themselves. What are they collaborating (laboring together) on; why do they need to work together? SharePoint of course!

Face it you and your staff won’t have time to help everyone in the owners groups with the interesting questions they are going to be generating, not if your implementation and user adoption are truly successful. Your staff might really want to help with these questions, questions like "How can I setup my list so that items of a particular type show x and y attributes but items of a different type show a and b attributes?" They are so much more interesting than "I closed Upcoming Events on my departmental page. How can I see it again?", but they just aren’t going to be able to do so.

Site owners should be able to help each other, to share their ideas easily, to use and build on the ideas of other site owners. They need to do this if novel and useful techniques, and so on will be available to the entire organization not just, say, the accounting department. This will happen if you encourage site owners to collaborate. Your first step should be providing them with their own site. This has worked very well for many organizations.

Remember that SharePoint means change

If you talk with just a few organizations about their intranets, you’ll find a pattern very quickly. Many, if not most, have become seldom-used. In part that is because they have become stagnant. The content is stale. Sometimes you’ll find that intranet content has not been updated for years – literally, yes literally. There are many reasons for this common condition. The relevance to this discussion is that your SharePoint environment must change and adapt to the changing business conditions and requirements that your organization confronts.

Earlier I pointed out the need to allow SharePoint users to control their SharePoint environment. That get’s you part of the way toward changing as needed. Getting the rest of the way though falls squarely on your shoulders, assuming you are responsible in some way for ongoing SharePoint use. Your responsibility is to look for ways to use SharePoint to support strategic and tactical objectives of your organization. This means, most probably, implementing SharePoint capabilities that were not implemented when SharePoint was initially put into production. It also means looking at how groups in your organization are or are not using SharePoint and getting all six SharePoint business functions used throughout the organization. (See this blog for thoughts about how do that: )

Did your company recently acquire another company? A SharePoint extranet can provide a common collaboration environment almost overnight. Has your external auditor identified items that have not been treated properly as company records? The document and records management capabilities of SharePoint’s Enterprise Content Management feature set can address this potential issue. You get the idea.

How does this help with user adoption? Total user adoption will have occurred when your employees ask "How can we use SharePoint to help us with this?" whenever they confront a new problem or requirement. That will only happen if they see SharePoint being used extensively. The more it’s used, the more ways people will find to use it (people are inventive).

This brings me to my final point. I could go on and list a number of other actions you should take to help ensure user adoption of SharePoint, but I have to save something for a future blog, and you’ve been reading for a while, so I think it’s best to end on this point:

Think infection: achieving user adoption is not an overnight event – it’s going to take a while.

This means you must continuously take the actions presented here. You can’t simply take them once, declare them complete like tasks on a Gantt chart and move on. You have to be the SharePoint champion, infect others so they can become SharePoint champions and in turn infect still others. Iterate to n where n=employee count+1.