« The Five Forces of Enterprise 2.0 Adoption | Main | Launch E2.0 Broad, Then Go Deep »

August 27, 2009

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00e54fa4700a88330120a5281601970b

Listed below are links to weblogs that reference Enterprise 2.0: Skip the Pilot:

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Emanuele Quintarelli

Hi Michael,

I can surely see your point and I do believe size matters as well but I can also hear many of my clients hoping to dip their toes gradually into a new way of working and conceiving their business.

As I said scale matters but not in an absolute sense: in my experience what you really need to guarantee is a meaningful group to create value and make the system scale later on. This doesn't necessarily mean involving the entire company from day one and for example you can work cross departments simply focusing on the right people in a 40-50 users group (taken from marketing, pr, communication, etc). To guarantee the value, you need to carefully select the right people (for the size of their network, their expertise, the trust and credibility, leadership, the department they are working into, etc) and to nurture that group while gradually learning and inviting others to join.

A final point: the right size probably also depends on the kind of scenario you are thinking of. Collaborative authoring could work in a single silo, capturing collective intelligence is clearly quite different. Again this could mean 30 people in a 150 people company or 1000 people in a 100K people company, but it's still a pilot, isn't it?

To me it's not doing the pilot or not going for it. The key is doing the right kind of pilot. Choosing the right size, the right people and cultivating them with love and patience could still make the trick :)

Chris McGrath

Hey Michael,

Thanks for the reference to my 8 Tips on Pilots article, and for the thought-provoking article. You make some good points.

I have two issues to take up with you:

1) The no-pilot recommendation is self-serving. You're a software vendor. I'm a software vendor. In all seriousness, I really wish people wouldn't pilot our software -- I wish they would just *buy it*! Means more revenue, sooner. But because no-pilot is better for vendors, your post could be biased.

2) Metcalfe's Law. Some feel that Metcalfe's law isn't applicable to social networks, but rather tends to greatly overvalue them. Is the value of the network really equal to the square of the number of nodes? A contrasting view is the n(log n) rule, which surmises that the second most important person in your network will have half as much correspondence with you as the most important person, the third most important person will have one third the correspondence, and so on. These and other laws are discussed in nauseating detail in this post by Bryan, our analytics expert: http://www.thoughtfarmer.com/blog/2009/04/27/intranet-roi/

At the end of the day, I hope you're right, because I'd rather sell a 10,000-user enterprise license to our software than a 100-user pilot. Do you have any ideas on how we could prove your theory?

Michael Idinopulos

Chris, thanks for your comments. I have a lot of respect for Thought Farmer and for your blog. I'm happy to be having this conversation with you.

Once you understand Socialtext's business model, you see that my no-pilot recommendation is not at all self-serving. Socialtext is a SaaS (Software as a Service) company. Our up-front fees are lower than traditional software vendors, and our revenue comes disproportionately from customer renewals beyond the initial contract period. A customer who buys and fails is actually worse for us than a customer who doesn't buy in the first place. So it's not at all in Socialtext's interest to sell a new customer based on an approach that won't deliver long-term success.

My objection to pilots comes from years of E2.0 implementations, first inside McKinsey & Co, and subsequently with hundreds of Socialtext implementations. Like you, I used to recommend small-scale initial pilots. But over time I noticed that our most successful customers consistently launched on a larger scale than our less successful ones. That led me to question why small-scale pilots weren't yielding better results.

We could argue over the details of Metcalf's law and the precise shape of the curve that describes the relationship between scale and value--logarithmic, exponential, whatever. But it doesn't matter. The point here is that a group of 50 and a group of 5,000 will adopt the tools in completely different ways. The 50-member group will focus on "closure" activities across strong-tie relationships (e.g., meeting notes, document co-creation, etc.) The 5,000-member group will focus on "brokerage" activities (social networking, micromessaging, expertise location) across "loose tie" relationships. (For more on Brokerage and Closure, see my post http://michaeli.typepad.com/my_weblog/2008/12/brokerage-and-closure.html)

It's silly to think that a 5,000-person rollout is just a 50-person pilot expanded 100x. I think most people would agree. And yet many companies base go/no-go decisions on small-scale pilots. As I've argued (see link above), brokerage and closure activities are both important. They're also mutually reinforcing. If you just focus on small-scale collaboration, you're missing more than half the picture.

Chris McGrath

Michael, you make a good case. I really appreciate the distinction in use cases in your Brokerage & Closure post, too -- it's an easy-to-understand articulation of some difficult concepts.

Practical question for you: How is E20 ever going to go mainstream if it requires massive deployments? I'd hate to be the person that convinces their company to make a million-dollar leap of faith, only to have a full-scale rollout languish. Shouldn't we strive to show tangible benefits at all levels of deployment?

Amy Senger @sengseng

You fail to acknowledge that pilots can afford the Enterprise expediency in getting the solution out quicker b/c they can circumvent some of the rigmarole of IT and security politics, red tape, bureaucracy, etc. This agility can be key, esp when the solution significantly challenges current business operations and tenets. You can implement a pilot fully scaled to include your entire customer base but still take advantage of the flexibility that the label "pilot" or "beta" allows.

Robert Fransgaard

Interesting view. The more I think about it the more I find myself agreeing with it.

For a web community/forum/group I would always aim to get that little core group in place first, the pioneers who will become your ambassadors, but for Enterprise including as many as possible makes sense to me.

However, a pilot may still be a feasible option, but instead of limiting the amount of users maybe a better way is to limit amount of functionalities as this would A) create a limitation on the pilot; B) introduce the whole concept to the users one step at a time; and C) gives a more agile environment to develop the structure based on user feedback.

The comments to this entry are closed.

My Photo

Twitter Updates

    follow me on Twitter