How to turn a failing SharePoint project around

Microsoft SharePoint is often sold on its features. Companies recognise that they can use the platform for document management, for example, or to develop a self-service intranet, so they buy in. After all, they say to themselves themselves, isn’t this what everyone needs nowadays?

Then, a few months down the line, it dawns on them that they’ve made a mistake – they’ve lumbered themselves with a clumsy, unmanageable system that nobody wants to use and nobody wants to take responsibility for. The costs are piling up and SharePoint hasn’t brought any of the benefits to the table that it promised.

Sounds familiar? Regardless of vertical and intended use, SharePoint projects often fail. This could be for any number of reasons, depending on the perspective of the end user. A manager might complain about low rates of user adoption, while other workers might feel they can never find what they’re looking for – the process of uploading a document is like flinging it into the void, never to be found again.

Despite the wide range of factors that might be implicated in failing SharePoint projects, however, turning them around is often a matter of following the same simple rules. Central to this is the fact that SharePoint is often purchased without a specific purpose in mind – it’s bought in as a solution without a preexisting problem, which always spells trouble. Getting a project back on track, therefore, is a question of working out what those business goals are – or what they ought to be – and then translating them into a functional, user-friendly SharePoint experience.

So, how exactly does a company go about this? In the following five steps, we’ll discuss what turning a failing SharePoint project around actually involves, as well as the potential pitfalls you might encounter along the way.

Step 1: know your users’ needs

The first step a company should take when it sets up a new SharePoint site – or in this case, goes about getting a failed project back on track – is to take stock of what its users require. And no, this isn’t a case of consulting a select group of senior managers – you need to talk to everybody, discover what they want and work out how best this can be accomplished.

Every single person who uses a SharePoint site is a key stakeholder. Companies that post low adoption rates have almost always failed to identify what end users are actually lacking, so they haven’t thought about how SharePoint’s features can be leveraged to provide concrete, unambiguous solutions.

Step 2: transfer ownership to business

Developing and deploying an effective SharePoint site takes technical skills, so organisations typically put the implementation process in the hands of IT. There’s no problem with this in itself, but we need to remember that SharePoint is a platform that provides specific, self-service business solutions – it’s not a toy box for the IT department. Consequently, if a company asks technical staff to manage the project through its complete lifecycle, it’s making a major error.

Much as many failed SharePoint projects are undertaken without capturing users’ needs, many others struggle because they’re managed by IT departments that don’t really understand what problems they’re trying to solve. In reality, no SharePoint site should be centrally managed at all – it might serve the needs of several business units, so why shouldn’t each be empowered to have a say in how it delivers value?

Step 3: Revise your governance plan

Of course, if we’re empowering end users to make the most of SharePoint’s self-service nature, it’s non-negotiable that we put policies in place that prevent misuse and even abuse. We can’t assume that everybody using the platform is an IT expert or information architecture specialist, so we need a comprehensive governance plan to ensure everybody understands what they can and can’t do.

Without governance, SharePoint sites grow out of control very quickly. And if they’re used to store and process sensitive data, this can be a security risk as well as an obstacle for productivity. You can’t, after all, call your implementation successful if it represents a challenge to regulatory compliance, or a data breach waiting to happen.

Step 4: Align SharePoint with a wider business strategy

It’s fine to define your SharePoint site’s goals in terms of discrete business benefits like improving communication and collaboration, or providing connectivity for workers in geographically separated offices. But this isn’t the same as a core vision that all your stakeholders can rally to.

However many workers it makes happy, a SharePoint project can’t be called successful unless it’s aligned with a wider business strategy. Does it boost the company’s bottom line? Could it replace legacy systems? And will it still be relevant in five years’ time when we’re doing something completely different?

Step 5: Measure success

Finally, as per the above, a tell-tale sign of a failing SharePoint project is the inability of its stakeholders to quantify what they’ve gained from it. SharePoint has countless uses and as such, measures of success vary across organisations and verticals, but they’re always important. Is the site delivering value through process improvements? Has it freed up departments like IT and HR to work on other projects? Is frequent downtime having a negative impact on productivity?

We previously discussed the importance of capturing users’ needs and translating them into solutions that SharePoint can provide. To determine if this accomplishes anything, we have to set parameters to measure success. We could choose to look at engagement figures, or if a certain process is sped up, or whether the site has contributed to cost savings.

If you can’t measure success, you might not even know when a SharePoint project is failing!