Microsoft Windows Server 2003 Unleashed (R2 Edition)
Before the migration document is created, the end state of the project has been documented in detail and agreed upon by the key stakeholders in the organization. There should not be any question as to exactly what the next evolution of the network will be composed of and what functionality it will offer. In addition, an estimated budget for the hardware and software required and an estimated timeline for the project have been identified. In some cases, depending on the size and complexity of the project, and whether outside consulting assistance has been contracted, a budget has also been established for the implementation services. So, now that the end state has been clearly defined, the migration document can be created to document the details of the steps required to reach the end state with minimal risk of negative impact to the network environment. The migration plan should not contain any major surprises. A key component of the migration document is the project plan, or migration plan, that provides a list of the tasks required to implement the solution. It is the roadmap from which the migration document will be created. The migration document will also provide a narrative, where needed, of the specifics of the tasks that the project plan does not provide, and provide other details as outlined next. Time for the Project Plan
As mentioned previously, the primary stepping stones needed to reach the end point have been sketched out in the discovery process, and in collaboration sessions or design discussions that have taken place. The project plan in the migration document provides a tool to complement the design document, which graphically illustrates the process of building and testing the technologies required as well as provides an outline of who is doing what during the project. By using a product such as Microsoft Project, you can organize the steps in a logical, linear process. The high-level tasks, like those shown in Figure 2.1, should be established first. Typically, they are the phases or high-level tasks involved in the project, such as Lab Testing, Pilot Implementation, Production Implementation, and Support. Then the main components of these tasks can be filled in. Figure 2.1. High-level migration project plan.
Dates and durations should be included in the project plan, using the basic concept of starting with the end date when everything needs to be up and running, and then working backward. It's important to include key milestones, such as acquiring new software and hardware, sending administrative resources to training classes, and provisioning new data circuits. Slack time should also be included for unexpected events or stumbling blocks that may be encountered. Each phase of the project needs to be outlined and then expanded, similar to the sample prototype testing phase plan shown in Figure 2.2. Figure 2.2. Sample Windows Server 2003 prototype testing phase project plan.
Note that in the example in Figure 2.2, the tasks are kept on a high level, but additional details can be included as needed. A good rule of thumb is not to try to list every task that needs to take place during the phase, but to have each line represent several hours or days of work. If too much detail is put into the project plan, it quickly becomes unmanageable. For the detailed information that does not necessarily need to be placed in the project plan (Gantt chart), the information can be detailed in the migration document. The migration document adds in technical and operational details that will help clarify more specific project information. Note The terms project plan and Gantt chart are commonly interchanged in IT organizations and may or may not have different meanings to different individuals. In this book, the term project plan will refer to the chronological steps needed to successfully plan, prepare, and implement Windows Server 2003. The term Gantt chart will be used to refer to the chronological steps, but also the inclusion of resource allocation, start and end dates, and cost distribution.
The plan should also assign resources to the tasks and start to define the teams that will work on the different components of the project. If an outside organization is going to assist in the process, it should be included at the appropriate points in the project. Microsoft Project offers an additional wealth of features to produce reports and graphical information from this plan; they will prove extremely helpful when the work starts. Also, accurate budgetary information can be extracted, which can take into account overtime and after-hours rates and easily give "what if" scenario information. Speed Versus Risk
The project plan will also enable you to test "what if" scenarios. When the high-level tasks are defined, and the resources required to complete each task are also defined, you can easily plug in external contractors to certain tasks and see how the cost changes. After-hours work might take place during working hours in certain places. If the timeline still isn't acceptable, tasks can be stacked so that multiple tasks occur at the same time, instead of one after the other. Microsoft Project also offers extensive tools for resource leveling to make sure that you haven't accidentally committed a resource to 20 hours of work in a day. The critical path of the project should be defined as well. Certain key events will need to take place for the project to proceed beyond a certain point. Ordering the hardware and having it arrive will be one of these steps. Getting stakeholder approval on the lab environment and proving that key network applications can be supported may well be another. Administrative and end-user training may need to happen to ensure that the resulting environment can be effectively supported. You may need to build contingency time into the project plan as well. Hardware can get delayed and take an extra week or two to arrive. Testing can take longer, especially with complex configurations, and where customization of the NOS is required or directory information needs to be modified. Creating the Migration Document
The migration document can now narrate the process detailed in the project plan. The project plan does not need to be 100% complete, but the order of the steps and the strategies for testing and implementing will be identified. The following is a sample table of contents and brief description of the migration document:
The Executive Summary
The executive summary should set the stage and prepare the audience for what the document will contain, and it should be concise. It should outline, at the highest level, what the scope of the work is. Ideally, the executive summary also positions the document in the decision-making process and clarifies that approvals of the design are required to move forward. The Goals and Objectives Section
The goals and objectives section may seem redundant because the design documents documented the objectives in great detail, but it is important to consider which specific goals and objectives are important to the success of the migration project that may not have been included in the design document. For example, although the design document outlined what the final server configuration will look like, it may not have outlined the tools needed to migrate key user data or the order that the company offices will be migrated. So, the goals and objectives in the migration document will be very process specific. The Roles and Responsibilities Section
In the roles and responsibilities section, the teams that will do the work should be identified in detail. If an outside company will be performing portions of the work, which tasks it will be responsible for and which ones internal resources will take ownership of should be documented. The Approach Section
Each section of the approach should detail the goals of each phase, as well as the process that will be followed for that phase, and the resources and estimated durations. Information should also be provided on what the final deliverables from each phase will be and the sign-off criteria to consider the phase complete. Critical path tasks and the risks associated with specific tasks should be outlined in these sections as well. Whereas the design document tells the story of the project's goals and the end state, the migration document provides the details of how to get there. It is important to note that the migration document is not typically a step-by-step guide on how to install and configure every product needed for the Windows Server 2003 project because such documents take an extraordinary amount of time to produce. The design document can be referenced as appropriate in the migration document, or additional details can be provided to clarify the process. The Project Plan Section
Where the project plan provides the high-level details of the steps, or tasks, required in each phase, the approach sections of the migration document can go into more detail about the details of each step of the project plan, as needed. Certain very complex tasks are represented with one line on the project plan, such as "Configure Windows Server 2003 #1" and may take several pages to describe in sufficient detail in the migration document. Data availability testing and disaster recovery testing should be discussed. In the design document, you might have decided that clustering will be used, as well as a particular tape backup program, but the migration plan should outline exactly which scenarios should be tested in the prototype lab environment. Documents to be provided during the migration should be defined so that it is clear what they will contain. The Budget Section
With regards to the budget information, although a great amount of thought and planning has gone into the design and migration documents, as well as the project plan, there are still variables. No matter how detailed these documents are, the later phases of the project may change based on the results of the earlier phases. For instance, the prototype testing may go flawlessly, but during the pilot implementation, performing data migration simply takes longer than anticipated; this extra time will require modifications to the amount of time required and the associated costs. Note that changes in the opposite direction can happen as well, if tasks can occur more quickly than anticipated. Often the implementation costs can be reduced by keeping an eye on ways to improve the process during the prototype and pilot phases. |
Категории