The Debate About Pilot Projects in Social Business

by Lee Bryant 14 May 2010 Blog Post

There has been a lot of discussion recently about the relative merits of starting social business technology projects with pilots versus jumping right in an building solutions at scale.

As is often the case, Socialtext’s Michael Idinopulos made an early, intelligent contribution with posts urging us to Skip the Pilot and Launch E2.0 broad, then go deep.

Andrew McAfee also shared his experience of large companies finding that constrained pilot projects often fail to gain traction, suggesting we drop the pilot. Emanuele Quintarelli, referring to Andrew’s post, emphasises one of the key problems with pilots, namely the limitation it places on serendipitous connections, which is a major source of benefits in wider deployments.

Hutch Carpenter also contributed a very thoughtful post breaking down the types of application that require a wide base of adoption to return value and those that can deliver value with limited populations.

Recently, at our Social Business Summit in London, there was a good discussion of this question, where Mark Masterson talked about why CSC decided to go straight for a large-scale deployment rather than attempt a small pilot, and Luis Suarez of IBM spoke about his experience of smaller (but still relatively large) pilots. Rather than try to summarise their excellent contribution, I have extracted the video here:

So what are the issues with pilots? I think in summary:

  • Serendipity: as Andrew McAfee pointed out, greater the constraints on population included means fewer serendipitous connections.
  • Expertise location: one reason why I think Yammer or external social network tools are unrealistic options for large organisations is that such a small proportion of colleagues are already on the system, which makes expertise location and other tasks much more difficult than it needs to be.
  • Mainstreaming: if pilots are too marginal from mainstream business activity, then they are less likely to be seen as real by participants, and are therefore less likely to succeed.
  • Experimentation: if a project is genuinely experimental, then a learning pilot that has permission to fail might be a good option, but in most cases, pilots are just small versions of a bigger project that is already planned to proceed.
  • Use cases that need scale: as Hutch and Emanuele discussed above, some social modes and some use cases simply do not make sense without scale, and so these pilots provide an unrealistic picture.
  • Organisational culture: some organisations are just not set up to run pilots – if the same inflated internal costs and processes are applied to a pilot as to a full implementation, then pilots will be swamped by bureaucracy and probably not given the space they need to operate.

What would we recommend?

If your pilot is genuinely experimental, then go for it. If you are trying to win support or investment to go further, then design a proof of concept that is broad enough to show real results, but shallow enough to be quick, cheap and under the radar. For most other pilots, I think Michael’s advice of start broad then go deep makes sense.

There are (at least) two strands to a social business project within the enterprise: strategy and implementation. The strategy part is just as important as the doing part, both ahead of implementation and, crucially, in evolving the solution once people start using it. Skimp on this at your peril.

But purely for implementation, we think in terms of three layers:

  • Social business infrastructure. This encompasses both the base platform(s) being used and the pipes, APIs, data flows and integration that connect them with each other and external systems. This layer should probably contain basic elements such as a wiki engine, micro-messaging, social network profiles, bookmarking / signalling, search, etc.
  • Social business apps. These are the specific, vertical apps that can be built on top, sometimes entirely using the functionality of the base platforms, and sometimes needing customisation or additional technology. These apps should be driven by specific user stories and cases, and can be very local or broad in their reach and applicability.
  • Personalised user experience. The key to success in most cases is making the features and affordances of social business tools relevant, useful and desirable for individuals. Over time, as participation increases and people generate more and more feeds, flows and data, personal tools that help them manage, parse and action their inbound flow will prove to be just as important as the social business tools themselves.

Some pilots can exist purely in the infrastructure layer, but ideally we like to build out just enough breadth and depth in this layer to make a pilot viable, and focus early adopting groups on one or two vertical apps that address specific business needs. And then, as you might expect, evaluate, extend, iterate … then rinse and repeat.

This post originally appeared on the Headshift blog.