A few weeks ago I was in Zurich presenting at Somesso. Part of my talk was around ROI where I had the opportunity to speak about why ROI is so difficult for social software.

First, it’s always worth checking whether or not your ROI case is needed to convince people that social software is a good thing, or to get your social project formally approved.  If you’re trying to use an ROI case to convince people that they should undertake a social software project it’s unlikely to work – Larry Hawes puts this best:

“No business case will sell social software to a firm that doesn’t already value collaboration in its culture.”

However, an ROI can be used to get a social software project approved. When I was working with Portal products several years ago, we often sold them on the basis of collaboration and productivity, but got them approved by making a case that due to single sign on the number of calls to the (outsourced) technical help desk would be reduced. An approval ROI can be very different from trying to convince a client of a project’s value. Social software can often be approved on the basis of time saving, even if the true value is innovation.

Second, it is easier to make ROI cases for social software projects which involve collaboration between people who know each other, as opposed to projects designed to help you find people you don’t know. This is because the former is more measurable, you know how many attachments you send to your team and how often documents are reviewed. Social software discourages attachments from being sent, which reduces storage cost, and speeds up the document review process, reducing inaccuracies due to poor version control. IBM, for example, believes it has saved $16.5m per year by moving email “conversations” on to instant messaging.

Third, there is a good reason why social projects to help you find expertise and innovate with people you might not otherwise know have such trouble with ROI. Traditional IT projects have an ROI because they help speed up business processes. They might allow a client to sign up over the web, for example. An organisation knows how many clients they sign up per month, how long that would take their staff over the phone, and what that cost is in terms of salary. They can therefore work out how much they would save if 50% of their clients signed up over the web instead. You can do similar calculations with IT solutions that improve a manufacturing process, or speed up invoicing. Social interaction is different. Whereas traditional IT supports business processes, social software helps you when the business process breaks. But you don’t necessarily know how often the process breaks, it’s not as predictable as number of invoices processed per month, or new clients signed up per week. You don’t know what benefits could be realised if Joe in Finance talked to Sarah in HR. It might be absolutely nothing. On the other hand it might fundamentally change the company for the better. Social software is a serendipity lubricant that increases the chances of valuable interactions occurring - but it makes no guarantee on their frequency or their value.

So what’s the best way to proceed? To quote my friend Euan Semple on ROI, “if you make the ‘i’ small enough, no-one will care about the R” – certainly helps. You can start with pilots at very low cost and low risk. As roll-outs get bigger, try to get the ROI approved on something more tangible, such as time saved on email, even if this isn’t the focus of the project. And finally as Larry says, if the ROI is needed to convince an organisation that collaboration is “a good thing” – then ROI is the least of your problems…