Signals instead of conversations ?

Summary :  enterprises will have to enter the world of conversations. Everything will become conversations between enterprises, employees and customers. Such a concept, when not introduced the right way, is scary for lots of businesses because it overlooks the need to make conversations actionable. Most of all, employees are very uncomfortable with the conversation attitude at work. A matter of attitude but also a matter of sense, organization, time, tools…and a human matter full stop. The business world is more in need of signals contributing to ambient awareness than of conversations. Conversations can follow the signals but are not indispensable. In the current state of maturity, employees are more comfortable with factual signal logics that may lead to conversations than with conversations as a direct model. As a matter of fact, even if  ”markets are conversation” , it’s time to realize that organizations are not market (for the moment ?). And customers seem to prefer results and factual interactions than social conversations.

Tomorrow, everything will be conversations. The web will all be made of conversations between businesses and customers and intranets will be nothing more conversations between employees. Business need to join the world of conversations and facilitate conversations between and with anyone. Of course, in the small world of initiated people, everybody understands what hides behind this simplistic shortcut (although…). But, when held in front of “real” large businesses and decision makers, this discourses often sounds irrelevant.

Of course, we can argue the these businesses rely on old frames of reference and did not get the new world that’s emerging. This is true, even partly, but does not explain everything and should not be the easy pretext that prevents from having a critical look at the content of some concepts and the way they’re introduced.

Let’s take a few minutes to put ourselves in any executive’s shoes. Imagine a business world where everyone would spend his time having conversations. The first thing that comes to you mind is : lower productivity, people loosing time chatting. Of course…such a thinking shows the person do not understand the “new world”…but, in some ways, it’s not totally wrong. Engagement and conversations share the same problem : they’re worth if actionable. In other words :

- they are part of concrete frameworks (marketing, innovation, customer service, problem solving….) and not a plan saying “converse, converse…and maybe, sometimes, we’ll manager to leverage it for business purposes”/

- they relate to an empowerment approach : conversations expose involved employees to an external stimulus that should, in most of cases, be followed by an action. If the employee is not able to take any action following the conversation, the conversation is useless and may even be deceptive for those who participated. Even if the only benefit of the conversation is related to knowledge acquisition, employees need to be able to use this knowledge in their work in the future and not be locked into logics focused on strict use of previously validated and official knowledge.

But this is not all. Conversations means a series of exchanges overtime, the willing to exchange with or without predefined purpose. So businesses started to focus on one goal : stimulating conversation. They need to make people talk the one with the other. This job usually falls to the community manager. Now let’s see this with a little distance to realize how absurd it is : if we want people to have conversations and they don’t do, do you think, even a second, that, with all the tools they already have, an internal social network (for employees) or external communities (for customers), animated by a community manager who’s mission is to make people talk will change anything ? If conversations have neither sense nor interest, the best tools and community managers won’t change anything. The problem is elsewhere.

[Read more...]

Does enterprise (2.0) need a pilot ?

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