A CMSWire post summed up collaboration adoption in one neat sentence recently: if it were that easy, we’d all be doing it—well.

It isn’t. We aren’t. How come? 

Ten years of knowledge sharing deployments convince me that the rules are different for E2.0. Transactional system benchmarks just don’t work, but we keep applying them to collaborative situations anyway. When you think about it, it doesn’t make sense.

Consider the “truths” for traditional back-office deployments: get everything right before you go live. Mandate a cutover date and turn off the old system. Calculate ROI by increases or decreases in anything tangible -- widgets, hours, paperwork.

None of that stuff applies to E2.0 environments. In my experience, six counterintuitive principles work better.

1. Launch Before You Are Comfortable

This is a tough one for most of us. Ignore instinct and training and go live before you’re ready. Don’t wait until you’ve addressed all the technical issues and fine-tuned every workflow. Naturally, you’ll communicate this strategy to users: if they think you think they’re using the final iteration, you’ll have a credibility problem. Release early and often.

2. Training Discourages Adoption

Whenever I mention this somebody pipes up with, “Training is important!” Yes it is, but Day One is crucial. If users can’t do anything with the system the first time they see it -- log on, post a blog entry, check a calendar or find a resource -- that perceived difficulty is tough to overcome.

Give newbies quick ways to experiment and win, even if it’s just creating their user profile and making lunch plans with colleagues.

3. Compliance is Not Victory

Ah, the good old days, when we pulled the plug on Friday night and everybody logged onto a new system Monday morning. This doesn’t work with E2.0: we simply can’t force people to collaborate. It’s all about quality and quantity.

What’s the point in uploading a hundred outdated documents before the next performance review? The most effective knowledge sharing incentives are reported to be public recognition and personal accomplishment. Money doesn’t even make the list.

4. Impossible Deadlines Work Best

This goes hand in hand with the “launch before you’re ready” principle. (Convenient, huh?) Pick a realistic launch date and compress it by half. You’ll get more done than you believed possible and less than you think is enough, which is exactly the way it should be.

Long deadlines -- or no deadlines at all -- are disaster for E2.0 programs.

5. Past Successes Don't Count

Surprisingly, a winning track record with transactional enterprise systems doesn’t help -- and sometimes hinders -- E2.0 success. Decision-making and control are shared sooner and more broadly. The project’s never finished. Appointed leaders aren’t always the de facto leaders. And first-hand collaboration experience carries more weight than titles.

It’s a different game, and not everybody can make the transition (or wants to).

6. Accomplishment Trumps Productivity

Boosting productivity is a superficial goal for E2.0. There’s no advantage to doing more stuff that didn’t matter to begin with.

The biggest opportunities in E2.0 aren’t tactical, they’re strategic. What’s the value of a one percent gain in market share if you’re a consumer products company? One key correlation if you’re an intelligence analyst? One-month earlier FDA approval if you’re a pharmaceutical research firm?

A prospective customer once said to me, “If we only knew what we know, we’d be ten times more effective.” In my view, that’s the only good reason to spend time, money and effort building a collaborative community.

Also read: