Creating the Migration Document

 <  Day Day Up  >  

With the Design document completed and agreed to by the decision- makers , the Migration document can now be created. There are always different ways to reach the desired Exchange Server 2003 configuration, and the Migration document presents the method best suited to the needs of the organization ”in terms of timeline, division of labor, and cost ”based on the goals and objectives defined in the initiation and planning processes. The Migration document makes the project real; it presents specific information on "who does what" in the actual testing and migration process, assigns costs to the resources as applicable , and creates a specific timeline with milestones and due dates.

The Migration document should present enough detail about the testing and upgrade process that the resources performing the work have guidance and understand the purpose and goals of each step. The Migration document is not a step-by-step handbook of how to configure the servers, implement the security features, and move mailboxes. The Migration document is still fairly high level, and the resources performing the work need real-world experience and troubleshooting skills.

Additional collaborative meetings might be needed at this point to brainstorm and decide both on the exact steps that will be followed and when the testing and upgrade will be (see Figure 2.3).

Figure 2.3. Migration session agenda.

graphics/02fig03.jpg

Part V, "Migrating to Microsoft Exchange Server 2003," provides additional information about the various strategies and processes for moving from previous versions of Exchange to Exchange Server 2003.

The Project Schedule

A project schedule or Gantt Chart is a standard component of the Migration document, and it presents tasks organized by the order in which they need to be completed, in essence creating a detailed roadmap of how the organization will get from the current state, test the solution, and then implement it.

Other important information is included in the project schedule: resources assigned to each task, start dates and durations, key checkpoints, and milestones. Milestones by definition have no duration and represent events such as the arrival of hardware items, sign-off approval on a series of tasks, and similar events. Some additional time should be allocated (contingency time) if possible during the testing phase or between phases, in case stumbling blocks are encountered .

A good rule of thumb is to have each task line represent at least four hours of activities; otherwise , the schedule can become too long and cumbersome. Another good rule is that a task should not be less than 1% of the total project, thus limiting the project to 100 lines. The project schedule is not intended to provide detailed information to the individuals performing the tasks, but to help schedule, budget, and manage the project.

To create a project schedule, a product such as Microsoft Project is recommended, which facilitates the process of starting with the high-level steps and then filling in the individual tasks. The high-level tasks, such as those shown in Figure 2.4, should be established first and can include testing the server configurations and desktop designs, performing one or more pilot implementations , the upgrade or migration process, and the support phase.

Figure 2.4. Sample project schedule.

graphics/02fig04.gif

Dependencies can also be created between tasks to clarify that Task 40 needs to be completed before Task 50 can start. A variety of additional tools and reports are built in to see whether resources are overburdened (for example, being expected to work 20 hours in one day), which can be used for resource leveling. A baseline can also be set, which represents the initial schedule, and then the actuals can be tracked and compared to the baseline to see whether the project is ahead or behind schedule.

Microsoft Project is also extremely useful in creating budgetary information and creating what-if scenarios to see how best to allocate the organization's budget for outside assistance, support, or training.

If the timeline is very short, the Gantt chart can be used to see if multiple tasks take place simultaneously or if this will cause conflicts.

Create the Migration Document

With the project schedule completed, the Migration document will come together quite easily, because it essentially fills out the "story" told by the Gantt chart. Typically the Migration document is similar to the structure of the Design document (another reason why many organizations want to combine the two), but the Design document relates the design decisions made and details the end-state of the upgrade, and the Migration document details the process and steps to be taken.

The following is a sample table of contents for the Migration document:

  1. Executive Summary

  2. Goals and Objectives of the Migration Process

  3. Background

  4. Summary of Migration-Specific Decisions

  5. Risks and Assumptions

  6. Roles and Responsibilities

  7. Timeline and Milestones

  8. Training Plan

  9. Migration Process

    • Hardware and Software Procurement Process

    • Prototype Proof of Concept Process

    • Server Configuration and Testing

    • Desktop Configuration and Testing

    • Documentation Required from Prototype

    • Pilot Phase(s) Detailed

    • Migration/Upgrade Detailed

    • Support Phase Detailed

    • Support Documentation Detailed

  10. Budget Estimate

    • Labor Costs for Prototype Phase

    • Labor Costs for Pilot Phase

    • Labor Costs for Migration/Upgrade Phase

    • Labor Costs for Support Phase

    • Costs for Training

  11. Project Schedule (Gantt Chart)

The following sections delve into the information that should be covered in each section. Part V of this book provides in-depth information on the steps involved in migrating to Exchange Server 2003 from Exchange 5.5 or Exchange 2000, and Part IX, "Client Administration and Management," provides details on the client configuration options and processes.

Executive Summary

As with the Design document, the executive summary section summarizes what the Migration document covers, the scope of the project, and the budget requested .

Goals and Objectives of the Migration Process

The goals and objectives of the migration overlap with those of the overall project, but should focus also on what the goals are for use and development of internal resources, and the experience of the user community. A goal of the overall project could be "no interruption of messaging services," and this would certainly be a goal to include in the Migration document.

