What do you do when a wiki pilot succeeds? This is a question I'm hearing more and more. Usually the conversation goes something like this: "We launched a wiki pilot. It went great. Everyone in our group uses the wiki. We can't live without it. We'd love to see the rest of the company follow our lead. But...they're not."
In theory this shouldn't be happening. According to most theorists of social software, getting started is the only hard part. Once a pilot is successful, viral adoption and network effects are supposed to take over and ensure broader uptake, just like the old "and she told two friends" shampoo commercial. (BTW, if you have a URL for that commerical online, please post it!). Stewart Mader, for example, describes it this way on his blog:
Dwight is compiling his quarterly marketing report with his teammate, Jim. He and Jim use the wiki to add their respective statistics and compile the department's report. However, when the report is complete, it must be submitted to their manager, Michael, who will have comments. Rather than emailing the report to Michael and then manually incorporating Michael's changes, Jim realizes it will be far easier for him if he has Michael do it directly to the wiki document. Michael, in turn, has to submit the report to the regional director, Jan, who will have her own changes. So Jim signs Michael up for the wiki, and then Michael gets Jan to use the wiki. It can expand even more widely from there.
Stewart has a good example, but it misses the fact that adoption has a natural stop. If Dwight and Jim are working together on the wiki to create a departmental report, it's very easy for Michael to join them as long as Michael is working on that same report. But what about Mary, who isn't working on that report?
When wikis are used in-the-flow, they have natural boundaries beyond which adoption does not typically spread without help. If the Marketing group uses the wiki to research and write reports, then adoption of that wiki will probably end with the Marketing group (and maybe a few interested outsiders.) It's not a silo thing; it's just that when people use wikis to work together on an activity, that wiki is not usually interesting or accessible to people who aren't engaged in that activity.
This doesn't discredit the notion of viral adoption. But when we think at the level of the enterprise, rather than the pilot, we need to think about virality differently. Rather than viewing virality as the extension of existing wikis and use cases to new individuals, we need to see it as the extension of wikis to new use cases (and, by extension, individuals).
Just to put a name on it, let's call this "Use Case Virality" and contrast it with "User Virality". User Virality is when users pull new users into existing wikis and wiki-enabled collaborative activities. Use Case Virality is when users extend existing wikis or create new ones to support and enable new and different collaborative activities.
What I'm saying here, and what I think a lot of the standard talk about virality and network effects misses, is that User Virality all by itself does not generate enterprise-wide adoption. User Virality may result in some nice, contained pilot successes, but in order to go enterprise-wide you need Use Case Virality as well.
I agree that there will be an ebb and flow of activity as one project winds up and another starts. The wikipattern of one wiki per group available off a company or division homepage seemingly would feature many interesting things going on around a company. It's the network effect at work if done well.
Posted by: Dan Smith | July 01, 2008 at 03:37 AM
Dan, I completely agree. The challenge is that each new project is a new project. Network effects are relatively easy to achieve within a project. I'm interested in how to ensure that there are, as you say, many interesting things going on around a company. It's achievable, but it's a different type of virality and one which in my experience is harder to achieve.
Posted by: Michael Idinopulos | July 01, 2008 at 10:21 AM
I have already been involved with enterprise scale adoptions of collaborative solution and, from that experience, can confirm that lack of integration, or a broad vision of success, will limit an adoption to small groups who view the need only locally.
Take a look at my quick presention regarding adoption models. http://kevinshea.typepad.com/kevin_shea_process_collab/2008/07/enterprise20-ad.html
Posted by: Kevin Shea | July 14, 2008 at 10:58 AM
Kevin,
I looked at your presentation, and I think your MIP model is spot-on. My interest is in the organizational scalability of the MIP model. A single insertion point can happen on the strength of one individual or a random flash of insight. But to get MIPs, you need an institutional capability to make it happen. What examples have you seen of companies successfully building those institutional capabilities?
Posted by: Michael Idinopulos | July 14, 2008 at 10:16 PM
Michael
I am a consultant in this area and have been directly involved in institutionalizing solutions. My observations are based on my experiences and the ability to compare and contrast different adoption/execution models within the same very large company. My approach is to use a process approach, set up a basic framework, install a user agreed upon structure and let people at it. Then monitor, manage and adjust as appropriate.
The controlled MIP model reflects an organized approach to introduction, while the SIP is what I observed happening as IT simply released the app. What happening in the SIP model was that everyone saw the benefit, and as a result, moved rapidly to the tool. However, all they did was to mirror the existing poor process, and in the end, all they got was the same mess they started with. Much of it was quite isolated.
The MIP model developed more slowly. It was held back in a way to develop interest. The initial architecture was designed to be full scale, with a long term vision. It was intended to be highly integrated (far different than that SIP model), and serve 1000’s of users.
A SIP model may work in a small company, but I do not envision it being sustainable in the large scale operations. I do not accept Prof McAfee premise of the emergence (SIP) model in large companies. I think the examples at CIA, Pfizer, and others will point to this as well.
Kevin
Posted by: Kevin Shea | July 15, 2008 at 09:00 AM
Michael
Here is a question to ponder while considering the idea of institutionalization. If people want to lead from the bottom, then why do they suggest that support from management can be key to success?
Kevin
Posted by: Kevin Shea | July 18, 2008 at 02:52 PM
Kevin,
I don't see leading from the bottom and top management support as an either/or thing. Lasting organizational change requires both. Workers on the front line (i.e., the "bottom leaders") are the only ones close enough to the work to make real innovations, but management (i.e., "top leaders") are required to sustain the innovations and to make sure that they are replicated across the organization.
Posted by: Michael Idinopulos | July 28, 2008 at 04:27 PM