Andrew McAfee had a post a couple weeks ago that suggests Enterprise 2.0 implementers should Drop The Pilot. I have heard this in Theory of Constraints circles too. If the project is worth doing, shouldn't it be worth doing everywhere?
McAfee suggests the main problem with E2.0 pilots is that they can't work due to the necessary scale:
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.
His discussion (and the excellent comments) makes me think of network effects. And that network could be people, or parts flowing through a manufacturing facility, or inter-related projects. If you attempt to carve out a subset of this type of network for a pilot, you are guaranteed two problems. First, the pilot network is going to require inputs from outside the network. Since they aren't participating in the pilot, the pilot is automatically hamstrung by forcing those participating to operate under (at least) two regimes: the pilot, and the old way. Second, the outside network takes actions that impinge on the participants in the network. Department X makes a decision for the whole company that runs counter to the new way of operating in the pilot group. Or more simply, another project in the organization requires the time and energy of the people in the pilot. In either case, the expected benefits and value of the project are going to be significantly reduced due to these effects.
For these projects to work, they need to have a fairly self-contained segment of the organization. In some cases, that means the entire organization, such as what McAfee suggests. In other cases, this is a full business unit or operating division, where the outside interactions are minimal and can be limited to a few key nodes in the network (where the interface effects can be minimized).
[Photo: "Sky Pilot" by jayspost]