The Pilot Phase: Validating the Plan to a Limited Number of Users

Now that the prototype phase has been completed, the deployment team will be raring to go and have hands-on experience with all the new technologies to be implemented. The process documented in the migration document and migration plan will have been tested in the lab environment as completely as practical, and documentation detailing the steps to be followed during the pilot implementation will be at hand.

Although the pilot process will vary in complexity based on the extent of the changes to be made to the network infrastructure, the process should be well documented at this point.

It is important to identify the first group of users who will be moved to the new Windows Server 2003 environment. Users with a higher tolerance for pain are a better choice than the key stakeholders, for the most part.

Note

In many organizations, the CEO, CIO, VP of Sales, or other key executives may want to be part of the initial pilot rollout; however, we suggest not making these individuals part of the initial rollout. These individuals typically have the most complex user configuration with the lowest tolerance for interruption of network services. Users in the production environment with simpler needs can be used for the initial pilot. If necessary, create a pre-pilot phase so that the senior executives can be part of the official pilot phase, but don't make the challenges of pilot testing more difficult by starting with users who have the most complex needs.

A rollback strategy should be clarified, just in case. Test the disaster recovery and redundancy capabilities thoroughly at this point with live data but a small user group to make sure everything works as advertised. Migration processes can be fine-tuned during this process, and time estimates can be nailed down.

The First Server in the Pilot

The pilot phase is begun when the first Windows Server 2003 accessed by users is implemented in the production environment. Dependent on the scope of the migration project, this first server may be a simple application server running Terminal Services or SharePoint Team Services, or the first server may be the root of the Active Directory tree.

Just as in the prototype phase, the testing to be conducted in the pilot phase is to verify successful access to the server or application services the system provides. One of the best ways to validate functionality is to take the test sequences used in the prototype phase and repeat the test steps in the pilot production environment.

The major difference between the prototype and pilot phases is interconnectivity and enterprisewide compatibility. In many lab-based prototype phases, the testing is isolated to clean system configurations or homogeneous system configurations; however, in a pilot production environment, the new technology is integrated with old technology. It is the validation that the new setup works with existing users, servers, and systems, and software is the added focus of the production pilot phase.

Rolling Out the Pilot Phase

The pilot phase is usually rolled out in sub-phases, with each sub-phase growing in number of users affected, uses of system technology by the pilot users, and the distribution of users throughout the organization.

Quantity of Pilot Users

The whole purpose of the pilot phase is to slowly roll out users throughout the organization to validate that prototype and test assumptions were accurate and that they can be successful in the production environment. An initial group of 5 to 10 pilot users (typically members of the IT department overseeing and managing the migration) are first to be migrated. These users test basic functionality.

After successful basic testing, the pilot users group can grow to 1%, then to 3%, on to 5%, and finally to 10% of the user base in the organization. This phased rollout will help the migration team test compatibility, inner-communications, and connectivity with existing systems, while working with a manageable group of users that won't overwhelm the help desk services in place during the pilot and migration process.

The pilot phase is also a time when help desk and migration support personnel build the knowledge base of products that occur during the migration process so that if or when problems occur again (possibly in the full rollout phase of the product), lessons have been learned and workarounds already created to resolve stumbling blocks.

Application Complexity of Pilot Users

In addition to expanding the scope of the pilot phase by sheer quantity, selecting users who have different application usage requirements can provide a level of complexity across software platforms. Application compatibility and operation are critical to the end user experience during the migration process. Often users won't mind if something runs a little slower during the migration process or that a new process takes a while to learn; however, users will get upset if the applications they require and depend on each day to get their job done lock up while they use the application, data is lost due to system instability, or the application just won't work. So testing applications is critical in the early pilot phase of the project.

Role Complexity of Pilot Users

Pilot users should also be drawn from various roles throughout an organization. In many migrations, all pilot users are tested from a single department using just a single set of applications, and it isn't until the full migration process that a feature or function that is critical to everyone in the organization (except the pilot group user's department) doesn't work. An example might be a specific financial trading application, a proprietary healthcare tracking application, or a critical sales force automation remote access tool that causes the entire project to come to a halt far into the full rollout phase.

Geographical Diversity of Pilot Users

The pilot group should eventually include members geographically distributed throughout the organization. It is important to start the pilot phase with a set of users who are local to the IT or help desk operation so that initial pilot support can be done in person or directly with the initial pilot group. Before the pilot is considered complete, however, users from remote sites should be tested to ensure their user experience to the new networking environment hasn't been negatively affected.

Fixing Problems in the Pilot Phase

No matter how much planning and testing are conducted in the earlier phases of the project, problems always crop up in the pilot phase of the project. It is important to have the prototype lab still intact so that any outstanding problems can be re-created in the lab, tested, and resolved to be tested in the pilot production phase again.

Documenting the Results of the Pilot

After the pilot, it is important to document the results. Even with the extensive discovery and design work, as well as the prototype lab testing and pilot phases that have taken place, problems may reoccur in the post-pilot phases, and any documented information on how problems were resolved or configurations made to resolve problems in the pilot phase will help simplify the resolution in future phases. If you take some extra time to give attention to the pilot users, you can fine-tune the solution to make sure the full implementation is a success.