When people consider introducing social-computing in their organisation, one of the questions that regularly comes up is ROI: "what is the impact of social tools, whether blogs or wikis or social networks or social bookmark or all of them, on my ROI?"

There are two ways of answering that question. Either you provide rough estimates with ball-park figures or you answer "I don't know". My view is that it is better to go for the second answer, even if this not comfortable for the client. [after all the ROI question shows that people have not captured the essence and the value of the approach]

Why? Because social tools differ from traditional IT solutions. In what sense? Most traditional IT solutions are designed to address one and only one issue. E.g. if one wants to improve its customer relations, it will go for a CRM solution. One problem, one solution. From there is it pretty easy to analyse and measure the variation and consequently provide a priori answers on ROI. Traditional software vendors sell "solutions".

The trick (and beauty) with social computing is that one tool can address many issues and provide a diversity of solutions. A blog platform can be used at the same time for co-ordination and support among and between teams, CEO blogging, marketing and reputation, designing entire websites (including "static" pages), knowledge sharing and dissemination, engaging with third parties (clients, investors, partners), etc ... A wiki similarly can contribute to a variety of collaborative processes, but also be the foundation of public websites. The opposite is also true: a bespoke solution including a blogging platform, a wiki and a social bookmarking app is great for knowledge sharing. Also, the mash-up of data and applications favours non-standard systems.

As a result, it is very difficult to provide an answer to the ROI query. In fact it is difficult a priori. Software vendors and consultants can only provide estimates that are ultimately pointless. Hence my above mentioned preference. But when social computing enters the organisational arena, measurement is a key element in the decision making process. And some people won't go for a solution they can't financially justify it to their sponsor or board. That's fair.

Looks like we're between a rock and a hard place. Well, yes and no. The ROI question does have an answer. Measurement is possible, but context is king. It is only when in context, where the issue to address is well defined, where tools are correctly customised to processes and credentials, that the impact of social computing can be measured. Measurement is possible when implemented, a posteriori. Back to basics.

The role of a consultant or a software vendor in social computing is not to provide an off-the-shelf solution and the scorecard that goes along with it. Past experiences have showed us how painful and irrelevant this can be, because:

• It creates more issues than it provides solutions


• It discourages people who are forced to adapt to the tool


• Adoption is hard


• It can be expensive

Their role is to define issues that social computing can tackle better than traditional corporate software, and help integrate that smoothly in the ecosystem. Measurement of ROI, building balanced score-cards and so on, is the role of business analysts. The data models are for finance people to build, which is what they have been good at for more than a century. The real issue is not about busyness, as Andrew McAfee writes, but rather laziness.

Why? Because the adoption of social computing in organisations - some call this Enterprise 2.0 - is a major evolution of both the knowledge economy and organisational development. It is meant to create a better way of sharing knowledge in organisations, which is a key intangible asset. It is meant to create more sustainable businesses. It is about delivering the right info to the right people at the right time, rather than focussing on storing data (a major activity of IT). As Martin Roulleaux Dugage says: enough of building sky-scrapers, let's build bridges. A smart and profitable company is made out of informed employees, simply because a well informed employee is more efficient in his/her role. Implementing social-computing in organisations is serious business.

The major shift we need concerns tools and our relationship with them. One lesson organisations can take from Web 2.0 is that social software is not some kind of "Deus ex-machina" - in fact, no single tool is. Tools that pretend to be one-size-fits-all solutions are aimed at lazy IT and procurement departments, not business people.

A major reason why social computing projects can sometimes fail, or simply not happen, is that people buy a social tool and expect it to do all the work, because that is the way they were educated about traditional IT solutions. Organisations need tools, but most of all they need to build 'situated' custom applications and services around them.

Tool builders invent simple yet powerful tools. Consultants - more precisely technology agnostic consultants - invent smart ways to make them work in organisations (quite often mixing and customising tools), working hand-in-hand with their clients. Elsewhere, business analysts invent new ways of translating real-life operations into economic representations (ratios and score-cards). This is exactly what happened a century ago when corporations were facing new (physical) production processes (Fordism). At that time, business analysts were engineers. Things went wrong only when people standardised the method (scientific management) to create from it a recipe, if not an ideology (Taylorism). Scalability? No, just laziness (soldiering to use Taylor's own word).

There is no standard recipe to encapsulate the new, social, way of doing things: we are all experimenting in different contexts. Experience shows that a good method is bottom-up, such as a small pilot group with defined needs, a collaboratively designed prototype, a test phase and eventually diffusion more widely within the organisation.

Nothing new under the sun, in fact. The hope is that this time we don't switch from methodology to recipe and lose the value of the former in our lazy pursuit of the latter.