Ever 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!

I have to admit that I'm a bit of a collaboration and community junkie and as such follow some obscure topics.  One topic I've had on my radar for quite some time is Flock Theory.  Flock theory tries to describe the self-organizing and emergent aspects of human behavior.  Succinctly put, behavior in some cases is not a property of any individual person (or bird), but rather emerges as a property of a group or social network (flock).  This concept can be used to describe aspects of both collaborative teams and open source communities.  I'm don't want to analyze the merits of the theory but I do want to introduce its concepts which I think have implications for team/community productivity and possibility even individual information relevance.

The fundamental aspects of Flock Theory can be distilled into the following axioms and tenets ...

Distance Optimization

1. Avoid crowding group members
2. Move towards the central tendencies of the group

Motion Replication

1. Direction Matching
2. Velocity Matching

Leadership Maintenance

1. Group leaders must shift efficiently
2. Eliminate extreme dissenters

Distance optimization speaks to the fact that teams need to find a balance between working autonomously and relying too heavily on team decision making.  Teams and communities that rely heavily on group cohesion (or decision-making) can find themselves with a case of "groupthink".  However, having accountability is such an environment is equally important Allowing group members the autonomy to work requires having goals that each member can be accountable for.

And finally, Leadership Maintenance is perhaps the most interesting part of the theory (for me) as it postulates that there is a need for constant leadership change so that management of the flock remains fresh and focused and is always headed towards the correct goal.  Any extreme deviation from goal-oriented behavior by a team member can risk the mission and must be dealt with harshly.

I find Leadership Maintenance especially intriguing given my association with open source projects.  Based on Flock Theory one could argue that open source project management should continuously turnover so that other community members can help shape the direction of the project.  In reality many successful open source projects have very strong central leadership that never really change significantly.  A few that jump to mind ... Linux, Perl, Python, Scala, Ruby, etc.  All of these projects have a vibrant community of active participants but are led by a strong leader.  There are also examples of successful projects that follow Flock Theory more closely.  Apache jumps to mind.  Is Apache a better project than Linux, Python, or Ruby?   Certainly not.  But perhaps it is a better example of what an "emergent" software project looks like?

Teaming 2.0.0 Beta 1 has been released and includes some cool and some surprising changes:

The big surprise is that we no longer bundle Liferay with Teaming. Our default configuration is now to run as a standalone web application. We had many requests to make this happen and we did.  For users who really can't live without Liferay we will soon release a Liferay "lite" version that integrates with existing Liferay.

The significant new features of 2.0.0 are ...

• Open source Teaming now includes advanced workflow capabilities that allow an object in the system to have an attached workflow.  Users can process blogs, files, wikis, or even custom web forms with workflows now.
• New guest account so that users can assign privileges website visitors without requiring authentication
• New extension specification and deployment functionality that allows additional functionality to be included in a Teaming instance just by dropping an archive in the right place.  Now developers can easily extend Teaming with new applications and workflows. See the wiki article that explains it.
• Many UI improvements

1. Second Class Citizen Problem

   1. Virtual teams members must overcome the "Second Class Citizen Problem" when working in teams. Virtual members can have less influence than local team members.

   2. This is primarily due to lack of Trust

   3. Teams must work very hard to develop processes and tools that lead to trust and full collaboration between remote and local workers

   4. Example: SVN development team decided that no decisions would be final unless discussed on mailing list. Way to gain consensus and force discussion across everyone in the team.

1. Team Communication Tools

   1. IRC is critical for most virtual teams studied

   2. IM is to disruptive and costs productivity

   3. Teams like IRC better than IM because IRC is about the group, IM is about an individual.

   4. There is an expectation that the receiver should drop everything and answer a question with IM. In IRC questions are asked of a group instead of a person

   5. However, IRC can get too big then it is just noise. Channels should be limited to 15-25 max and should be very focused.

   6. IRC needs protection to stay small and focused. Things that can be asked on the mailing list should be moved to the mailing list.

2. Video

   1. Video chat is rarely used

   2. Screen sharing is used alot

3. Community

   1. The way to move up in an open source project is to ask for help and take the feedback. Tools need to be transparent so that everyone sees this.

   2. In open source there is a lot of mentoring to move people forward. Not do it yourself but push people to do it themselves.

4. Team Tool Design

   1. Put features in people's way so they don't have to find them. Like SVN comments on checkin. From Aza Raskin.

   2. Information overload is everywhere. Need filtering by topic or context.

   3. Sometimes it can be too easy to add information creating too much fragmented data artifacts. Teams need the ability to pick and choose what they want and define rules for adding information that is relevant.

   4. Tools should move people to think about what the topic and objective is rather than where the information lives or who sent it. Topic-centric view.

   5. One of the most overlooked team software features is the ability to associate decisions with the process that was taken to reach consensus.

5. References

   1. Garr Reynolds - presentation guru

   2. Subversion talk (Poisonous People talk on YouTube)

   3. Paul Eckman – Behavioral Science

   4. Aza Raskin – UI Design

Ever wonder how you could integrate your kablink or Novell Teaming instance with a remote system and pass data back and forth?  What if you wanted to send your SAP or SalesForce.com systems some of your kablink data.  You can using custom actions and conditions that can be integrated into the workflow engine processing.  A new tutorial in the Wiki walks you through creating a custom workflow callout that can handle some pretty heavy lifting when it comes to data integration.  This tutorial really gives you a glimpse of the power that was added to Kablink with the addition of workflow.  Check it out!