I was recently putting together a chart for a client to help them understand how to build a business case for Social Business. I started with this diagram:

Which led naturally to consideration of the difference between the traditional approach to rolling out collaboration and the IBM Collaboration Agenda approach. As I said in the accompanying presentation:

Business involvement in creating a social collaboration solution is key to its credibility with the business and the end users.

• IT led Social Business projects tend to fail or stagnate
• Business led Social Business projects tend to succeed

Which doesn’t invalidate generic cost benefits like reduced e-mail traffic, lower telephony costs and less travel (these are measurable benefits that can help justify deployment costs, if nothing else) but highlights the fact that the real limit organisation’s have on new initiatives tends be be around management bandwidth and short term expenditure, rather that whether there is a long term return on investment, Ultimately management will invest effort in projects that deliver more revenue or improved customer satisfaction, rather than those that might "improve employee productivity" (this is the "selling vitamins vs. selling pain killers" discussion that Louis Richardson used when I presented on the business value of social software with him at the Portal Excellence Conference 2010 in Dusseldorf recently).

Ultimately, business cases are therefore more compelling if they either deliver collaboration enabled business processes or leverage social media to improve the customer experience and increase sales. This is why the IBM Collaboration Agenda focusses on delivering industry specific and job role specific value via social business tools (like social software and unified communications).

Incidentally, I completed this diagram by highlighting the internal and external aspects of Social Business.

I was reminded of this only this morning while participating in the IBM internal Technical Consulting Group session discussing future use of Collaboration within IBM in the UK. The team just completed a study of IBMers view of their adoption of, and needs for, collaboration tools.

One of the things that became very clear in this study, was that social collaboration adoption varied significantly by job role. Typically, customer facing staff used social software less in their job, while delivery and back office workers used it more. This may be partly due to better accessibility for desk based than mobile workers (and area where we still have deployment work to do), but I believe the more significant factor is the differences in the way they work. Customer facing teams are more face-to-face, telephone, e-mail, instant message focussed, while back office workers are more meeting, collaboration space, repository (but, still, e-mail and instant messaging) focussed.

Stuart’s first law of social software adoption has always been that its use must provide a benefit both to the organisation (to justify the investment) and the user (to drive usage). This isn’t just about "sharing stuff is good because being able to search for stuff other people share helps me in my job"; it is about a much more selfish "if I take time to share this now, I get this benefit immediately".

So the TCG team refined my general "benefit to the user" statement and came up with three phases or barriers which must be navigated for an individual to become a committed user of social software:

1. Will it bring me a benefit (and what is that benefit)?
2. How do I use it (and is it easy for me to integrate into the other tools I use)?
3. Should I adopt it as part of the way I work (which needs the communities I work with to adopt it too)?

What this discussion made clear to me is that what the user needs to overcome each of these obstacles is user (or job role) specific. When you think of business adoption, you cannot rely on one set of messages to apply to everyone – you have to adapt them to the audience.

Interestingly, Jon Machtynger brought up Maslow’s Hierarchy of Needs in the discussion:

Which is probably an interesting way to refine these thoughts further. I am sure we will be considering this more in the coming weeks.