We’re web workers and for the most part, we’re comfortable with technology. We’re not as put off as the typical user is by having yet another login username and password, or a new line of icons in our toolbars. Bring it on, we say, we like to play with what’s new and interesting on the internets. It’s all about increasing our productivity, and we’re usually not afraid of trying something new in the process.
If you work with a team of folks who have the same attitude, that’s wonderful. Chances are, you work in web development. But what happens when you work with a team, who while comfortable with email and web surfing, wouldn’t know their ActiveCollab from their Zimbra? Collaborative software that you use alone is a bit like clapping with one hand.
You have a Basecamp account, but your team members still insist on emailing you directly instead of going through the site. You have all your files on OmniDrive, but you can’t find that important spreadsheet because Mary still has it on her computer and she’s on vacation. You use a tool that publishes a RSS feed of changes, but your colleagues still email you constantly asking for updates. Your users love reading Wikipedia, but are themselves resistant to using a wiki to collaborate on projects.
It can get frustrating when colleagues fall back on old habits that are not potentially as time- and cost-effective as the new tools that the social web can bring to the table. How do you convince your co-workers or clients to not only try a change in their work process, but stick with it after the novelty has worn off? Do we have to become scholars in change management just to get people to update a wiki?
Last year, Suw Charman outlined some user adoption strategies that may have some relevance.
There are two ways to go about encouraging adoption of social software: fostering grassroots behaviours which develop organically from the bottom-up; or via top-down instruction. In general, the former is more desirable, as it will become self-sustaining over time – people become convinced of the tools’ usefulness, demonstrate that to colleagues, and help develop usage in an ad hoc, social way in line with their actual needs.
Top-down instruction may seem more appropriate in some environments, but may not be effective in the long-term as if the team leader stops actively making subordinates use the software, they may naturally give up if they have not become convinced of its usefulness. Bottom-up adoption taps into social incentives for contribution and fosters a culture of working openly that has greater strategic benefits. Inevitably in a successful deployment, top-down and bottom-up align themselves in what Ross Mayfield calls ‘middlespace’.
While aimed at the enterprise, Charman goes on to outline concrete tips that are also applicable to smaller teams and are worth a read.
Some simple tips that I’ve found effective in remotely encouraging user adoption of social/collaborative tools:
Understand your team’s work habits. Do they already use Instant Messenger clients? Do they use Firefox or Opera, or are they still using Internet Explorer with the default home page? Do they already use other tools that may conflict either by process or design with the tool you want to introduce? If they use Outlook, have they customized it to their liking? I know my co-workers well so I know how off-the-beaten-trail I can go. I know that everyone on my team is very comfortable with content that is emailed to them, so collaboration tools that are email-centered are more successful. It is easier to get someone to send an email to an address to post content to a collaborative site than it is to get them to remember to visit that site on a regular basis. It may be very different for the people you work with and you have to tailor your expectations accordingly.
Deploy slowly. Resist the temptation to tell everyone about something that is so cool they have to start using it immediately. After a period of testing a collaborative tool on my own (using dummy email accounts), I share it with one colleague that I feel would not only benefit from its use but is also willing to help me test out the best processes for our group. Then I slowly introduce the concept to others, documenting the questions and concerns carefully as I build the support documents for our team. It took months, but now most of our team instinctually loads Salesforce in their browser to assign tasks to others or to check calendar availability. It didn’t happen overnight. Don’t change for the sake of change. Make sure the tool truly adds value.
Ask the tough questions. Technologies come and go. Don’t be lured by pretty design with AJAX navigation. Do your research. Send email to tech support. See how fast they answer and if the answer is satisfactory. Make sure any data you put in can be pulled back out easily. You don’t want to encourage your team to adopt an application only to have it go south.
Be prepared to offer user training. Don’t rely solely on the help files provided by the tool. Don’t assume that because you picked it up quickly and you read the developer’s blog or forum that everyone else will. You have to be willing to put the time in to do some hand-holding. You want to show your team how they can use the tool to answer your specific business need. As tempting as it may be to show off all the cool things that can be done with the application, limit your demo time to just what it is needed for your business. It is better that your colleagues use the tool consistently (read: by habit) to collaborate on one small project, than they know everything that is possible in the first lesson. Once the tool is ingrained, they’ll explore other uses on their own.
I’ve found that a combination of on- and off-line training tailored to individual need works best. Start by using web conferencing software to host a live demo of the application, where your co-workers/team can see you working through a specific process unique to your business. Prepare tutorial documents with step-by-step instructions, including screenshots, using your own projects and settings. Try to anticipate where the challenges will be. It isn’t about getting your colleagues to buy into the application. You are not selling the technology. You are persuading your co-workers to adopt a new process that can increase overall productivity and project success. This is the make-or-break point. Keep it simple and be patient. It takes time to become habit.
Be consistent. If you want your team to adopt a wiki for project management, then don’t send a lot of content through email. Write it to the wiki and send colleagues a link. Gently remind your colleagues to do the same. You have to set the example.
Look for tools that will be easier to adopt. It’s half the battle. If an application requires a complicated registration process, only works with a single browser or has no email functionality then the chances that a less-technical team will adopt it drops dramatically. Look for tools that work with applications your team already uses so they won’t have to manage yet another login. Many collaboration tools are designed for enterprise or small businesses where management can dictate a common denominator or enforce adoption. Web workers aren’t often that lucky. We have to adapt to situations and users we can’t always control. Don’t look at tools with web savvy eyes or based solely on your own work process. Imagine that you are a team member who is using their computer right out of the box. Try to anticipate barriers and workarounds.
What has/has not worked for you? Have you tried a great web application only to abandon it because you couldn’t get others to adopt it into their own workflow? Why do you think organizations have been slower to adopt wikis and RSS for collaboration as compared to other new technologies?