Before the actual migration to Google Apps, there is often a technical and organizational phase called the "Pilot Project". This chapter presents the principal issues related to this pilot project. The first part deals with organizational matters. The second part more concretely explains how to implement it. Finally, the chapter concludes with a proposal of how to evaluate the results of this experimental phase.
Adopting a new tool generally includes an experimental phase. Many things have to be done simultaneously: to evaluate the benefits of the new solutions, to progressively train the users on the new solutions, to identify the impacted use cases and, finally, to define a migration plan that will lead from the current situation to the target situation in a smooth way. This experimental phase is a project unto itself and this is what is called the pilot project.
The pilot project is not a simple functional and technological demonstration whose aim is to display the panoply of existing features and prove the technical feasibility of the migration. Its primary purpose is to come up with a change-management policy and to identify the infrastructures and the procedures that will be impacted. Even if these changes are usually more in terms of configuration than the development of new products, the subject remains touchy. Within a professional context, you should keep in mind that acting on the messaging system will have an impact on a large number of users. Losing messages, incorrect addressing, and spam are all things to avoid.
Put simply: the success of the pilot project strongly correlates to the success of the migration as a whole.
There exists no strict rule for the length of a pilot project; it can vary from two weeks to two months, roughly.
Contrary to what you might expect, the length of a migration project will depend more on the scope than the size of the organization. The population of pilot users is usually restricted to a subset of no more than 20 individuals. This is enough for a representative sample of the user population, as disparate as it may be.
Another important element affecting the schedule is the expectations held of the pilot project. Asserting the technical feasibility of the migration is not tantamount to preparing the whole migration. This confusion, however, frequently occurs. Checking the feasibility of rolling back the migration for a single user is certainly not equivalent to industrializing this rollback at a larger scale. For each topic dealt with in the pilot, you should precisely assess the expectations and deduce the time required to achieve them.
Just as for any other computing project, the pilot project consists of defining the triad: scope, planning, and cost. The remainder of this chapter is thus devoted to providing concrete elements for organizing this type of project.