Many pundits view social-collaboration through the lens of "digital transformation," where employee digital networking can liberate organizations from rigid silos and hierarchies while creating new ways of working. There's some truth to this, but the real experience among RSG's larger enterprise subscribers is that organization-wide attempts have frequently not turned out well. Implementing targeted applications has tended to yield more useful results.

Featuritis and Going (Too) Big

In my experience, early social-collaboration initiatives frequently got pulled in two different directions:

1. Feature-focus:
   This happens when you deploy social-collaboration building blocks — blogs, wikis, activity streams, comments/likes, discussion forums, etc. — and leave it to business units to figure out what to do with them. This approach often gets fostered by IT groups, who can intuitively divine how to get value from these features, but often underestimate the immediate utility for their business brethren.
2. All Aboard:
   This is when you create a trans-enterprise environment where employees can see everyone, follow anyone, and view all activity, striving for a network effect that only comes with scale. This approach was advocated circa 2010 by some Enterprise 2.0 gurus like Andrew McAfee ("Drop the Pilot" and see his gracious hat-tip to critics) and Jive's former evangelist, Sam Lawrence (now defunct "Go Big Always" blog).
   
   Cross-enterprise transparency and scale is laudable, but after initial bursts of enthusiasm and new connections, busy employees start to pull away, struggling to get a handle on the chaotic flow of activity and align it with their workaday tasks.

Applications to the Rescue

You conquer featuritis and activity-stream overload through applications.

I'll go into more detail on each of these applications in a subsequent post. For now, just note that applications can play out at a departmental, community, or enterprise level. The main goal is not scope but employee utility.

Applications like Innovation Management and Expertise Location do rely on building blocks, such as discussion forums and profiles. But they've been tuned and polished to support a particular employee objective, like "who's our expert on financial services regulations?" or "I need a re-usable template for running this year's annual volunteering project."

We use these same application archetypes to assess social-collaboration tools in RSG's vendor evaluation research. I've always been fascinated by how few applications any given solution will support, which is one of the reasons we increasingly counsel a multi-vendor strategy. (Get a sample evaluation here.)

You may also want to deploy specialized variants to any application. Knowledgebases can be "gold" and locked-down, or very flexible and dynamic. Project collaboration requirements can prove very rigid and templatized, or in other cases highly informal and fluid. Slack has carved out a successful niche addressing the latter variant, even as it largely fails to address the former (we just added Slack to our evaluation report.)

No Guarantees

I believe taking an applications-first approach to social-collaboration is necessary, but of course it's not sufficient. You'll want to invest in a range of non-technical capabilities, including business analysis, user experience, and community management.

To see where you stack up relative to your peers, try out RSG's RealScore benchmarking tool. Application breadth is a key part of your assessment, but in the end just one of four dimensions where you measure your social-collaboration effectiveness.