Blogging was where we began, and how we built our company so we have preserved this archive to show how our thinking developed over a decade of developing the use of social technology inside organisations

The debate about pilot projects in social business


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.

3 Responses to The debate about pilot projects in social business

  1. By Mark Tamis on May 14, 2010 at 2:39 pm

    The first question to ask is which problem are you trying to solve? What is the business case for Social Business or Enterprise 2.0?Are you looking to collaborate for collaboration’s sake? Or are you looking to change your organisation to become more effective, collaborate around improving the customer experience, collaborate to innovate etc.?
    Without setting out what the objectives are to which people can rally to and what their place is in the larger scheme of things (company strategy), you are just given your employees a nice shiny object to play with. If my 3yo is anything to go by, it captures their interest for a while but will soon be relegated to the back of the drawer.
    The tools are enablers, not an end in itself. If they do not make sense in the context of your business, your pilot or even your company-wide deployment will be a time-suck.
    There are good business cases for E2.0, but you need to define these clearly before starting any initiatives.

  2. By Michael Idinopulos on May 14, 2010 at 11:47 pm

    Lee, this is an elegant treatment of a subtle and important debate. Well done!
    At the end of the day, my position is quite simple. Companies should feel free to use the word “pilot” to convey the fact that they are not (yet) committing full resources to a social software rollout. “Pilot” explains to your company why they’re not seeing the Full Monty in terms of communications, training, systems integration, support, documentation, UI, etc., etc., etc. All of that is smart and no-regrets risk mitigation. But whatever language you use, the one area where you should not compromise is on the *scale* of the pilot.

  3. By Lee Provoost on May 16, 2010 at 3:19 pm

    Hi Mark. Your comment touches exactly what is often wrong in the whole ROI discussion around Enterprise 2.0. Many decision makers challenge Enterprise 2.0 champions in large organisations what the ROI is for introducing a platform like Jive, Confluence or any other platform. These people are, as you point point, too much focused on collaboration for collaboration’s sake and why is that necessary? (which is a valid question if you put it that way)
    When you look at what Lee Bryan’t suggests with his Social Business Apps, you are basically looking at the different use cases. For instance:
    – lowering the time to market for product development by better collaborating with your suppliers and integrating transactional data (from e.g. SAP) into your interaction workflow
    – lowering the time needed to respond to an RFP for a sales team by giving easier access to subject matter experts and streamlining the RFP process
    – surfacing great ideas that live in the heads of employees (bottom up innovation) and providing a mechanism to spot these and accelerate them into a product or service that generates revenue
    And this comes back nicely to your point 🙂
    “The other Headshift Lee”