Get out your pitchforks, I'm about to commit Enterprise 2.0 heresy.
There's an orthodoxy in Enterprise 2.0 circles about how you're supposed to run an implementation. The orthodoxy goes something like this: Start with small-scale pilots, define your business objectives, watch the pilots closely, evaluate their success, make a go/no-go decision. (A good recent articulation of this view is in Chris McGrath's post on 8 Tips for a Successful Social Intranet Pilot.)
As far as I can tell it's what everyone thinks. In fact, it's what I used to think. Unfortunately, it's dead wrong. The orthodoxy is wrong for a very simple reason: Size matters. By constraining the size of your pilot, you significantly alter the way your company can and will use the tools.
I'm not opposed to pilots for most enterprise IT solutions. Companies like to pilot new technologies with small populations before they roll them out enterprise-wide. That approach makes a lot of sense for transactional systems like order management, project management, purchasing, ERP, and so on. By piloting with a small group, you reduce implementation risk. You get a read on the value of the solution, and you get feedback which you can use to make modifications while those modifications are still relatively easy and inexpensive.
But social software is different from traditional IT. Traditional IT enables individuals to carry out well-defined, highly standardized transactions. Users go into the system to process transactions--to transfer funds, purchase supplies, track inventory, etc. The nature of these transactions, and the system's ability to enable them, do not vary much according to the number of people using the system. Whether 100 people are entering orders or 10,000 people are entering orders, the transactions themselves doesn't really change. What that means is that a representative small-scale sample is an accurate predictor of adoption and value at full scale.
But Enterprise 2.0 tools are different from traditional IT systems. Traditional IT enables transactions; Enterprise 2.0 enables interactions.
Interactions and transactions have completely different scale economics. When we use Enterprise 2.0, we're not transacting with a system; we're interacting with other people. An interaction is a connection between two or more nodes in a network. And as Metcalf's Law famously states, the more people there are in that network, the more interactions each individual can have with his or her peers, and the more value that individual derives from participation in the network.
When companies pilot Enterprise 2.0 tools with small subsets of their organization, they're not testing collaboration with a representative sample. An artificially constrained pilot is always a poor representation of post-pilot collaboration, because the range of potential interactions is so limited. The value delivered to each individual participant is exponentially smaller than it would be at full scale, and the ways that people will use the tool are different.
That doesn't mean small-scale Enterprise 2.0 pilots can't succeed. They can, and many do. But even when pilots succeed, they have limited ability to predict how the organization goes on to use the capabilities once they are rolled out enterprise-wide. Pilots typically fall into the lower left-hand corner of the Social Software Value Matrix: improve existing interactions within existing silos. That includes things like project team workspaces, departmental workspaces, and technical knowledgebases. When organizations really embrace Enterprise 2.0, however, they almost always play in multiple sections of the Value Matrix, launching solutions like collaborative intranets, ideation portals, private extranets, Those solutions, almost by definition, require scale.
Scale is the oxygen that feeds collaboration. That's why collaborative tools like Facebook, and Twitter have taken off so spectacularly on the public web: With over a billion people on the Internet, the opportunities for interpersonal interaction are unbelievably high.
From a practical standpoint, this has a counter-intuitive implication: If your E 2.0 pilot is struggling, don't shut it down. Make it bigger. Open it up. Invite more people. Tell them to invite even more people. That's the only way you're going to find out the real behavior and the real value.
If you're just starting to launch Enterprise 2.0 tools, throw the doors open wide. Invite your entire company, or as much of your company as you're allowed to invite without waiting for an act of God or Congress. Give them fun, easy ways to start contributing. (My personal favorite is microblogging.) Ease them into deeper forms of collaboration like wiki workspaces. And support those users who come forward with good ideas on how to use the tools.
Just to be clear, I'm not saying you shouldn't have clear business objectives. I'm not saying you shouldn't subject your Enterprise 2.0 implementation to critical evaluation. I'm not saying you shouldn't learn from your users and incorporate those learnings into your plans. Those are all good and important things to do. But you can only do them if you're piloting the tools in a way that you'll really learn from: at enterprise scale.
Follow us on Twitter
Follow us on Facebook
Save this to del.icio.us
Subscribe to our newsletter
Watch us on YouTube
August 28, 2009 5:57 AM
Michael, when I was at IBM, this is exactly how new technologies were tested. While IBM did have "official roll-outs" for new IT packages like HR, Billing, Travel, etc... the collaboration and social tools such as blogs, wikis, file sharing, social networks, instant messaging, even 3D worlds, were all piloted via the "Technology Adoption Program", or TAP. TAP products were not officially supported by the HelpDesk, but they all had forums where other users helped solve just about any problem. Many of these products took off, some getting 10, 15, even 20K users without any official push from the company. The most popular of these tools would "graduate" from TAP and move into the officially supported platform.
August 28, 2009 7:44 AM
Alan, now that's what I'm talkin' about!
It's great to do your homework before investing in industrial strength processes like Help Desk support. But don't place restrictions on the pilot that will stunt adoption before it gets started.
August 28, 2009 10:08 AM
Michael-- this is a provocative idea-- and the more I think about it, the more I suspect you're right.
Any good 'scientific' experiment is designed to accommodate 'requisite variety'. You have to have the right kind of 'sensors' to catch the dimensions you want to access, like having a rake with teeth spaced narrowly enough to catch the small leaves as well as the big ones.
So in addition to being about 'scale' it's also about catching enough of the variety of innovations/problems/uses etc. to give it a fair test. In theory, you could design a big enough but not all encompassing beta that addressed variety. Then you might be able to get the data/experience you need while limiting the downside risk.
That still means 'make it bigger' but adds 'in a smart way'. Neat idea. Thanks- cvh
August 31, 2009 8:59 AM
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 challenge s current business operations and tenets. You can implement a pilot to include your entire customer base but still take advantage of the flexibility that "pilot" or "beta" allows.
August 31, 2009 11:15 AM
Provocative idea and I lik the concept
But
Organisations are unique and what works in some won't necessarily work in others.
I agree that the real benefits of E2 come from scale.
But
My experience is that introducing these ideas in smallish naturally collaborative groups gets some "natural" traction from which wider collaboration and the real benefits can grow.
But
This can lead to collaboration "silos" if not careful
So
Yes the "end game" has to be scale
August 31, 2009 12:10 PM
Thanks for covering a topic that has been bothering me for some time, but I've not been able to spend the cycles on to evaluate more critically. THIS is the answer I would have been going after.
September 1, 2009 8:55 PM
"Scale is the oxygen that feeds collaboration." - I like that quote!!
September 1, 2009 10:05 PM
Interesting article. The thing with pilots and small trials is that it lets you identify some problems early before everyone else gets to use it.
I guess if you are going to open yourself up to a wide scale enterprise 2.0 subject, it may need to be called a BETA. Otherwise if you start something up and it is wrong, first impressions last and could be the downfall of the project.
Thanks for the article, it has got me thinking.
September 2, 2009 11:39 PM
Michael,
This is a thought provoking perspective. Couple of points:
Traditional IT systems are getting obsolete; and have moved/are moving towards interactive mode. So its no longer fair to see such systems as just enabling interactions. They are very much interactive. Hence, the recent emphasis on areas like Human-Computer interaction. I dont see a practical need for the divide between trasactive and interactive modes here. Consequently, I do not see why there should be a need for differnt pilot size based on this criterion.
I do agree that there needs to be a representative sample for a pilot. But then again I am not convinced that it necessarily means larger pilots for Enterprise 2.0. What we need is carefully designed pilots that are strong enough to capture the multiple dimensions of social collaboration.
If a small pilot is not working, I would ask why? I suspect there could be culprits other than size, e.g. Organization culture, relevancy of product features that may be responsible.
September 4, 2009 4:28 AM
Thanx for this post michael. I couldnt agree with u more when say that size matters for these type of systems as ur interacting with people. I also like the BETA approach jason is talking about. Systems seem to be always in beta nowadays, there are no official releases. Web services just update en provide you with more functionalities. I think u can also apply this to organizational processes. Just try a solution for ur business problem (with or without technolgy). Put it out there and see how it emerges. Unfortanetly many managers are still afraid of such an approach.
September 7, 2009 10:10 AM
I loved this post. And think it's applicable to far more than IT projects. Like @rotkapchen, this has scratched a mental itch that I've had for some time.
My only comment to add is that there is an implied criticism of your customers here. Which would be fine if you (and other vendors) weren't so unimaginative in the way that you offer free trials. Here's the trial, we're not going to give you any support - just come back and tell us if you like it.
This is fine for organisations with enough scale to carry out this kind of stuff. And in organisations where the 'future is evenly distributed'.
Such organisations are in the minority. If you want the rest to drop the pilots, you're going to have to be more creative with your free trials. And work with Enterprise 1.0 as well as 2.0