Enterprise 2.0: Skip the Pilot

Get out your pitchforks, I'm about to commit Enterprise 2.0 heresy.

There's an orthodoxy in Enterprise 2.0 circles about how you're supposed to run an implementation. The orthodoxy goes something like this: Start with small-scale pilots, define your business objectives, watch the pilots closely, evaluate their success, make a go/no-go decision. (A good recent articulation of this view is in Chris McGrath's recent post on 8 Tips for a Successful Social Intranet Pilot.)

As far as I can tell it's what everyone thinks. In fact, it's what I used to think. Unfortunately, it's dead wrong. The orthodoxy is wrong for a very simple reason: Size matters. By constraining the size of your pilot, you significantly alter the way your company can and will use the tools.

I'm not opposed to pilots for most enterprise IT solutions. Companies like to pilot new technologies with small populations before they roll them out enterprise-wide. That approach makes a lot of sense for transactional systems like order management, project management, purchasing, ERP, and so on. By piloting with a small group, you reduce implementation risk. You get a read on the value of the solution, and you get feedback which you can use to make modifications while those modifications are still relatively easy and inexpensive.

But social software is different from traditional IT. Traditional IT enables individuals to carry out well-defined, highly standardized transactions. Users go into the system to process transactions--to transfer funds, purchase supplies, track inventory, etc. The nature of these transactions, and the system's ability to enable them, doe not vary much according to the number of people using the system. Whether 100 people are entering orders or 10,000 people are entering orders, the transactions themselves doesn't really change. What that means is that a representative small-scale sample is an accurate predictor of adoption and value at full scale.

But Enterprise 2.0 tools are different from traditional IT systems. Traditional IT enables transactions; Enterprise 2.0 enables interactions.

Interactions and transactions have completely different scale economics. When we use Enterprise 2.0, we're not transacting with a system; we're interacting with other people. An interaction is a connection between two or more nodes in a network. And as Metcalf's Law famously states, the more people there are in that network, the more interactions each individual can have with his or her peers, and the more value that individual derives from participation in the network.

When companies pilot Enterprise 2.0 tools with small subsets of their organization, they're not testing collaboration with a representative sample. An artificially constrained pilot is always a poor representation of post-pilot collaboration, because the range of potential interactions is so limited. The value delivered to each individual participant is exponentially smaller than it would be at full scale, and the ways that people will use the tool are different.

That doesn't mean small-scale Enterprise 2.0 pilots can't succeed. They can, and many do. But even when pilots succeed, they have limited ability to predict how the organization goes on to use the capabilities once they are rolled out enterprise-wide. Pilots typically fall into the lower left-hand corner of the Social Software Value Matrix: improve existing interactions within existing silos. That includes things like project team workspaces, departmental workspaces, and technical knowledgebases. When organizations really embrace Enterprise 2.0, however, they almost always play in multiple sections of the Value Matrix, launching solutions like collaborative intranets, ideation portals, private extranets, Those solutions, almost by definition, require scale.

Scale is the oxygen that feeds collaboration. That's why collaborative tools like Facebook, and Twitter have taken off so spectacularly on the public web: With over a billion people on the Internet, the opportunities for interpersonal interaction are unbelievably high.

From a practical standpoint, this has a counter-intuitive implication: If your E 2.0 pilot is struggling, don't shut it down. Make it bigger. Open it up. Invite more people. Tell them to invite even more people. That's the only way you're going to find out the real behavior and the real value.

If you're just starting to launch Enterprise 2.0 tools, throw the doors open wide. Invite your entire company, or as much of your company as you're allowed to invite without waiting for an act of God or Congress. Give them fun, easy ways to start contributing. (My personal favorite is microblogging.) Ease them into deeper forms of collaboration like wiki workspaces. And support those users who come forward with good ideas on how to use the tools.

Just to be clear, I'm not saying you shouldn't have clear business objectives. I'm not saying you shouldn't subject your Enterprise 2.0 implementation to critical evaluation. I'm not saying you shouldn't learn from your users and incorporate those learnings into your plans. Those are all good and important things to do. But you can only do them if you're piloting the tools in a way that you'll really learn from: at enterprise scale.

Comments

[Emanuele Quintarelli]

Hi Michael,

I can surely see your point and I do believe size matters as well but I can also hear many of my clients hoping to dip their toes gradually into a new way of working and conceiving their business.

As I said scale matters but not in an absolute sense: in my experience what you really need to guarantee is a meaningful group to create value and make the system scale later on. This doesn't necessarily mean involving the entire company from day one and for example you can work cross departments simply focusing on the right people in a 40-50 users group (taken from marketing, pr, communication, etc). To guarantee the value, you need to carefully select the right people (for the size of their network, their expertise, the trust and credibility, leadership, the department they are working into, etc) and to nurture that group while gradually learning and inviting others to join.

A final point: the right size probably also depends on the kind of scenario you are thinking of. Collaborative authoring could work in a single silo, capturing collective intelligence is clearly quite different. Again this could mean 30 people in a 150 people company or 1000 people in a 100K people company, but it's still a pilot, isn't it?

To me it's not doing the pilot or not going for it. The key is doing the right kind of pilot. Choosing the right size, the right people and cultivating them with love and patience could still make the trick :)

[Chris McGrath]

Hey Michael,

Thanks for the reference to my 8 Tips on Pilots article, and for the thought-provoking article. You make some good points.

I have two issues to take up with you:

1) The no-pilot recommendation is self-serving. You're a software vendor. I'm a software vendor. In all seriousness, I really wish people wouldn't pilot our software -- I wish they would just *buy it*! Means more revenue, sooner. But because no-pilot is better for vendors, your post could be biased.

2) Metcalfe's Law. Some feel that Metcalfe's law isn't applicable to social networks, but rather tends to greatly overvalue them. Is the value of the network really equal to the square of the number of nodes? A contrasting view is the n(log n) rule, which surmises that the second most important person in your network will have half as much correspondence with you as the most important person, the third most important person will have one third the correspondence, and so on. These and other laws are discussed in nauseating detail in this post by Bryan, our analytics expert: http://www.thoughtfarmer.com/blog/2009/04/27/intranet-roi/

At the end of the day, I hope you're right, because I'd rather sell a 10,000-user enterprise license to our software than a 100-user pilot. Do you have any ideas on how we could prove your theory?

[Michael Idinopulos]

Chris, thanks for your comments. I have a lot of respect for Thought Farmer and for your blog. I'm happy to be having this conversation with you.

Once you understand Socialtext's business model, you see that my no-pilot recommendation is not at all self-serving. Socialtext is a SaaS (Software as a Service) company. Our up-front fees are lower than traditional software vendors, and our revenue comes disproportionately from customer renewals beyond the initial contract period. A customer who buys and fails is actually worse for us than a customer who doesn't buy in the first place. So it's not at all in Socialtext's interest to sell a new customer based on an approach that won't deliver long-term success.

My objection to pilots comes from years of E2.0 implementations, first inside McKinsey & Co, and subsequently with hundreds of Socialtext implementations. Like you, I used to recommend small-scale initial pilots. But over time I noticed that our most successful customers consistently launched on a larger scale than our less successful ones. That led me to question why small-scale pilots weren't yielding better results.

We could argue over the details of Metcalf's law and the precise shape of the curve that describes the relationship between scale and value--logarithmic, exponential, whatever. But it doesn't matter. The point here is that a group of 50 and a group of 5,000 will adopt the tools in completely different ways. The 50-member group will focus on "closure" activities across strong-tie relationships (e.g., meeting notes, document co-creation, etc.) The 5,000-member group will focus on "brokerage" activities (social networking, micromessaging, expertise location) across "loose tie" relationships. (For more on Brokerage and Closure, see my post http://michaeli.typepad.com/my_weblog/2008/12/brokerage-and-closure.html)

It's silly to think that a 5,000-person rollout is just a 50-person pilot expanded 100x. I think most people would agree. And yet many companies base go/no-go decisions on small-scale pilots. As I've argued (see link above), brokerage and closure activities are both important. They're also mutually reinforcing. If you just focus on small-scale collaboration, you're missing more than half the picture.

[Chris McGrath]

Michael, you make a good case. I really appreciate the distinction in use cases in your Brokerage & Closure post, too -- it's an easy-to-understand articulation of some difficult concepts.

Practical question for you: How is E20 ever going to go mainstream if it requires massive deployments? I'd hate to be the person that convinces their company to make a million-dollar leap of faith, only to have a full-scale rollout languish. Shouldn't we strive to show tangible benefits at all levels of deployment?

[Amy Senger @sengseng]

You fail to acknowledge that pilots can afford the Enterprise expediency in getting the solution out quicker b/c they can circumvent some of the rigmarole of IT and security politics, red tape, bureaucracy, etc. This agility can be key, esp when the solution significantly challenges current business operations and tenets. You can implement a pilot fully scaled to include your entire customer base but still take advantage of the flexibility that the label "pilot" or "beta" allows.

[Robert Fransgaard]

Interesting view. The more I think about it the more I find myself agreeing with it.

For a web community/forum/group I would always aim to get that little core group in place first, the pioneers who will become your ambassadors, but for Enterprise including as many as possible makes sense to me.

However, a pilot may still be a feasible option, but instead of limiting the amount of users maybe a better way is to limit amount of functionalities as this would A) create a limitation on the pilot; B) introduce the whole concept to the users one step at a time; and C) gives a more agile environment to develop the structure based on user feedback.