Why SharePoint Doesn’t Suck

christineSharePointLeave a Comment

I’ll be the first to admit that SharePoint isn’t perfect. SharePoint Online, however, is a total steal and well worth the price, especially in the O365 E3 bundle that comes with Microsoft Office and email service.

Mentioning SharePoint gets an almost cliche reaction most of the time… typically an eye roll, a sigh, the “oh no it’s a Microsoft product” and the “I’ve used it before at _____ and it sucked.”

Well guess what, it’s a tool.

What’s that quote? A weapon is only as good as its wielder? SharePoint is a tool that allows the uninitiated, with a quick Google search, to build really useful things. For example, in 10 minutes you can create any of the following:

  • a basic blog
  • a form
  • a lightweight case management/ticketing system
  • a task list that emails your assignees when they get a task
  • a webpage
  • a survey
  • a collaboration space
  • a wiki
  • a multicolor milestone timeline for your project

… all with the same platform, living in the same environment. The environment is secure, you get 1TB of personal storage. That doesn’t suck. PARTS of SharePoint suck, it’s true – there are some lame legacy features and unexpected quirks, some things are harder than they should be, but by and large it is an amazingly versatile tool; and it’s improving all the time.

How to make SharePoint more lovable:

There’s steps you can take to increase the likelihood that your user-base gets their value out of and maybe even (gasp) likes SharePoint.

  1. Information architecture and navigation planning is important. If your information architecture sucks, nearly everyone will hate SharePoint. Put some thought into it and read some articles before you start, or hire a consultant for advice. It’s WAY easier to start right than to fix it later.
  2. Have easy-to-locate basic instructions and/or training videos available in a prominent location.
  3. Centrally control site creation and permissions. This is a biggie – have 1-2 people who know what they’re doing be the one to create subsites and set up initial permissions. There is no faster way to create a giant mess than letting your site owners create their own subsites.
  4. Keep the total number of sites from growing uncontrolled. This is like good city planning – before creating new sites, ask if a library will do what your user needs.
  5. Keep navigation consistent and the number of site collections minimal.
  6. Plan basic document metadata from the start. Getting people used to using it early on is easier than trying to push it out later. I’m on the fence as far as making metadata columns required… I currently make them optional because people like to use drag-and-drop uploading, and require fields cause problems there (they leave the docs checked out to the user, and 50% of the time they don’t notice). A good starting point for metadata is to have Enterprise Keywords, Target Audience (I create my own with managed metadata that includes department names, and some extra tags like “all staff,” “new hires,” etc, I don’t use the built in “target audiences” column), Document Type, and Document Status.
  7. Make a site template with your metadata libraries (I like to start with one shared library and one department/team-only library), your site features, navigation, and your style customizations. Use it for a while, then go back and improve it based on feedback.

Leave a Reply

Your email address will not be published. Required fields are marked *