Coming off two days at SPTechCon, I'm thinking about what was most valuable, and what I'm going to bring back to my clients and colleagues who weren't able to attend. There was a lot of excellent content, but the answers I heard there differ from the questions I'm hearing when I spend time at an organization that's going through a SharePoint deployment.
The usual suspects in the talk of how to build an oustanding SharePoint implementation, and how to encourage adoption, include the following:
- top-down support
- solid governance
- proper training, support, and resources
- useful, needed, and exciting functionality
- an elegant interface
- local evangelists
All of which are important. But more and more I'm seeing that there's another element that may trump them all: Trust. Even in a company that's doing well with all of the above (and I know some that fit this description), if the trust is broken, it's just as detrimental as missing any of the other critical factors.
When SharePoint comes into an organization, it's a stranger. People are wondering, "What does it do? Why should I take time to get to know it?" Many organizations don't have the ability (or desire) to fully enforce its use, so it can be easy for folks to turn their backs on the newcomer and stick with what they know.
Because of this tendency, it's not just one person's job to create trust through an implementation - it's everyone's job. And the most important person of all may not be the one you expect. Let me break out a few of the roles and how they affect trust, below.
Project Manager / Program Manager / KM Director / IT Applications Manager / Communications Manager
The role of the person who's leading the project within the organization can be different from company to company, but whichever department they belong to, it should be their daily job to make the case for trust. Most often, and totally understandably, this individual's time is consumed by tracking requirements, managing the scope and the schedule, and assuring quality while watching the budget. The end users seem like a distant reality while the project and its team are demanding the focus. But this is the time to make trust a part of the conversation, and to ensure that the solution not only performs to spec, but that users' questions are answered to their satisfaction, and that time is built in for them to start getting a feel for the system before it goes live.
CEO and Senior Leadership Team
These folks should aim to act like a grade school principal when they're walking a new kid into class on his or her first day. The principal would never tell the class that they're bringing in this new kid because it's the vision of the school to accept new students, or because the new kid is going to make everyone's lives better over time, or because the other schools are too outdated and students can't go to them anymore. The principal introduces the new kid and asks everyone in the class to make some time to say hello, and that's it. But in the background, the principal has created the culture and policies to ensure that this happens (think of many schools' emphasis on character-building as part of the curriculum). It's the new kid's responsibility to prove him/herself trustworthy, but he/she is never going to get that chance if the groundwork isn't set for the others to reach out.
The steering committee can establish trust by saying why they selected this product - and this shouldn't be solely because of the cost and an existing licensing agreement. What makes a better case, (and what I tell my clients): this is a product that's been around since 2001. That means it has gone through ten years of development, testing, and iteration. The company that supports it, founded in 1975, is firmly established with a solid financial base, and there's a vast global network of partners that also support it. The high adoption rate of the product worldwide has made a lot of resources available online, and engendered an active user community made up of all types, from first-timer to senior architect. The product improves every year, and the next version is already in development. (All of which I think makes a better case than "We're trying it out because we have an Enterprise agreement with Microsoft, and/or our existing system is broken.")
They know they need to provide dynamic and engaging content - but it's also their job to say, "I use it, you should too!" (And the more trustworthy this individual is within the organization, the more weight these words will have, which is a compelling reason to get the human hubs of your organizational networks up and running first, rather than allocating the work to the newest hires or temporary staff.)
For the creation of trust, this person has arguably the most important role in the new system's adoption and ongoing use. And yet this is the role that frequently isn't even 25% staffed at the time of rollout. Users invariably want to know:
Is the system reliable? (Or is it buggy and slow?)
If I store my stuff in the system rather than on my hard drive, will I be able to access it whenever I need it, wherever I am?
Is my stuff safe? Is it backed up, and if so, how quickly will I be able to get it back if I lose it?
How secure is it really? Can I really put these sensitive financials up there and be sure that nobody can see it who shouldn't?
If you're qualifying these answers in any way, you're not going to be able to establish the trust you need for the system to be successful. That's why it's most important to build for scalability, and to monitor performance and system health and address problems before they occur.
Which brings me to ongoing trust. Most of the article above addresses a first-time implementation, but trust is just as critical two, three, five, and ten years in as it is on the first day. If you've ever experienced a breach of trust by a longtime friend, colleague, spouse, or significant other, you know how detrimental it can be to the relationship, even if you've had years of smooth sailing. With a technology system, there's a lot the administrator can do to be proactive about maintaining the system in good working order, and this is a task that has no end point, because the more the system is used, the more it will need to be scaled-up and maintained.
My closing questions: If you're implementing SharePoint, can you say clearly why your users should trust the new system? And if so, have you said it to them?