Creating a Pilot Support Plan

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

The support plan identifies who will provide support for pilot participants, the level of support required, and how users can report problems. Be sure to develop your support plan early, because doing so will help you identify the type of training the support staff requires.

Defining Support Team Roles

For each pilot, identify who will support participants: project team members such as developers and testers, Help desk personnel, or outside resources. Even if the project team will not be providing primary support for the pilot, decide what the role of the team will be. If the project team is divided into subteams for different technologies, such as Active Directory or network infrastructure, determine whether the subteams should play a role in supporting participants and, if so, what that role should be.

If Help desk personnel will provide support, or if one of your pilot objectives is to train Help desk personnel, determine how they will be trained. If external resources are required, ensure that they are aware of the schedule and have been properly trained.

Develop a contact list for support staff that includes the names, phone numbers, and e-mail addresses of all support staff members and other key contacts. For example, provide the contact name and information for a manufacturer who supplies key equipment.

Service Levels for Support

Determine the level of service that the support team can provide during the pilot. The level of service depends on the number of support personnel available and the number of problems they can support. For example, if support staff can install upgrades to 20 client computers, but can provide support to only five participants if they all have problems, plan to upgrade only five client computers, so the team can provide the appropriate support level.

When determining support requirements, some typical questions to ask include:

  • Must critical problems be resolved within a specific number of hours? If so, what is that number?

  • During which hours must support be available to the users?

The level of service your support team can provide dictates the size of your pilot and the timeline for its deployment. In addition, determining the level of service helps you establish a baseline for a level of service that can be used to create final Service Level Agreements (SLAs) for the organization.

Problem Tracking and Resolution

When problems arise during pilot testing, participants must have a way to report them to the team. The incident tracking system, problem escalation process, and issue resolution process your team develops should identify:

  • Where participants post their problems.

    Can they report problems to an existing incident-tracking system, or does the team need to develop a new mechanism, such as a Web site, for participants to use to log their problems?

    If your testing team set up an incident-tracking system to record and report testing problems, you can use the same system to report and track problems that arise during the pilot. If your organization has not developed an incident-tracking system, set one up before the pilot begins. Be sure that the incident-tracking system is well documented so pilot participants can easily enter problems into the system.

  • How problems will be reviewed, prioritized, and fixed.

    For example, support staff can review reported problems on your incident-tracking system daily, and a problem can be assigned to the support staff personnel responsible for the applicable technology or functional area. After a problem has been assigned, the support team member responsible for it can prioritize the problem and estimate the amount of time required to fix it. If this information is entered into the incident-tracking system, participants who report problems can track the status of their problems.

  • The escalation process the team will use to notify the appropriate team members.

    The incident-tracking process should have a procedure for escalating problems that can not easily be resolved to the appropriate team for resolution. Determine who is responsible for deciding when a problem must be escalated, and who should contact the team who can resolve the issue.

    During a pilot, problems must be escalated and resolved much more quickly than during the testing phase, because pilot participants are working in a business environment. How quickly problems will be resolved after the escalation process has begun should be spelled out and understood by both the pilot participants and the team. Set reasonable expectations for issue resolution so both support staff and pilot participants are comfortable with the time allowed for the escalation and resolution of problems.

  • How change requests are submitted, approved, tested, and implemented.

    Your change management plan should address these issues. The way your team handles change management can vary depending upon when the change is requested: during testing, during the pilot, or when Windows Server 2003 has been rolled out to the business environment.

Note that the procedures for resolving a problem that arises during the pilot might vary significantly from those used during full production deployment. For example, a bug in the pilot might be discovered and fixed, and an updated release deployed to participants very quickly. Depending on the severity of a problem, when a bug is discovered in production, the team might be required to go through a lengthy change management and deployment process before the bug is resolved and an update to the system is made available in the production environment.