The bad news is that if you’re having trouble getting people to use an existing SharePoint platform then it’s already too late to do most of the things it usually takes to make your implementation successful. There’s only so much you can do once the system is in place to encourage people to use it in all the ways you planned for them to. This is because a good portion of what you need to do to get your employees on board after the solution has been deployed involves the process that goes into planning the implementation. And this gets at the most important thing everyone needs to understand about SharePoint: it was never meant to be a software tool you simply set up and hand over to employees.
Instead, to be effective, or even to be used, your SharePoint implementation must take into account what those employees are actually going to be doing with the platform. And that means you have to start by finding out what challenges each type of employee is facing that the platform may potentially help them address. As SharePoint Architect Scott Walsh explains, “If you listed all the tools it could potentially give you access to, you could easily fill about 500 pages.” Imagine looking for a single passage in a 500-page book and you get an idea of why many users find the platform so frustrating. So the task for any business planning an implementation is to choose from this vast array of tools the ones that should be readily available to each type of user.
So how do you plan an implementation in a way that encourages user adoption post-deployment?
The trap C-levels tend to fall into is thinking of the intranet and collaboration platform as a tool for corralling employees into a single shared space. And, since everyone is going to be looking at the same dashboard and navigating to the same pages, these management types see it as an opportunity to broadcast their directives and enforce adherence to the their preferred business processes. The result: users sign in and see a bunch of irrelevant information before having to proceed through a bunch of needless and needlessly complicated steps to do things they know are much simpler to do with other tools. So they stop signing in.
Then there’s the trap IT people often fall into—or rather push everyone else into. Tech people look at the platform and see all these cool features and tools. And they assume everyone else will be just as excited as they are. So, if IT staff is in charge of the implementation, you’ll likely end up with all kinds of slick applications that no one uses because they have little bearing on the daily challenges most of your employees face. And, even if the tools the implementation makes available really would help workers perform important tasks, they may still never get around to using them simply because they don’t know these tools even exist. Or they may not know how to use them.
Whether it’s managers driving the implementation or techies, the general problem is commonly known as the “If you build it, they will come” misconception. The reality is that unless the platform you set up makes users’ lives easier, they won’t keep coming back to it.
SharePoint planning isn’t about deciding what you want everyone to see and what you want everyone to do. And it’s not about just throwing a bunch of neat tools together so everyone can play around and figure out which ones are most useful. But involving users in the process is about more than effective design and custom functionality; getting user input and keeping users informed about the goals and progress of the project have a psychological impact as well as a practical one. It’s important that your employees feel like the tools are being set up for their benefit, not just as some new set of commands handed down from on high.
So what does involving users look like exactly?
SharePoint is a tool for making a worker’s daily tasks easier. So planning begins with a discovery process that explores what each type of worker’s challenges are. You don’t have to include every last employee in the planning sessions, but you should include a representative of each user type.
The platform shouldn’t simply be designed by higher-ups and then imposed on users. It should be designed with users in mind. This means getting input from end-users and creating use cases, hypothetical scenarios for how the tools will be used in a real work setting, and customizing the implementation around them.
Don’t just create a plan for implementation, disappear for a while, and then one day ask everyone to sign on to the newly launched platform. The solution is being built for them, so make sure everyone knows what the goals are. And keep everyone apprised of the progress along the way. This way, employees will have a sense of shared purpose and feel they have a shared stake in the project’s success.
Once the design and implementation are completed, your next step is deployment. But workers may still feel like the technology is being forced on them unless they have an opportunity to suggest some final changes. No matter how well designed a solution is, once you start using it every day you’re going to notice areas that need a little tweaking. So build opportunities for users to give you feedback into your implementation and deployment plans.
To get everyone on board from the beginning, and to keep them on board through deployment and beyond, you need to get the word out. It’ll be much easier to sell your employees on the project if you’re taking the right approach and making it all about them, but you still have to do some legwork. One internal marketing tactic is to appoint departmental evangelists who inform people about the goals and progress of the project, singing the praises of the platform all the while. You’ll also want to appoint Power Users, representatives from each department who are deeply involved in the project from start to finish, who can help train users and answer their questions.
Finally, it won’t matter if the platform has the potential to make workers’ lives easier if they don’t know how to use it. So every deployment plan needs to incorporate adequate training—and adequate periodic retraining.
Scott Walsh says the reason you hear complaints about SharePoint, whether they’re from users who find it frustrating or from managers who are disappointed that nobody’s using it, is that it’s too often treated as a one-and-done type of project. Some IT people install it and everyone’s expected to use it. “But SharePoint is much more like an ERP system in that it involves all kinds of planning around routine processes, and it requires a lot of encouragement and training.” To get people to use SharePoint, then, and hence to get all the productivity gains you hope to achieve with it, you need to design your implementation so that using it makes their lives easier, and you have to make sure they know using it will make their lives easier.