Why We Struggle With Social Software ROI

One of the prominent themes in any discussion of social software in the enterprise is Return on Investment (ROI). I opined in a previous post that all too often ROI is a hurdle put in place by opponents of a project to prevent it from happening or succeeding. I also said that organizations that have collaboration hardwired into their culture understand and accept the value of social software without a demonstration of ROI. Conversely, even a reasonable, positive ROI projection isn’t likely to get a proposed social software project approved in an organization that doesn’t “get” collaboration. I stand by those statements and have another observation to add:

The primary reason organizations are struggling with ROI in social software is because they have little or no idea what they want to accomplish by using it. There’s no link to business strategy and tactics.

To calculate ROI, one must define specific, measurable metrics, for which annual financial benefits can be projected out over 3-5 years. The rub is in developing the metrics. Defining appropriate metrics requires knowing what the organization wants to accomplish by making an investment. We all know this. Yet too many seem to forget this basic principle of ROI when contemplating an initial social software project. They get caught up in the hype of the newest fad and forget that technology must be deployed in support of a well-defined strategic goal or objective. They focus on the “soft” benefits of social software use that are widely communicated today instead of on how using social software in support of a specific business strategy or tactic can lead to revenue increases and cost reductions in the business.

Before you and your organization get too enamored with the shiny new toys presented by social software, or get caught up in the hype cycle, take a step back and ask questions like:

• What specific strategic imperative(s) could be enabled by social software?
• Where could social software help us increase revenue and/or reduce operating costs?
• Why are some of our employees using social software despite our reservations about it?
• Who might we be able to create new and valuable business relationships with by using social software?
• What differentiation for our company and it’s offering(s) could be built using social software?
• How could social software be used to increase trust inside and outside of our organization?

The answers provided by asking these kinds of questions will provide the purpose behind your social software project and investment. Knowing the purpose will make it possible to define metrics that can be quantified in dollars (or whatever currency your organization operates in) and demonstrate potential ROI.

Are you having trouble defining questions that reveal your organization’s purpose for investing in social software? Please contact me so we can discuss ways that I can help.

Autonomy in Collaboration

It hit like a flash of lightning.  I was hanging out in the Twittersphere yesterday, as is normal while working at my desk.  Then, right in the middle of one of the lulls in Twitter traffic that seems to occur every afternoon, I was rocked by a singular tweet posted by Stowe Boyd.

Stowe was in attendance at the Defrag conference, in Denver.  He had overheard a conversation and tweeted a simple, but striking comment on it:

“When collaboration people start talking about motivating people to participate it means the tools don’t provide enough autonomy.”

In one short, clear sentence, Stowe summed up much of what I believe is wrong with Enterprise 2.0.  Too much workplace collaboration is too tightly controlled by corporate IT.  Not only do they choose which collaboration tools employees can use, but they also (in most cases) prescribe and limit how those tools will be used.  Sometimes this constriction of usage is unintentional (poor product choice), but often it is intentional (policy and business rule choices.)

Here’s a hypothetical, but plausible example.  The CIO of Acme Corporation was concerned because a large number of employees were using external blog providers to publish information and opinions related to their work and the corporation.  Acme had no way to identify and monitor all the external blogs, and the company’s leadership was concerned that the Acme brand was taking a hit as a result of comments made in public by employees.  Acme was also terrified that employees might carelessly divulge confidential information on external blogs.

In order to accommodate employee eagerness to blog, Acme deployed an internal blog network, based on software purchased from Vendor X.  The intranet blog facility was established behind the corporate firewall, effectively excluding all non-employees from reading posts and commenting on them.  Acme’s CIO believed this solution would be a win-win; employees could fulfill their desire to blog, and the corporation could be certain that its brand reputation and confidential information would be protected.

The existence of the new intranet blog was heavily publicized, both before and after launch.  Training was provided on the use of the blog environment to any employee that registered.  Acme’s CEO and CIO even started their own blogs in an effort to lead by example.  However, six months after go-live, the number of blogs established and the number of posts and comments created were dismal.  And, despite the money, time, and effort spent to motivate employees to shift their blogging to the internal environment, anecdotal evidence suggested that even more Acme employees had started external blogs!

Why did the Acme internal blog fail?  It did not provide the autonomy needed by employees.  Acme employees wanted and valued feedback from their customers, business partners, and industry peers and analysts.  The intranet blog excluded those external collaborators, thereby limiting the value created by the blogging activity.

This is a very simple, hypothetical example, and I’m not at all sure that it represents what Stowe Boyd was expressing when he tweeted yesterday (I apologize to Stowe if I’ve misinterpreted his line of thought.)  However, I hope it illustrates the issue as I construe it.  Savvy employees know why and how they want to use specific collaboration tools.  Corporate IT must listen to its constituents and work with them to meet their requirements, rather than imposing solutions and trying to motivate adoption.  Providing autonomy hinges on one thing — TRUST.  Show me an organization that isn’t willing to trust its employees to use collaboration tools appropriately and provide them the autonomy to do so, and I’ll show you a collaboration failure about to happen.