An article on ReadWriteWeb discussing the perceived value of technology pilots included this comment about the size of pilots relative to large enterprises:
Interaction among workers in a tiny subset of your organization isn’t a fair test.
Pilots work well because they are culturally and functionally useful. Most organizations are not going to test a new technology on their entire workforce, so a pilot with a subset of employees is the next best option. One of the most important benefits of running a pilot is that it gives you an opportunity to discover and fix technical issues before a tool is made available to thousands or tens of thousands of people. Fixing those problems while they’re small and you’re working with a pilot group that’s empathetic makes it much easier to refine the system for a smooth rollout and adoption.
That’s the part about pilots that’s inarguable in my experience. If you find & fix a problem with the assistance of that compact group of helpful people, you’ll be in much better shape than if you have 10,000 angry people beating down your door while you try to fix a major problem that has brought down the whole system. Political debates about the importance of pilots can go one way or the other, but technical problems can derail even the best-laid plans.
Making a pilot representative of large-scale adoption is dependent on how you structure the pilot participants. If you only involve hard-core early adopters, then of course it won’t be representative. However, if you construct a pilot that involves people from several key areas of the organization (HR, product/project groups, technical writers, customer support/service, etc.) and those people understand that they’re getting a chance to set up their uses before everyone else in exchange for their help and patience in finding and fixing technical problems, you’ll get a group that will solidly support the project once it’s opened up for large-scale use.
The use cases developed by your pilot group are an important part of the larger scale rollout that happens after the pilot, because they give the rest of the organization a set of tangible starting points. Some teams will want to mimic the exmples generated by your pilot, and others will say “hey, my case is different.” Offer the former as much guidance and access to structural and process details of the use cases they want to mimic, and let the latter develop uses that meet their particular needs. Ultimately, running a pilot gives people an opportunity to actively engage with the tool and make it a productive part of their daily work.