SharePoint Productivity: 3 Best Practices for Supporting SharePoint

After your SharePoint implementation is up and running, users start to discover its capabilities and to demand solutions to business problems. How do you help users solve business problems with SharePoint?

This week, I’d like to share with you what I consider to be the three pillars of SharePoint productivity—of delivering business solutions on SharePoint: self-help, escalation, and community.

In the context of this discussion, a “solution” means just that—a solution to a problem—which is not necessarily equal to a SharePoint solution—custom code packaged up for consumption.

In fact, many solutions can be built with no code, using browser-configured functionality of lists, libraries, and content types, along with SharePoint Designer, InfoPath, Access, Excel, and other Office client applications.

Recently, I’ve been working closely with several clients who have built successful governance and support for business solutions. There are three commonalities—three “best practices”—that create a trifecta for success. This week I’ll talk about these three pillars of productivity.

Before I do, let me shout out to those of you in Europe! I’ll be visiting next week with workshops and events in Scotland, Netherlands and Belgium—see last week’s column for details. And to those of you “down under,” I’ll be presenting a keynote and sessions at the SharePoint Conference on the 20th and 21st of March! Looking forward to returning to Australia which—strangely enough—is faster for me to get to than the east coast of the USA!

Now—about those “three pillars!”

Self-Help

Much of SharePoint’s powerful functionality is easily accessible to end users through the browser-based UI, SharePoint Designer, InfoPath and Office clients. Just because it’s easily accessible does not, unfortunately, mean that it’s easy to figure out how to build a specific solution—such as a form or a workflow to support a business process.

Even fundamental components—lists, libraries, content types, and metadata (columns)—are not necessarily straightforward to end users, particularly as they are focused on addressing a yet-unsolved business problem with SharePoint.

I am not a fan of the following statement: “We sent our users to a five-day course on SharePoint.”

Those of you who know my history will know that I’m a trainer, at my core. So for me to say, “Do NOT train users to use SharePoint” may seem surprising.

I do believe that users need various levels of training on SharePoint—at least a fundamental understanding of some of the core components and concepts. But my experience is that it is not effective—or at least not efficient—to teach a new user “everything they need to know” about things like workflows and forms and the inner workings of SharePoint because, simply, it’s too much.

What’s more important, in my opinion, is that users see the potential of SharePoint as a business problem solver, and that they know where to go for help.

When a user needs to create a solution—a form with a workflow for example—they only need to know the steps for doing so with InfoPath and SharePoint Designer for a couple of minutes or an hour. It’s at that moment that you must have resources ready to help the user succeed in helping themselves.

Google and Bing are not the best answer. There’s a tsunami of information, much of which is irrelevant to your specific business, poorly written, or inaccurate.

Point users to specific resources, including the Microsoft Office website and to other selected resources that you find accurate, helpful, and relevant.

I also recommend two specific sets of resources as an internal training and knowledge base. Fellow MVP Asif Rehmani’s SharePoint Videos  provides hundreds of short video clips that are excellent at providing just-in-time guidance to specific SharePoint tasks, including and importantly SharePoint Designer and InfoPath. Another MVP, Rob Bogue, offers the SharePoint Shepherd resources which tend to be more “text-and-picture” (versus video) based, and which cover many of the core concepts and functionality.

Community

Your users are the best sources of knowledge about how to use SharePoint in your environment, to solve your problems. You are missing out on a golden opportunity if you don’t capture this resource from Day 1.

Create a discussion forum about SharePoint usage. Keep it focused on usage—have a separate forum for technical support. Spotlight your internal evangelists and success stories.

A build a library of solutions. Again I mean this in the broadest sense.

Find a way to collect the knowledge that your users build about using SharePoint in your environment. A wiki and a library where they can drop documentation about “How I built X” is a start. Create a gallery where templates and other solutions can be found.

Escalation

Above all, there needs to be someone—or a team of people—to whom SharePoint usage questions can be addressed.

Someone who really knows how to use SharePoint and the tools listed earlier—or at least someone who is capable of “figuring it out” on demand.

Ideally, this person is highly skilled with no-code development (browser, SPD, InfoPath and Office) and has a knack for business analysis—for eliciting real requirements.

Even more ideally, this person or team can drive the development of self-help resources and community, so that as your SharePoint implementation scales, you do not need to scale the escalation resource, but rather escalation needs start being filled by self-help and community.

Most ideally, the escalation resource ends up putting themselves out of business by effectively integrating their knowledge and experience into evolving self-help and community resources.

At several clients' locations, I’ve worked with the person in this role. Honestly, these people tend to be among the most vibrant and exciting people I work with.

They’re expert, enthusiastic, and deeply aware that SharePoint doesn’t really matter—the business matters. And that focus on business first means that business problems do get solved.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish