By now, many of you will have surely read the recent Drop the Pilot post in which Andrew McAfee, the Enterprise 2.0 father, manifested clear criticism against the way enterprise 2.0 projects are currently launched and cultivated by many experts in this domain. To say the truth, the position taken by Andrew is not completely original given that Michael Idinopulos of Socialtext had sustained the same point of view some time back, generating a lot of discussion in the community.

In the field of Enterprise 2.0, to me a pilot is

a method of co-design and adoption of new collaborative practices that follows an iterative, incremental and risk moderating approach to intentionally avoid organizational resistance

In other words, it is a strategy designed to reassure the management and especially to engage users by putting them at the center of  a content and services co-design activity.

What are the main points addressed by Andrew?

• The number of people involved: pilots are usually limited to a small number of people (a percentage of the overall number of employees)
• The low diversity of participants: launching departmental or group confined pilots that operate in a well-defined physical and operational boundary means choosing strongly connected individuals, whose distinctive personal knowledge is marginal compared to the group’s one

Even more meaningful than the criteria for pilot selection is McAfee’s belief that Enterprise 2.0 is first and foremost a matter of serendipity:

The more I learn about and think about the value of emergent social software platforms, the more I suspect that the deep meta-benefit they provide is technology-enabled serendipity, defined as ‘good luck in making unexpected and fortunate discoveries.’ Serendipity is possible when we’re collaborating with our close colleagues on a well-defined project, but that’s probably when it occurs least often. It’s much more likely during wide forays and broad searches, the kind that are so easy to do with current technologies.

If Enterprise 2.0 was totally here, Andrew’s point would have been absolutely on the target and any pilots would not have been representative of critical mass needed to trigger  and prove the exponential dynamics of interaction evident in online community . But, in my view, Enterprise 2.0 is not exclusively serendipity.

Looking at my Enterprise 2.0 Framework, developed from McAfee’s Bull’s Eye, it should be clear how more than the strength of ties between participants, what makes a difference are the goals and needs a project is launched for:

If collective intelligence or emergent non-codified expertise are certainly two of the most original contributions introduced by Enterprise 2.0, allowing people to connect, stay in touch, collaborate asynchronously, leaving traces of partial outcomes and maximizing the reusability of these assets over time, should not be ignored at all. In my experience these are among the most frequent scenarios in small and medium enterprises (most of the Italian and European markets).

That’s why I believe broadly discarding pilots as useless or not effective towards large-scale adoption may introduce major drawbacks:

• Losing sight of the relevant benefits Enterprise 2.0 provides at the team, group and department level  (at least 50% of the diagram above)
• Introducing harmful fears and resistance among the management in terms of budget, risk, exposure to negative publicity
• Raising political and organizational problems even before showing the effectiveness of participative approaches, because if the project is not a pilot then all business functions must necessarily be involved from the very beginning
• Giving up the chance to start from the bottom up, identifying concrete problems in different parts of the organization and involving people as owners of the project.

All these risks could simply mean jeopardizing again that widespread adoption that we want to achieve avoiding pilots

So what is the most effective approach to launch and nurture an Enterprise 2.0 project that is targeted to the entire organization?

I believe a general answer simply does not exist and that the best way to go should depend on the objective (and type of need even before that) you want to address. If a small group is entirely appropriate if you look at collaboration, to address the other levels of the diagram you should actually reach critical mass but while for collective intelligence numbers are necessarily important, for the intermediate levels starting even with 30-50 people could be actually enough.

Much also depends on the severity of organizational, cultural, geographical barriers among participants in the pilot. Stronger the barriers, greater the value generated allowing people to work together. Additionally, much care should be put while considering the position and reputation of the people who are going to take part to the pilot. Intentionally selecting the right influencers, connectors and trusted sources of informal exchanges will dramatically facilitate how adoption is spread reducing both the time and effort needed.

Pilots or not? As you can see, guidelines, patterns and best practices are slowly emerging and we surely need to take them into consideration. On the contrary I believe it’s much better avoiding generalization here. So my answer is.. it depends!