When an organization tries to embrace something new, the first steps are made in a very cautious way and that’s logical. Even when there’s a clear idea of what is being done, things have to be tried on a small scale to validate some things, compare the plan and the reality. I don’t even mention cases when something is tried without having any idea of the purpose and of the possible benefits that can be expected.
This applies to many things and enterprise 2.0 is not an exception. So, even if this post will be more about this topic, many things can be generalized to other fields.
I won’t rewrite the debate that took place last summer about knowing if this preliminary steps made sense or not. As a matter of fact, when a critical mass is needed, a smaller scale may made this steps more or less relevant. In concrete words, the question is about :
1°) Knowing what is being done
2°) How it’s called and explained.
1°) What is it about ?
There are two possible approaches.
The first is to test something on a very small scale to see if there’s anything to get something out of it and how to scale it. If nothing happens, the test is shut down. The upside is that it makes it possible to test many things, in the only purpose of “seing what happens”, the dowside is that, in case of failure, the baby is often thrown out with the bath water and nothing is made to understand the causes of the failure. In the Enterprise 2.0 case, we also have to consider the need for a critical mass (what may seem contradictory with a small scale test) that can be sometimes replaced by a hard work on sense and alignement, this second point being sometimes too heavy to be implemented in this kind of context. I’ve heard, a few years ago, someone telling me “we’ll work on sense and alignement only if the experimentation is successful”. Astounding. Anyway, in this approach there is often a limitation on both duration and number of participants.
The second is to limit the duration but not the number of people. The underlying assumption is that if, logically, what’s being tested should bring some known benefits and that these benefits don’t come, it’s not because the idea is bad but because it’s not been implemented very well. The the purpose is not to decide to carry on or not but to learn what will be needed to drive the program at a wider scale later. To illustrate this point I often mention cars as examples : if a car does not function it’s not because the concept of a car is bad, but because either the fuel is not good, the transmission is brocken or the engine is not well set. For instance, CSC is a good case (I briefly mention it there) : more than 20K users decided to join deliberately and the preliminary phase was used by the company to learn in a “real” situation before scaling.
2°) How the project is explained
Things would be simple if wording was not an issue. That’s true in France where we can spend ours discussing a concept and its name before knowing what it means in the facts, but I’m sure it also happens for other people : that’s not because one know what he means by using a word that the one who listen won’t understand something different.
The two above mentioned approaches are often called “pilots” or “experimentations”. Both of these words can apply to any approach but, in general, the first approach is often call experimentation and the second pilot. But it’s not that easy when it comes to explaining it to final users since they are the ones we need to get onboard if we want the project to be successful. The word we use are not neutral at all.
Experimentation wears its name very well. “Try and see”. It’s hard to be more repulsive while trying to engage employees who don’t have time and are searching for sense. We can be sure that employee will think, even unconscioulsy “I’m fed up with all their crazes…I won’t buy before it’s definitive and official…no time to waste for something than can be shut down at any time…being a part of it may expose me and it may be a bad idea if the project goes wrong”. I already heard an employee saying “experimentation…do they think we are guinea-pigs ?”. Explaining that the experimentation is not “on” them but “with” them is easy…but never happens. Anyway, we must be aware that this word means lack of visibility and indecision, what is not reassuring when trying to engage employees.
Pilot means that we’re opening the way, that others will follow, so that the first who’ll jump in will be forerunners the organization will recognize, support and reward, what is positive. In the other hand, employees can also think that “everything has been decided, nothing will stop us and you opinion does not matter”, what looks like the usual one-more-top-down-project they don’t believe in anymore. What’s important is to explain them that the direction is know but that the path will be decided with them, hence the pilot. This is the opposite of the previous situation : the company know where to head to but must be aware of not being too directive or interventionist.
You won’t be surprised to know that my favorite option is the second one. Anyway, organizations must be aware of the impact of how they communicate around the project to make it more engaging than repulsive. Sometimes, the success of a projet depends on what happens beforehand, in the antechamber.
