It started with this provocative post from Michael Idinopulos. His message is quite claire : assuming that enterprise 2.0 relies on networked interactions, that these interations need a critical mass of users not only because of Metcalf law but also because, by definition, it’s impsossible to know at the beginning  who will be needed in the future, he concludes that in a enterprise 2.0 perspective the usual pilots makes no sense and does not allow do demonstrate anything.

His take led to many reactions, even if no clear answer emerged (read Steven Walling’s post, the comments and the results of his poll). At the end, it seems that even if a discovery or learning phase is important, not everybody agree on how it should happen. Said differently, everybody agrees on the big picture but opinions diverge on details or on the meaning of things.

What’s a pilot  ?

What’s a pilot ? It’s a project which goal is to test in a riskless context and a small scope the key points of something that is expected to be deployed on a wider scale in the future. I’d rather say that that’s how people generalized the content of a pilot. If we focus on the real and primary goal it’s about validating something new, learning to master it, understanding its potential, the risks, the limits. Regarding to many things that happened in the pas, this definition was relevant because the only thing that differenciates the pilot from the full deployment is the scale. In a system relying on transactions, if a system, a processus, works for 10 people it will work for 100, 10 000 or 100 000, the only thing to do being to scale the infrastructure.

Conversational or transactional ? Two different logics

What’s new in enterprise 2.0 projects, if we consider the IT side, its the human dimension, not mutch transactional, not foreseeable, and the fact it relies on a people network. In other words, that’s not because something works with 10 or 100 people that it will work with 10 000. And the most frequent situation : something that does not work with 10 or 100 people may perfectly work with 10 000. If the web had only 1000 users, the social networks as we know them may not exist, the probability for a given personne to find his own network, people who share the same concerns being very low.

There’s also another point that is far from being trivial : a transactional application can be tested with blanks, injecting datas and looking at what happens. A conversational application can’t be tested in a sterilized room, disconnected from the operational reality. Isolated from the day to day concerns in order not to impact anything, it can’t provide with any clue or certainty about its future use or efficiency.

Il existe également un autre point qui est loin d’être anecdotique : on peut tester une application transactionnelle “à blanc”, en lui injectant des données et voyant ce qu’il en sort. Une application plus “conversationnelle” ne peut être ainsi mise en salle blanche, déconnectée de la réalité opérationnelle. Isolée des préoccupations quotidiennes de manière à ne rien impacter, elle ne peut donner aucune preuve ni piste quant à son utilité et son efficacité future.

So the goal of a pilot applies to enterprise 2.0 (at least to its software component) but the method should certainly be changed to fit the specificity of 2.0 applications, most of all in terms of scale and positioning toward day to day business issued.

A good synthesis of what a pilot should be in such a context can be found in Claire Flanagan’s comment. A comment that gains a special dimension when you know the results of the pilot she’s currently leading.

A pilot is not an explorer

A pilot aims at validating, refining the understanding of a problematic and improve the tools to…pilot things once the project will become mainstream. In our context it means that there is a critical mass of users and that the pilot is not isolated from the real work. It implies that people already have a quite clear understanding of what the project is about, what it will be used for, what are the preliminary changes to undertake and those who will follow.

When a pilot is restricted to a few people and is help apart the real life, it’s often because people don’t know what they are doing, what tools do and don’t do, what will  be their impact, what they help to change and what changes they need. It’s a discovery phase of tools and concepts, without anything operational, that won’t help to prove anything. Such a project is not a pilot but rather an explorer, and its purpose is to do the spadework on the subject. Its a key element of the necessary (and too often forgotten) strategic thinking phase but it’s not a pilot in any way. And when you expect from an “explorer” the same things than from a pilot, their are many chances to be very disappointed.

It taking the specificities of the 2.0 paradigm in a pilot is key, it’s also very important not to call a pilot the necessary discovery and exploration phase, which purpose is to open up before launching a pilot, in order to understand things and prevent from doing mistakes later.

You my also find Steward Mader’s takes interesting..

adoption, changement, conversationnel, conversations, Entreprise 2.0, expérimentation, périmètre, pilote, réseaux-sociaux, transactionnel, transactions