Social software ROI

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…

This entry was posted in Enterprise 2.0, roi, social software. Bookmark the permalink.

11 Responses to Social software ROI

  1. Larry Hawes says:

    Thanks the quote, Jon, and I’m glad that you agree! You are absolutely right that ROI can (and should) be positioned as an approval enabler, especially when dealing with well-understood business processes. The hurdle to demonstrating value is certainly lower in that situation. This is great, practical advice that everyone should keep in mind!

  2. Jon Mell says:

    Thanks Larry – and thanks for your quote which started my train of thought along these lines..!

  3. Swan says:

    Perhaps a pseudo-science that helps get us part way to an ROI. eg. Find a way to calculate the value of two people in your organization finding each other when they need to connect and then estimate the additional number of times this would happen with the new system over the old one. Perform the multiplication to estimate ROI.

    Also, can we calculate what we might lose by not innovating? What is the difference between where we want our business to go and where we are now? How much of that do we expect to come from innovation? How much does collaboration contribute to innovation? Can we look to the past and determine how much more we made thx to innovations? Would those innovations have been possible without collaboration?

  4. Ted Stanton says:

    Good summary and I’m finding the same with the customers I speaking with. Glad I’m not the only one :-)

  5. Start with pilots at very low cost and low risk. That seems to me the best way to setup the first step. To me this was a key statement at the somesso.

  6. Peter Bray says:

    Hi Jon

    Great post – check out http://www.streamwall.com for a good way to measure success.

    Cheers
    Peter Bray

  7. Hi Matey, thought I would share this preso with you – talks about RoC ratios as a way of measuring benefit.

    http://kiwilight.blogspot.com/2008/10/measuring-success-of-social-networking.html

    Cheers
    Chris

  8. Abbe says:

    Check out Aberdeen’s recent Sales 2.0 report that looks at the percentage of best-in-class companies using wikis and enterprise 2.0 tools and say those tools contribute to their better numbers. Here’s a blog post on it: http://wikisunleashed.blogspot.com/2008/10/aberdeen-on-sales-20.html

  9. Jordan Frank says:

    Reducing search chains (to find experts) and collaboration have tangible benefits, albeit hard ones to quantify in a material manner. A pair of papers in MIT Sloan Management Review confirm the direct tangible problems faced by employees who have a harder time locating an expert or faced by failure of divisions/subsidiaries of a company to collaborate and seek knowledge with other divisions.

    See “Collaborating Across Boundaries, Searching People for Answers” (http://traction.tractionsoftware.com/traction/permalink/Blog793)

    Per Euan’s point that you bring up, the “I” that you might spend on a social software project is miniscule compared to the benefits that can be unlocked. And, while, trying to unlock those benefits by quantifying storage saving from e-mail may “pay the bill” it will miss the point.

  10. Gary Solomon says:

    Tremendously insightful article. Even years later, in 2010, organizations and social software solution firms struggle with the quantifying the initial spend for these environments.

    To the point logged in March, 2009, I agree that the investment in minuscule to the benefits. But getting out of the gate is extremely difficult in these times of flat or constricting IT budgets. By using an off point such as storage saving to pay the initial bill is huge. The bill payers don’t understand intangibles.

    We’ll all get to the real value, but without getting out of the starting gate with something blasse like storage savings, there will never be a chance to realize the true point.

  11. Pingback: Library clips :: Skip the buy-in and get ‘em addicted! :: May :: 2010

Leave a Reply