Real Story Group. Make Better Technology Decisions.

A Scenario-based Approach to Evaluating Social Software

By Tony Byrne at 2008-10-21 15:00:00 |

This article is excerpted from the CMS Watch Enterprise Social Software Report, which evaluates 20 vendors head-to-head.

The previous chapter in this report introduced numerous concepts around product functionality and vendor predilections. But the key to comparing technologies lies in how well they fit particular scenarios. The right solution is the one that works for your needs. But how best to understand your needs? In our experience, scenario analysis provides the most efficient shortcut.

Explicitly or not, different Social Software products target different use cases. Understanding the business scenarios that fit better or worse for the different packages enables you to see deeper into their relative strengths and weaknesses for your particular circumstances. Therefore, we have identified eleven common scenarios against which vendors can be judged. Each scenario emphasizes to varying degrees the features we elaborated in the previous section.

About the Scenarios

To be sure, these scenarios are abstractions. In practice your own efforts here are likely to represent variants or some hybrid combination of scenarios. And the cases overlap somewhat. Nonetheless, they are useful for understanding which types of products tend to work better for which type of projects.

Overall, our eleven common scenarios represent different business objectives or outcomes that can yield the business benefits outlined above. In some cases, they may represent specific projects as well, although we find that many Social Software investments target multiple scenarios. We break the eleven scenarios down into two broad categories: External and Internal.

• External scenarios involve social networking and collaboration with people primarily outside your firewall.
• Internal scenarios focus on activity that takes place primarily behind your enterprise firewall. We say "primarily" because in practice enterprise networks can get fungible, especially where collaboration is involved.

Nevertheless, we find that most technology offerings in this space target either Internal or External scenarios. Or, if the same product gets marketed for both categories, typically it gets implemented as two wholly separate environments. Use this section -- and the comparison charts in each vendor category -- as a guide to identifying which vendors might fit your needs best. As you'll notice, some vendors fit well into multiple scenarios. Do not discount a vendor because we didn't list them in a particular scenario. Similarly, don't use this section to identify your short list of vendors for soliciting proposals. Rather, scan these charts to help identify your long list of suppliers to investigate deeper via the individual vendor chapters.

Under each Scenario, we identify Key Services (e.g., wikis) and Functional Emphasis (e.g., spam filtering) that become more important for that particular use case. Let's take a look at a couple of scenarios to give you an idea.

External Scenario: Branded Customer Communities

A plethora of Social Software providers offer "community-in-a-box" services designed to support clubs, affinity groups, product enthusiasts, and anyone else interested in forming or becoming part of an online community. Typically there is a community "owner," who could also be the owner of a particular brand who wants to create a community around that brand. In either case, unlike the next scenario ("Customer/Reader Interaction"), the emphasis here is on community-generated and community-organized information.

Like other external scenarios, Spam/Naughty Filtering is essential to reducing incidents of abuse, especially if you are not moderating all submissions. Since marketing and product management teams will take a keen interest in what is going on in these communities -- in addition to participating in them -- they will want to see more advanced analytics on usage patterns and impacts.

Internal Scenario: Enterprise Discussion

At first blush, Enterprise Discussion may seem like Enterprise Collaboration, but the two scenarios are in fact quite different. This scenario emphasizes "discuss" over "do." Many business leaders are innately skeptical of this, considering talking as a time-waster. Don't "actions speak louder than words"?

Well, it turns out the power of the word is quite important. Early Social Software adopters have found enterprise discussion as a key precursor and adjunct to enterprise collaboration. Not all internal conversations are "projects" that need structure and guidance. Important conversations about strategy, procedures, and objectives go on in every enterprise. The question is: Do you want them to transpire only in conference rooms and e-mail distribution lists?

The key here is to allow informal, bottom-up discussions that can supersede boundaries. Every CEO talks about wanting to dissolve internal silos, but few have concrete ideas about how to make it happen. Software can help here, but also a willingness to seed discussions, and then tolerate it when it doesn't go in the direction that the enterprise anticipated.

[Note: the full report explains all eleven scenarios.]

Example: Traction Software

Now let's extend the analysis to a particular product, Traction's TeamPage. It's a broad (albeit rather complicated) offering from a small, passionate vendor that embraces services ranging from wikis (foremost), blogs, forums, project collaboration, and profiles under a single system. TeamPage really supports a kind of hive of interconnected pieces of information. The idea is that you can contribute anything, anywhere, and link promiscuously to other assets.

The Scenario Fits chart reflects TeamPage's broad functional product. It offers the kind of open canvas for unstructured information sharing that you'll find only in Oracle (formerly AquaLogic) Pages or the better wiki packages. At the same time, you can employ TeamPage to support fairly structured collaborative projects as well.

Clearly, though, this product is best suited for Communities of Practice -- in fact, a particular type of CoP: researchers and analysts who have to accumulate and organize large quantities of arbitrary information. To the extent you can collectively track and annotate photos, text, feeds, and maps about "Rocket Launchers" in "Peshawar" in the "Taliban Tracking" wiki within the "Terrorist Threat" project, and bookmark it under "Afghanistan" and "Pakistan," and make that information readily available to other analysts, well, then you can see the appeal for national intelligence -- as well as competitive intelligence -- use cases.

The same services could help you build a loose or highly structured knowledgebase as well, but we believe this isn't a great tool for encouraging the more ad hoc spread of wisdom, news, and simple (but important) arcana that you would find in a stronger blogging package, for example. More generally, this is not a good Social Networking platform, and we would never call it a "fun" product to use.

TeamPage also remains less oriented toward discovery (especially people-finding) and Enterprise Discussion. Finally, you also really wouldn't want to use this product for any External scenarios beyond perhaps a fairly tightly controlled partner extranet.

Putting It All Together

As mentioned earlier, your Social Software efforts may span multiple scenarios, and a single project may consist of a hybrid of two, three, or more. That's OK. These are abstractions to get you thinking more concretely about what you're trying to achieve, and to give us a more business-friendly approach to segmenting the vendors in the evaluations that begin in the next chapter of the report.

Next, let's put it all together by re-introducing our "Focus Point" chart from earlier in this report, and suggest a placement for each of the individual scenarios.

Again, there is no "magic" wedge here. No one scenario is categorically more important than the other. Your mission is to figure out which ones are most critical to your enterprise, down-select vendors, and plan accordingly.