This post is perhaps a few days late but it’s something that I have been thinking about ever since Andrew McAfee wrote that organizations needs to “Drop the Pilot” for their Enterprise 2.0 initiatives. Now before you take sides here let’s think this through and see what makes sense. According to McAfee:
“I believe these kinds of pilots are unintentionally set up to fail, or at least underwhelm. This is essentially because they contain too few people, most of whom know each other too well. The more I learn about and think about the value of emergent social software platforms, the more I suspect that the deep meta-benefit they provide is technology-enabled serendipity, defined as ‘good luck in making unexpected and fortunate discoveries.’ Serendipity is possible when we’re collaborating with our close colleagues on a well-defined project, but that’s probably when it occurs least often. It’s much more likely during wide forays and broad searches, the kind that are so easy to do with current technologies.”
Andrew’s argument is essentially based on comparing the risks associated with E2.0 failure vs. the serendipitous benefits of E2.0. …
This post is perhaps a few days late but it’s something that I have been thinking about ever since Andrew McAfee wrote that organizations needs to “Drop the Pilot” for their Enterprise 2.0 initiatives. Now before you take sides here let’s think this through and see what makes sense. According to McAfee:
“I believe these kinds of pilots are unintentionally set up to fail, or at least underwhelm. This is essentially because they contain too few people, most of whom know each other too well. The more I learn about and think about the value of emergent social software platforms, the more I suspect that the deep meta-benefit they provide is technology-enabled serendipity, defined as ‘good luck in making unexpected and fortunate discoveries.’ Serendipity is possible when we’re collaborating with our close colleagues on a well-defined project, but that’s probably when it occurs least often. It’s much more likely during wide forays and broad searches, the kind that are so easy to do with current technologies.”
Andrew’s argument is essentially based on comparing the risks associated with E2.0 failure vs. the serendipitous benefits of E2.0. Finally Andrew puts together his simple high level E2.0 roll out plan:
- Deploy tools that deliver a novel capability, like microblogging, social network formation, or prediction markets. Tools that deliver something novel — that aren’t trying to displace an incumbent — avoid the 9X effect.
- Make sure the tools are frictionless, freeform, and emergent. This lowers barriers to participation and altruism.
- Give them to everybody with just enough policy-setting to satisfy the people who concern themselves with compliance, risk, and security.
- Get a group of both formal and informal leaders to be heavy initial contributors. They’ll draw in others quickly.
- Monitor usage over time and make adjustments if and when necessary (for example, if conversations descend into flame wars or anyone’s tone becomes inappropriate or unprofessional).
- Collect examples of the good stuff that happens. Use these to justify the project, satisfy the sponsor / boss, and evangelize.
On one hand, I really like the simple approach that Andrew is taking because as I’ve stated several times, I think we tend to over complicate things and perhaps scare companies that are interested in E2.0. I’m not going to comment specifically on his six step roll out plan because that’s an entirely separate discussion. Now having said that, we also need to look at what exactly a “pilot” project is or can look like.
In my opinion, a pilot project can be one of several things:
- A broad deployment of a strategy or technology over a specific period of time (i.e. we will push it out to the company for six months and if it doesn’t work we pull the plug)
- A deployment across a specific geographical location or department that is justified prior to broad organizational deployment
So in my opinion broad deployment can still be considered a pilot project if we limit the shelf life.
Now the question comes down to whether or not it makes sense to start off with a pilot project or just go for broad mass deployment. There have been good cases made for both dropping the pilot and for keeping it. I think the reality of the pilot program depends on the organization. However, Andrew is right, for serendipity to occur we usually need large/broad scaled networks that connect mass groups of people together and if you launch a pilot program to let’s say 100 employees, chances are that the serendipity factor is going to be minimal. But, why does an E2.0 pilot need to hinge on serendipity to begin with?
Let’s say an E2.0 pilot project doesn’t see any type of serendipity effect at all, there are still plenty of other useful things that a pilot project can do such as:
- allow you to efficiently store and manage product and process information
- allow your team to work more seamlessly and share information with one another efficiently
- allow you to test the technology challenges and then develop solutions before implementing a broader launch
- reduce the amount of duplicate content
- reduce the amount of time spent in email which will hopefully improve overall productivity
- I’m sure you can think of others
The point of a pilot project is to demonstrate some sort of business value to the organization, so why not start there? For example if your engineering team is having a heck of a time storing information to train employees, why not launch the E2.0 pilot project there and see if it helps the problem? I did a case study on Vistaprint where they were able to decrease the onboarding time for an entry level engineer by almost 50% just by using an internal wiki that housed relevant and updated information for newly trained engineers. Sure the serendipity effect wasn’t there but the value of their pilot was clearly justified.
What’s interesting is that every company that I have spoken to so far has two things in common:
- Their E2.0 initiatives did not start from broad adoption (they were more pilot based)
- Each company has a corporate culture that encourages employees to innovate and try new things; they are given the time and resources to do so
In my opinion a corporate culture that allows for employees to test and try out new things is almost a type of pilot project in itself. The folks over an Intuit for example (I’m currently writing up their case study) launched their internal ideation platform as a result of their 10% free experimentation time (I believe Google does 20%?). The folks over at Oce branched into E2.0 because they were encouraged by their organization to find new solutions to old challenges, and so they did. Vistaprint needed a more efficient way for one of their departments to come up with new ideas to deploy to their customers and also needed a solution for their engineering team to manage information.
I think broad deployment across an organization can also lead to chaos if not done properly. Now having said that I think there is merit and justification for both but the corporate culture can play a huge role in deciding which approach to take. There is more to E2.0 then the serendipity effect. If you start with a pilot project then start with solving a business challenge, serendipity will come later.
So again, I’m not biased towards one side or the other but I do think it’s a very interesting discussion to have. What do you think? Start with a pilot project or go for broad deployment across the organization and leverage the scale and network of the employees?
Here is a collection of 50+ Enterprise 2.0 Case studies and examples I have compiled
In depth Enterprise 2.0 case study on Océ
