What's the Biggest Challenge You Face with SharePoint?

I recently had a conversation with someone that went something like this:

Him: "So what do you do then?"

Me: "I'm a Knowledge Management Consultant.  I'm currently helping a client implement SharePoint."

Him: "Oh, that's interesting.  We've just started using SharePoint and we're struggling with getting the right branding and styling on our publishing site.  Any tips you can give me on working with their CSS?"

Me: "Not really, I tend to work on the content management and collaboration parts, rather than the publishing side of it. But the Microsoft help material is very good and I can point you...."

Him [interrupting]: "What do you mean, you don't do publishing sites? I thought you said you were a consultant?"

Me: "I am, but SharePoint is..."

Him: "So you don't know what you're talking about then?"

The conversation went downhill from there, as my interlocutor almost, but not quite, accused me of lying about what I did and got increasingly irate and frustrated. In the end we parted company with him still muttering and me shaking my head ruefully.

Now you might instinctively think bad thoughts about my ill-tempered friend, but that would be a knee-jerk reaction.  He was clearly struggling with a complicated and powerful piece of software, and meeting someone who might be able to bring some light to the shadows must have gotten his hopes up, hopes which I promptly dashed.  It's only natural that he was frustrated, even if he didn't necessarily express that in the most constructive way.  What's more instructive about this encounter is that it represented a microcosm of the way an entire enterprise often feels about implementing SharePoint.

If you've encountered SharePoint before then the likelihood is that your experience hasn't been overwhelmingly good.  I've met more far more people with negative things to say about SharePoint than I have people with positive things.  It's like the England football team - depressing, confusing, poorly performing, promising lots and delivering little.  But like the England football team, SharePoint's individual components are good, yet the sum seems to be less than the whole of its parts.  To continue this analogy one stage further, the management just doesn't seem able to turn a collection of good things into a better coherent whole.

The question is: Why not?

Let's start an answer to that with the obvious point that SharePoint is large and complicated.  If you have SharePoint then you're going have Microsoft Office, which increases both the size and the complexity by a significant factor.  Office itself can be pretty difficult to get to grips with as a whole, when you've got both client and online versions, as well as lots of tools that weren't in the traditional Office package of a few years ago, like Sway, Planner and Video.  Then there's OneDrive, which is actually just a personal SharePoint site with a front-end, and Power Apps, Flow and Delve.  The sheer number of these apps is dizzying, and they all work together if you want them to, and each one is a whole book and training session on their own just to get comfortable with the basics.  Even programs as venerable and well-know as Word, PowerPoint, Excel and Outlook have lots of functionality that most users never know about or haven't got to grips with.  Then you add a powerful electronic document and records management system like SharePoint on top of all that and dear Lord, where on Earth do you even begin?

This alone is enough to put a lot of people off, and not just users.  Designing, implementing, training and supporting that kind of enterprise-level suite of applications, with its mind-boggling array of options, parameters and functionality, is not a job for the faint-hearted or workshy.  For users it can be even more daunting because they're not supposed to be the experts and usually have very little time to dedicate to learning these tools.

The biggest part of this problem is that often the people deciding to use SharePoint underestimate the investment of time and resources needed to design, implement and support it, and they seriously underestimate the investment of time and resources needed to train users. Many a C-level decision-maker has seen a demonstration, or worked in another company with a successful SharePoint implementation, or seen that it's a highly-recommended tool by a relevant professional body.  These are all valid reasons (although not sufficient on their own) for choosing SharePoint, but they're not valid reasons for thinking that SharePoint is easy, simple or quick to implement and maintain.  If you've seen SharePoint working well then you can't even begin to imagine how much work has gone into making that happen.

It's worth saying as well that when users struggle with SharePoint it's not always because it hasn't been implemented well.  SharePoint is so large that you can't even hire a consultant direct from Microsoft that knows all of it to a significant degree.  It's also not the most intuitive experience, which makes learning it harder.  Training users is always easier when an application has obvious signposts and markers for the users, because once they've got a rough idea of how things work they can generally find their way around and work out how to do things using these signposts and markers.  But there are plenty of areas in SharePoint where these signposts and markers are missing, often because a certain feature or parameter is "owned" by one application within SharePoint/O365, so you can only get to it from that application.  This means a lot more rote learning is required to know how to do things.  On an application as large and complicated as SharePoint this means that the learning curve is high, which acts as a significant barrier to adoption across a business. 

When you take these problems together - the size, the complexity, the difficulty learning it - it becomes easier to understand why my frustrated friend felt like he was banging his head against a brick wall.  He's most likely up against a deadline, he's faced with a suite of applications that is so large it's very difficult to know where to start, and when he does start the amount of learning to be done must feel insurmountable.

All of which leads to the reason that many companies struggle to have a successful implementation of SharePoint: It's not a one-off implementation, it's an ongoing process of training, learning and incremental advances for the entire life of the application.  

Every user needs to be trained, and not just with a 60 minute introductory session.  Every new starter has to be trained.  Existing staff have to have access to refresher training.  Training material needs to be updated as new functionality is released.  Content and working practises have to be analysed so they can be successfully migrated.  Deletion, retention and preservation policies must be decided and implemented from the very start.  Metadata must be applied to migrated content and added to all new content.  Workflows must be designed, created and added.  Security must be applied.  And throughout all this you have to deal with the change management aspects by engaging the users, communicating the plans and timelines, quelling fears, and listening to concerns.  If you can do all this, and still meet your success criteria then you'll have a successful implementation.

SharePoint is not an application, it's a long-term commitment of people and time.



(Note: A cardinal rule on this blog is that I never discuss current or previous clients.  Nothing from this post should be inferred about any company I've worked for; as always this is a general discussion about issues that we find in our industry.)