Subphases of the Migration document have their own specific goals that might not have been included in the Design document. For example, a primary goal of the prototype phase, which takes place in a lab environment so it won't interfere with the production network, is to validate the design and to test compatibility with messaging- related applications. Other goals of the prototype phase can include hands-on training for the migration team, creating documents for configuration of the production servers, and creating and validating the functionality of the desktop configurations.

Background

A summary of the migration-specific decisions should be provided to answer questions such as "Why are we doing it that way?" Because there is always a variety of ways to implement new messaging technologies ”such as in-place upgrades instead of buying new hardware ”and a number of conversations will have taken place during the planning phase, it is worth summarizing them early in the document.

Risks and Assumptions

Risks pertaining to the phases of the migration should be detailed, and typically are more specific than in the Design document. For example, a risk of the prototype phase might be that the hardware available won't perform adequately and needs to be upgraded. Faxing, virus protection, or backup software might not meet the requirements of the Design document and thus need upgrading. Custom-designed messaging applications, or Exchange add-ons might turn out not to be Exchange Server 2003 “compatible.

Roles and Responsibilities

The Design document focuses on the high-level "who does what"; the Migration document should be much more specific, because the budget for labor services is part of this deliverable . Rather than just defining the roles (such as project sponsor, Exchange Server 2003 design consultant, Exchange Server 2003 technical lead, and project manager) the Migration document specifically indicates the level of involvement of each resource throughout the prototype, pilot, and migration phases. The project sponsor should stay involved throughout the process, and regular project status meetings keep the team on the same page.

The project manager is expected to keep the project on time, on budget, and within scope, but generally needs support from the project sponsor and key stakeholders involved in the project. Depending on how the project manager role is defined, this individual may be either a full-time resource, overseeing the activities on a daily basis, or a part-time resource, measuring the progress, ensuring effective communications, and raising flags when needed. A cautionary note: Expecting the project manager to be a technical resource ”such as the Exchange Server 2003 technical lead ”can lead to a conflict of interest and generally does not yield the best results. Projects tend to be more successful if even 10% of an experienced Project Manager's time can be allocated to assist.

Timeline and Milestones

Specific target dates can be listed, and should be available directly from the project schedule already created. This summary can be very helpful to executives and managers, whereas the Gantt Chart contains too much information. Constraints that were identified in the discovery process need to be kept in mind here, because there might be important dates (such as the end of the fiscal year), seasonal demands on the company that black out certain date ranges, and key company events or holidays.

Training Plan

Will training happen during the prototype testing process in a hands-on fashion for the project team, or will classroom-style training be required? Will the end-users be trained while their desktops are being upgraded, or be left with a training document, or be directed to a training video on the network? If management tools are being added to the environment, who will train the appropriate resources on how to effectively use them and not be overwhelmed by false alarms?

Migration Process

The project schedule Gantt chart line items should be included and expanded upon so that it is clear to the resources doing the work what is expected of them. The information does not need to be on the level of step-by-step instructions, but it should clarify the process and results expected from each task. For example, the Gantt chart might indicate that an Exchange Server needs to be configured, and in the Migration document, information would be added about which Service Pack is to be used for the NOS and for Exchange, how the hard drives are to be configured, and which additional applications (virus protection, tape backup, faxing, network management) need to be installed.

If the Gantt chart lists a task of, for example, "Configure and test Outlook 2003 on sales workstation," the Migration document gives a similar level of detail: Which image should be used to configure the base workstation configuration, which additional applications and version of Office should be loaded, how is the workstation to be locked down, and what testing process should be followed (is it scripted or will an end-user from the department do the testing)?

Documentation also should be described in more detail. The Gantt chart might simply list "Create as-Built documents," with as-built defined as "a document containing key server configuration information and screen shots so that a knowledgeable resource can rebuild the system from scratch."

Sign-off conditions for the prototype phase are important and should be included. Who needs to sign off on the results of the prototype phase to indicate that the goals were all met and that the design agreed upon is ready to be created in the production environment?

Similar levels of information are included for the pilot phase and the all-important migration itself. Typically during the pilot phase, all the upgraded functionality needs to be tested , including remote access to email, voicemail access, BlackBerry and personal information managers, and public folders.

After the Exchange Server 2003 infrastructure is fully in place, what level of support will be provided? If an outside firm has assisted, will it leave staff onsite for a period of time to hold users' hands and troubleshoot any issues that crop up?

If documentation is specified as part of the support phase, such as Exchange maintenance documents, disaster recovery plans, or procedural guides, expectations for these documents should be included to help the technical writers make sure the documents are satisfactory.

Budget Estimate

At this point in the process the budgetary numbers should be within 10 “20% of the final costs, bearing in mind any risks already identified that could affect the budget. Breaking the budget into prototype, pilot, migration, support, and training sections helps the decision-makers understand how the budget will be allocated and make adjustments if needed. No matter how much thought has gone into estimating the resources required and risks that could affect the budget, the later phases of the project may change based on the outcome of the prototype phase or the pilot phase.

 <  Day Day Up  >  


Microsoft Exchange Server 2003 Unleashed
Microsoft Exchange Server 2003 Unleashed (2nd Edition)
ISBN: 0672328070
EAN: 2147483647
Year: 2003
Pages: 393
Authors: Rand Morimoto

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net