5 Steps to Better Collaboration

Smarter Not Harder

campfireEver wonder why some collaboration projects take off and become successful but you can’t get your company’s users to use a simple wiki?  Do your discussion forums in Sharepoint go unused?  You did everything right… didn’t you?  Well, the honest truth is that there is no silver bullet to making something popular, but there are a few strategies you can use to deal with the biggest obstacle you face in collaboration which is User Discomfort.  That’s right, it’s not your processes or your technology, it’s not even your management.  The biggest impediment to getting your collaboration project off the ground and making it popular is User Discomfort.  Here’s why …

  • Change is uncomfortable
  • Learning new technologies can be hard, time consuming, and frustrating
  • Voicing an opinion in a participatory community is hard for many and terrifying for some
  • Benefits of trying something new …. Unknown
  • and I saved the worst for last, Fear of Criticism

Most people live in their nice, neat worlds and don’t dare try anything too new or too different for fear it will upset the balance.  This is basic human nature.  When we all dragged our clubs around and lived in caves there was safety in numbers.  When someone walked outside the light of the campfire they were … gulp … eaten.  As humans, we are trained to stay where it is safe and avoid discomfort at all costs.  That’s why collaboration projects (and many others for that matter) fail.  So what do you do?  You make it hard to get eaten, that’s what.

Here’s what I’ve learned about how to combat User Discomfort and get your projects started off on the right track.  It’s a simple 5 step plan that will provide amazing results if done correctly.

1.  Solve a real problem
2.  Get user input early
3.  Create density
4.  Provide recognition
5.  Fail fast

Let’s take a closer look at each of these to fill in some of the necessary detail …

Solving a real problem may seem obvious but it’s not.  Lots of projects get started without having any clear goals for solving real user problems.  Solving real problems will also help build momentum with users as you evangelize your plan.  A couple of things to look out for are (a) processes that have been around for a long time and  require lots of user intervention during their lifecycle and (b) processes that require lots of communication between team members that are still done via email or file sharing.  Don’t try to become the next amazing success story that transforms your company from Good to Great (heh heh).  It can be done, but the circumstances necessary to bring the stars into alignment are rare and hard to identify early on.  It’s like asking to get struck by lightening … twice.

After you’ve identified some real pain points, communicate what you hope to accomplish to your users before you start the project, and get their feedback.  The more involved the initial users are in defining how new tools can be used to solve the problem, the more likely they are to actually use those tools (hmmmm, go figure).  One of the worst things you can do is mandate collaboration tools to your users.  Listen to me … this will end badly.  If you think a wiki is the way to go but they are suggesting something else you’d better listen.  Remember you’re trying to solve their problem so make sure your users are involved so that their opinions can be heard, evaluated, and implemented during the roll-out.

Which leads to the next fundamental success factor: density.  Have you ever wondered how Facebook became so popular so quickly?  One of the key reasons was user density.  They started at Harvard University as a replacement for a student directory (a real book that was distributed to freshmen).  They didn’t launch a national campaign to recruit lots of users until much later in the adoption cycle.  In fact, early on you had to have a .edu address to join and even then you could only register if they had launched at your college.  They would wait until they had a certain number of requests from a particular university before they would start accepting registrations from that institution.  The point I’m trying to make is that by not allowing registration at schools until they had a certain number of requests created a density of users at a particular college.  This meant that when new users from a college started joining, some of their friends were already there.  User density is sort of like our caveman example earlier – there is safety in numbers.   And having other users they know involved in the project helps reduce User Discomfort.  So my recommendation is to start small and focused and make sure the user pool you select will have a high density of actual users.

Another success factor is recognition and reward.   Pure and simple, people like to be recognized for things, even in small ways.  Think about it this way.  If you Twitter or blog and someone retweets you or comments on your blog, somewhere deep inside it makes you feel good, admit it.  It’s “cool” to have someone retweet you or make a positive comment.  This holds true for everyone else too.  Find a way to offer recognition for the work they are doing.  It could be as simple as a point system for posts, ratings for contributions, an email every so often to their managers, whatever.  This not only makes them feel better about what they are doing but also reduces their User Discomfort level.  Remember fear of criticism is the biggie.  The more you build users up, the easier it is for them to open up.

The last one is … Fail early and often.  This is really general advice for anyone starting anything.  If your first attempt at anything important goes right, you should thank your Lucky Stars.  Most efforts won’t go so well.  Recognize when things aren’t going so well and take corrective action early.  This means constantly talking with your users to determine what is and is not working.  If your user’s are complaining about too many options, remove them.  If the website is too slow, fix it.  At this point you should be working with somewhat passionate users who will likely want to see your small project become a big success (remember they helped plan it:), take advantage of the fact that the user population is small to constantly probe for feedback, and above all else, listen to it!

Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmailby feather