Interesting conversation last week last week on twitter with Hutch Carpenter and Gil Yehuda about how long Enterprise 2.0 adoption takes. This question is a real concern for many enterprises and, even if there’s no mathematical formula to help them to find an answer, maybe we can gather a few elements that may explain the mechanisms that make things happen more or less quickly.
First, I think it’s important to make things clear about what we mean by “enterprise 2.0 adoption” and go into what may accelerate or inhibit adoption.
What does “enterprise” mean ?
Are you a 50 000 employees company or a 50 people business ? It changes many things. Not because it’s more easy or difficult in any case but because the time things take to spread will not be the same. As the time needed for “preparation” because such projects need to be prepared beforehand. Saying “tools are there, enjoy !” is not enough.
In the case of a large business, are we talking about global adoption or adoption within a department. Which also leads to strategic issues : global mutation or small project proliferation, hoping the dynamics will spread.
What “adoption” mean
Here again, it’s important to know what we mean. Having tools at people’s disposal takes little time once the decision is made. Having these tools used on a wide scale takes more time. Creating value using these tools takes a little more time if things were well conceived, much more if not.
According to me, what must be aimed at is tangible value creation even if activity is a good indicator. The second will never come without the first, but we have to be conscious that if activity is the goal, things may quickly fade away to nothing when investments will be reassessed according to their ROI. Value needs activity but continuity needs value demonstration.
Depending on what adoption mean for you, you may say that it tool 3 years or 3 months. 3 months to launch the first pilots, 6 to get the first business successes, 1 year for a global deployment, 3 years for a global mutation. These numbers are only examples but they are coherent with the reality of many companies.
Visible and hidden time
“Things need time to happen quickly”. If you try to copy companies who “did” it, don’t forget you have to add the time that was needed before all the visible part of the project started. The hidden time used to make things possible. Of course, we’re not talking about an ERP deployment and it’s not about years or many months, but it must not be forgotten. Keep in mind that when companies get tangible results, whatever the scope is, it took time, beforehand not to decide whether to try it or not, but to wonder how to get rid of all possible barriers.
Adoption boosters and inhibitors
I can see three levers that can make your way longer, or quicker.
• Culture
Once again ! Does your company have the culture of experimentation, of discovery ? Or is it conservative and noveltyphobic ? It will surely impact the adoption duration and the needed efforts.
Rather hierarchical and “command and control”. It matters too. The problem with highly hierarchical structures is the incapacity to let people take initiatives. In the other hand, if the top of the pyramid consider change as a strategic issue and teach by the example, things may go very fast.
People’s culture plays its part too. I talked about that a few weeks ago with Martin Koser about Germany and I will go more deeply into it later, and that’s true that you won’t get the same results in the same way depending you work with people from Germany, France or the US. It can even be worse, if you try to launch cross-country initiatives. I remember of a group of French, Spanish and east european people who couldn’t even agree on the language to be used. I don’t even mention the political issues between the headquarters and its newly acquired foreign subsidiaries. A very indigestible cocktail !
• Project size
Do you wan to get all your 80 000 people in at once ? Do you prefer to go team by team, department by department ?
Both have their positive side and their limits. In the first case you are sure that everytime a need emerges, all the “right” people will be able to be involbed in. But if you don’t let communities, groupes, form depending on needs it will be hard to go further. More, you need everyone to be comfortable with the tools beforte you stard…and it may take a long time. You also have to be aware of the inertia that is proper to large groups in search of sense.
In the second case the start may take a very little time and adoption come quickly. But one limit may be reached if you have to involve other people later, people out of the population that was targeted first. “We found 10 people we must bring with us”. “We bought licences for your 50 people…all are used. Sorry”. The other kind of issues that may happen with such projets is that they are usually supported by a BU, a departement, and nobody want to pay for people from another team, what is a real barrier to cross-functional projects. Who said that cost allocation was a barrier to effective collaboration ? My third point is that you will ask people to work in a “2.0” mode with some of their colleagues, while they still work “1.0” with the rest of them. One day gravity will make them prefer the tools that are used by everybody, the lowest common denominator.
• Alignement / shared goal / Community-ship
Tools aren’t sensemakers by themselves. They are used because they make sense regarding to their purpose. Without shared goals, without being conscious that the goal can only be reach in a “social way”, and if internal rules and management makes it logical for people to play the one against each other and not the one with the other, you may have to wait a long, long time before anything happens. So it’s better to start where sense exists or take the necessary time to make it emerge.
Example : a company want to empower community of experts with its foreign subsidiaries. But there are no shared values, they don’t feel they belong to a group and the subsidiaries consider each other as competitors. According to you, what happened ?
The Yeahuda’s Theorem
Gil proposes us a formula that’s not that bad: a year + a year per each 5K employees.
I like this concept that assumes that some time is needed to build a common basis, to learn a new paradigm, a time to launch pilots and learn from successes and failure, and then that time is needed to spread.
I would only tone down about one point. For a 50 000 people company, it would take…11 years. According to me a kind a degression has to be taken into account : the last 5k will need less time than the first.
Whatever, the idea that there is a fixed + varible duration sounds good to me. Maybe the variable duration depends on the company’s size and the way accelerators and inhibitors were addressed. Something that would be worth doing deeper into but that will remain rough : since a project involves behavioral changes, it’s hard to make plans. Beware of anyone tells you the contrary.
So enterprise 2.0 adoption needs…a certain time. But this time can be reduced by :
• dealing with inhibitors
• adopting the right strategy. Beyond the “academic” side of the global vs department projects discussion, there is a real impact on adoption. Cisco did global ? Ok…Cisco is Cisco and if the logic has to be learned, the strategy depends on the company, its culture, its context. What’s good with global projects is that it prevents from issues caused by department projects that may have their own tools, what matters for continuity. What’s good with department projects is that things can happen quickly and that it’s easier to find shared goals. Experience teaches us that it’s often the best way to be successful. I fully agree with that even if it’s always possible to find businesses with the right DNA to tackle things globally.
According to me both approaches don’t have to be set one against the other and there’s a way to make things more easy, more “fluid”. A global framework has to be set at a corporate level, same tools available for all from the start. Then department projects have to be looked for. Their success will help teaching by the example, spread best practices and their proliferation will help to grow from “departments 2.0” to “enterprise 2.0”. Then, rather than thinking “E2.0” or “Dept 2.0”, think “Department 2.0” on an “E2.0” framework.
What takes us back to the first question. For a large business, I’d say :
• 6 months to build a corporate framework : choose tools, first pilotes, learning from successes and failures, identify which services / support / ressources have to be provided internally. It may take one year depending on the corporate DNA.
• 6 months to find and launch the first department projects and get tangible benefits.
• Then generalization. Here we will use Gil’s formula. Best practices learned in the previous months are industrialized.
