Chapter 2 - Building the Project Plan

  • Article
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

John Fisher, Senior Consultant, Microsoft 

The project plan is essential to planning, designing, and deploying Microsoft Exchange 2000 Server. A thorough project plan provides logical phases that keep the team focused on the tasks involved. This chapter addresses items that you need to consider when creating your project plan.

Deploying Exchange 2000, whether as an upgrade from Microsoft Exchange version 5.5 or as a new installation, is a complex project that requires a plan to aid the people working on the project. To assist in the planning and deployment of a project, Microsoft Consulting Services and the Microsoft development groups have assembled a framework of best practices called the Microsoft Solutions Framework. Microsoft Solutions Framework is not a methodology, but a flexible series of concepts, models, and best practices that lay the foundation for planning, building, and deploying technology projects.

This chapter uses concepts from the Microsoft Solutions Framework Infrastructure Deployment Process Model, which is based on a team approach and milestone-driven schedules. The team that deploys Exchange can be an internal division of a company or an external consulting company that works with many companies. The scenario outlined in this chapter is based on an internal Information Technology (IT) team deploying Exchange 2000 for its own company. You can easily adapt the guidelines in this chapter for a team that consults for several companies and is not part of the company deploying Exchange 2000.

Note Microsoft Solutions Framework is part of the Microsoft Enterprise Services Framework, a framework that targets different aspects of providing world-class information technology to companies. For more information about Enterprise Services Framework and its components, see the Microsoft Web site at https://www.microsoft.com.

Taking a Phased Approach

When you are planning any large project, it is easy to get overwhelmed; dividing the project into phases helps keep the team on track and makes it easier to measure progress. Taking a phased approach to your project reduces risk and increases project success by ensuring that necessary tasks are completed in a logical order. Each phase of a project should have clear objectives and deliverables that, once completed and reviewed, allow the team to proceed to the next phase of the project.

This chapter discusses the four-phase model used with the Microsoft Solutions Framework Infrastructure Deployment Process. The phases are:

  • Phase 1: Envisioning In this phase, you define the project vision and scope, you create the project team, you gather business requirements, and you identify project risks. 

  • Phase 2: Planning In this phase, you plan and design the solution. From a design perspective, you create detailed, low-level specifications for the project in the form of a functional specification. In addition, you establish detailed project plans in the form of the Master Project Plan and Master Project Schedule to help you complete the project. 

  • Phase 3: Developing In this phase, you develop the final system by using the design and planning information gathered in the planning phase. You finalize and tune systems in pilot projects, and create deployment plans. 

  • Phase 4: Deploying In this phase, you deploy the system. You take the project from the pilot stages in the last phase to full production status. 

Assessing Project Risk

Assessing potential problems that might arise during your project—and devising a method to mitigate them—can reduce the negative impact they might have on your project. Risk management is a team effort, which continues throughout the life of the project; however, attempting to identify the risks early and mitigate them keeps the project on track and on schedule.

You can use the following five-step risk management process on your project:

  1. Identify the risk This step allows the team to become aware of a risk and address it before it can cause harm to the project. 

  2. Analyze the risk This step involves analyzing the risk and converting it into information that the team can use to make decisions. The risk is assessed as to its probability of occurring, as well as its potential impact on the project. Using this information, the team can devise a plan for mitigation. 

  3. Plan for risks This step involves creating plans to turn the information that is collected into actions and decisions. The plan should involve developing actions to address the risks, prioritizing risk actions, and devising a metric or trigger point to alert the team that the mitigation plan must be put into action. 

  4. Track the risks Tracking the top ten risks is important; it allows the team to monitor them if mitigation steps were taken. 

  5. Control risks This step moves the risk management process into the daily activity of the project. If the team did a good job on the earlier steps, risk control should be easy by monitoring the metrics and triggers. Risk management remains a high-profile activity to aid in the success of your project. After a risk can no longer have an impact on the project, it should be retired. 

Creating a table to assess risks (by estimating the probability of the problem arising and the impact it may have on the project) allows you to mitigate the risk. The mitigation may be a full plan or just an item or step to complete to eliminate or reduce the risk to the project. Although you create the table at the beginning of the project, it is constantly managed throughout the life of the project, and risks are added, removed, and retired as required.

Example

The following example can help clarify the risk assessment process.

A company is in the process of installing a new online training system for company-wide use, but there is a concern that it will not be in place in a timely fashion for the Exchange deployment. Based on the current schedule, the team has assigned this risk a high probability and a high impact on user satisfaction. As a result, the team tracks the risk as follows:

Risk Identifier: Online User Training.Risk Statement: The training plan calls for all user training to be delivered by using the new online training system that is currently behind schedule for being installed. If this schedule continues to slip, the team will have no mechanism for delivering training material to users.Risk Management Strategy: A member of the User Education team responsible for training monitors the installation status of the online training system on a weekly basis; if time allows, this person will offer assistance.Risk Management Strategy Metrics: The Online Training System project schedule is no longer slipping or the team is actually close to getting back on schedule.Action Items: Assign a team member to monitor and assist with the Online Training System and report back to the Exchange team weekly.Due Date: Ongoing.Personnel Assignment: Sandra from the User Education team.Risk Contingency Strategy: Work with an outside vendor to obtain printed training materials rather than the online versions, and ensure that enough copies are available for the deployment.Risk Contingency Strategy Metrics and Trigger Value: If the Online Training System slips more than an additional three weeks, or if 30 days prior to the first deployment, online training is not available, plan to order printed training material for user self study.

Identifying, analyzing, mitigating, and tracking the risks early in the project cycle allows the team to use the metrics and trigger point to easily identify when the risk needs to be addressed. Tracking the top 10 project risks in this manner eliminates the guesswork of risk management and aids in the success of your project.

Templates to Aid with Your Project

To assist in your program planning, several templates have been included on the Microsoft Exchange 2000 Server Resource Kit companion CD. You can use these templates to develop the various plans required for the project.

  • Deployment Schedule Template 

  • Action Item Template 

  • Vision-Scope Template 

  • Risk Management Plan Template 

Phase I: Envisioning

In the first phase of the project, you define the goals, limits, and structure of the project. The key deliverables in the envisioning phase are:

  • Structure of the project team 

  • High-level project requirements 

  • Project vision, scope, and assumptions 

  • Conceptual high-level design 

Note While in this phase of the project, it is especially important to identify and assess possible high-level project risks that you may encounter. For more information about risk assessment, see the section "Assessing Project Risk" earlier in this chapter.

Many project teams want to immediately begin the work of designing a new system; however, it is important to complete the envisioning phase first because this is when you assess customer requirements and create the final vision and scope of the solution. Without the final vision, a project can become unmanageable.

The envisioning phase concludes when your vision and scope document is complete and approved by the team and the project sponsor.

This section explains the major components of the envisioning phase.

Building the Project Team

The creation of a team allows you to distribute project responsibilities among team members. In the Microsoft Solutions Framework model, a team of peers plans and implements the project. The overall project responsibility lies with the entire team, but each member of the team is responsible for his or her appropriate functional area.

The different roles of an Exchange deployment team might include:

Table 2.1 Deployment team roles 

Role

Responsibility

Product Manager

Works with the customer to gather business requirements, set objectives, and set the budget. This is not necessarily a technical role. The product manager is also responsible for project communications.

Program Manager

Assumes responsibility for the overall technical Exchange design and implementation.

Executive Sponsor

Provides support at a management level throughout the life of the project. As a high-level manager (usually a Director, Vice President, or above) this person is not necessarily a team member, but an external advisor to the team.

Project Sponsor

Reviews the progress of the project. This is an individual or small team of key stakeholders from the company. This person may be a director or manager to whom the technicians deliver the project report. The project sponsor is not necessarily a team member, but rather an external influence over the entire team.

Development/Engineering

Determines all technical configurations of the Exchange messaging system and interfaces, including the server, clients, and external connections. The development team consists of people functioning in different roles, such as:
· Messaging Administrator
· Network Administrator
· Internet/Intranet Administrator
· Desktop Administrator
· Account Administrator
· Security Administrator
· Operations Engineer
These professionals work together, on the central team or in sub-teams as required, to design the new system.

Test/Quality Assurance

Ensures that the designed systems comply with the functional specification and other corporate standards.

User Education

Ensures that the user education process and documents are completed, including all documentation and training for the project. Skill areas utilized on this team include:
· End User Training
· End User Technical Support
· User Communications

Logistics Management

Determines the best way to deploy Exchange servers and transition systems to the operational groups.

In a larger project, you can assign roles to different sub-teams that will focus on the functional area. In a smaller project, you can assign a single role to an individual team member or you can combine roles, so that one member handles multiple roles.

Often an IT group that undertakes a project on its own may choose to contract an external technical consultant to advise the project team. This resource can provide occasional consulting services to the team across all teams; Microsoft Consulting Services as well as Microsoft Certified Solutions Providers can provide assistance with this role.

All team members should be proficient with Exchange 2000 and Microsoft Windows 2000 so that the team can share a base level of understanding. This training is important so that the team understands the effort required to add functionality to the systems. For additional information about training classes and authorized training centers, see the Microsoft Web site at https://www.microsoft.com.

Building the Project Structure

You must set up and communicate the operating structure during the envisioning phase of the project. In the next phase, you will add details to the structure. Depending on the culture at your company, different degrees of formality may be acceptable, but at a minimum, you should hold regular scheduled project meetings with an agenda. Consider the use of a project Web site to store all pertinent project documents, schedules, and status reports, so that all team members, as well as the customer, can access the latest information.

Gathering High-Level Requirements

Gathering the requirements of your new Exchange environment is important because these requirements make up the infrastructure or framework of the system design; they can be categorized as follows:

  • Business requirements The requirements, such as service level objectives, that the business demands of the new Exchange messaging systems. For example, you must decide if Exchange will be the building block for future business applications. 

  • User requirements Specific features that the users have requested. 

  • IT requirements Requirements from IT management as well as systems administrators, which outline the structure and operation of the Exchange environment. 

When you collect requirements from the different groups, you might want to prioritize requirements or create a list of requested features. By having the customers prioritize their requests, you enable your team to phase in features if the project timeline is aggressive.

Defining the Project Vision

A high-level project vision or mission statement helps the team focus on its tasks when designing and deploying the new Exchange system. The vision statement describes what the team envisions as the end result or outcome of the project.

For example, a fictional company called Northwind Traders has 10,000 employees in fifteen locations worldwide. The company has five different business units, each maintaining its own messaging system, ranging from Microsoft Exchange Server 5.5 to an old mainframe text-based mail system. To reduce IT costs and improve communications, Northwind Traders' IT group has decided to replace the old messaging systems and install a new company-wide standard that uses Exchange 2000. The project team has created the following vision statement for its project:

Northwind Traders will replace its five existing divisional-based messaging systems with an enterprise-wide messaging system that uses Microsoft Exchange 2000 Server. This will enable the five business units to interoperate seamlessly while adding user functionality and reducing administrative and operational costs. The new system will be deployed to each of the company's locations and all employees worldwide. Deployment will commence within three months and be complete within 18 months.

Defining the Project Scope

Whereas the vision statement defines a final vision of the project, the project scope defines the functionality that you can reasonably implement within the time allowed, given the project variables. Project variables include:

  • Resources People and money. 

  • Schedule The time allowed for the project. 

  • Features The specific features that are included in the final solution. 

    For example, the new messaging system at Northwind Traders will:

    • Be designed for 10,000 users and accommodate Northwind Traders' 7 percent expected growth per year, for the next seven years. 

    • Replace the five previous messaging systems: Microsoft Exchange, Lotus Notes, Lotus cc:Mail, UNIX Post Office Protocol (POP) servers, and SNA Distribution System (SNADS). 

    • Coexist with the five legacy messaging systems until migration is complete. 

    • Be a highly available system that fulfills the requirements specified by the company's business units' Service Level Agreement. 

    • Provide the capability for real-time employee communications to facilitate idea sharing across the company. 

    • Leverage the newly installed Windows 2000 infrastructure. 

    • Provide an internally hosted data conferencing service to eliminate the need to contract this service from an outside provider. 

Defining the Project Assumptions

Assumptions should be identified as early as possible in the process and listed in the project's vision and scope document. The addition of items outside the project's scope should also be listed in the assumptions section to clearly identify functionality that will not be delivered as part of the project.

For example, the following are assumptions for an Exchange 2000 deployment:

  • The Windows 2000 infrastructure project must be complete enough to use Active Directory directory service for this project. 

  • The resource gap will be filled with contract labor to meet the aggressive project schedule. 

  • The migration team is not responsible for mail older than 30 days. 

Creating a Conceptual Design

Often when planning a project, you can develop a conceptual design based on your vision statement and the requirements that you have gathered. The conceptual design would be a high-level drawing of your optimal solution and would be included in your vision and scope document. It is important to not go into too much detail at this phase because the detailed design occurs in the planning phase when you create the functional specification.

Phase II: Planning

The second phase of a project is the planning phase. This phase plays an important role in the smooth deployment of your Exchange environment. In the planning phase, the team completes high-level concepts in the envisioning phase and begins the detailed planning and engineering tasks of the system. Planning, also called the engineering phase of a project, addresses three main points through the following deliverables:

  • Functional Specification: Details the final solution that the team delivers. 

  • Master Project Plan: Details how the system is designed, tested, and deployed. 

  • Project Schedule: Details when the remainder of the project begins and when it will be completed. 

To cover the What, How, and the When of the project, the team must complete several major tasks during the planning phase. General planning tasks help the team understand the current environment and plan for the new project's environment. The following are general planning tasks:

  • Gather information 

  • Design the functional specifications 

  • Perform proof-of-concept testing 

  • Identify resources

  • Create the project plan 

  • Build the project schedule 

Specific planning tasks must include addressing the following issues:

  • It is critical to understand the existing Windows infrastructure, whether it is Windows NT version 4.0 or Windows 2000. If Windows NT 4.0 is currently being used, then the team must understand how and when Windows 2000 will be deployed in the company. 

  • If Exchange 5.5 is currently deployed, the team must plan an approach for interoperability, integration, and user migration to Exchange. 

  • A clearly defined owner of Active Directory, both for planning and operational purposes, must be identified. If you do not plan for this issue, you might later face political and operational barriers. If Exchange is already deployed, Exchange administrators may be accustomed to owning the directory. When Active Directory is introduced into the environment, Windows NT administrators and not Exchange administrators might own Active Directory. 

The planning phase is complete when the team agrees to the functional specifications and the program plan.

Gathering Information

When designing the new messaging system, it is critical that the team has an accurate picture of the existing environment. The following table illustrates the important information that you must obtain.

Table 2.2 Information about the existing environment

Information to Gather

Description

Organizational structure and location data

How the business is organized and operates (for example, divisions vs. regions). This often dictates message flow. The number of office locations and users at each location is also important.

Network infrastructure

The company network infrastructure (including LAN and WAN topologies) and utilization. It is important to determine how the company handles remote access.

Messaging and directory structure

What the current messaging topology looks like and how it operates. The existence of a Windows 2000 Active Directory and whether it needs to interact with other directories within the company is also important.

Desktop and server environments

The types of systems that users are currently using. It is important to determine if existing messaging hardware can be re-deployed for use with Exchange 2000.

Standards

Whether there are existing corporate standards, such as naming and operational procedures, that impact the design of the system.

Functional requirements

These requirements expand upon the high-level user requirements. It is a good idea to conduct user and IT surveys to determine user and IT requirements.

The Functional Specification

After the teams have gathered the appropriate information, you use this information along with the requirements, vision and scope documents, and high-level design to start creating a functional specification. The functional specification must provide enough detail to allow the various team members to begin work in their areas, such as engineering, testing, training, and deployment.

As the functional specification evolves, it may become clear that there is not enough time to complete the system with all of the desired functionality, particularly the desirable but non-essential items. To deliver a solution that meets the project schedule, consider limiting the functionality included in the release to the functionality that is required. Using the concept of versions, you can add functionality to the system in future projects. When deciding on which features to move to a next version, always refer to the vision and scope, as well as user requirements. These items, along with estimated costs and scheduling information, aid in the decision.

The functional specification can be considered a contract between the company and the project team on what will be delivered for a final solution. At the end of the planning phase, the team and the customer approve a draft version of the functional specification. This provides a mechanism for setting expectations for everyone included in the project. In the next phase, after the design is tested, the functional specification is frozen. To ensure timely delivery, changes to the design are no longer acceptable.

Proof-of-Concept Testing

During the design and engineering process, you might need to validate some engineering designs by performing a prototype or a proof-of-concept test. These tests are not intended to test the entire solution, but to aid in the engineering process and verify that a design is actually achievable. Often teams choose to prototype a new technology, such as conferencing services or connectors to external systems. This helps the team better understand product features and aids in the design of the system.

For example, given that Northwind Traders' IT group already has experience with Exchange 5.5, they will prototype some of the new or updated features and connectors that are required for the project. These features include:

  • Exchange Instant Messaging 

  • Exchange Conferencing Server 

  • Third party e-mail connectors, such as Lotus Notes and Lotus cc:Mail. 

  • Multiple storage groups 

Identifying Resources

In the next step of the planning phase, you identify resources such as staff, hardware, software, and tools required for the project. These resources help in the creation of the project plan and schedule.

When identifying staffing resources, consider the following questions:

  • Do you need to fill the team members' regular positions for the duration of the project? 

  • Are the team members properly trained for designing and deploying Exchange 2000 and Windows 2000? 

  • Do you need to hire consultants to augment your team? 

When identifying hardware resources, consider the following questions:

  • Do you have hardware available for a development and lab environment? 

  • Can you use existing production messaging servers to support Exchange 2000? 

When identifying software resources, consider the following questions:

  • Can you upgrade your existing software licenses to Exchange 2000? 

  • Which version of Exchange 2000 do you need to purchase? 

  • Do you need to obtain Windows 2000 licenses for Exchange users or have the licenses already been purchased? 

When identifying tools resources, consider the following questions:

  • Do you need to obtain a tool to aid in the migration of old mail? 

  • Do you require additional monitoring tools for your environment? 

Creating Required Project Plans

A project has multiple project plans, each listing the tasks that an individual team member performs. All of these plans form a Master Project Plan. You can consider the Master Project Plan the blueprint of your project, which details the planning of your project and helps ensure a smooth deployment.

The major sections of a Master Project Plan might include:

  • Product and Program Management 

  • Architecture/Engineering Document 

  • Test Plan 

  • User Pilot Plan 

  • Security Plan 

  • Budget 

  • Training Plan 

  • Communications Plan 

  • Deployment/Migration Plan 

  • Logistics/Operations Plan 

  • Risk Management Plan 

Building the Project Schedule

After completing a draft of the functional specification and master project plan, the team builds the schedule, based on the work outlined in the specification and master project plan. The team also decides on a release date for the final system. The project schedule includes the details of the four phases and the work required from the different team members. The team may need to reassess the schedule and modify the functional specification to achieve an acceptable release date for all involved.

It is important for the team to develop the master schedule and agree to it, because the team members will be held accountable for the schedule and will be measuring their progress against it. Creating detailed schedules with various milestones allows team members to measure their progress and quickly identify any issues that may impact the project schedule.

A sample Exchange 2000 schedule template created in Microsoft Project 2000 is included on the Microsoft Exchange 2000 Server Resource Kit companion CD. This template is organized around the four Microsoft Solutions Framework phases and includes the various tasks for each phase.

Phase III: Developing

The third phase of the project involves testing and verifying the designs and plans completed in the planning phase. The teams set up the equipment to be used in production, and follow the plans and designs to create the final systems or a portion of the final environment. A series of verification and pre-pilot tests occur on the system and the phase is complete when the user pilot testing has been performed and the systems are ready for the first production use.

The major steps in the developing phase are:

  • Validate the design and project plan 

  • Build the system 

  • Complete a pre-pilot test 

  • Complete a user pilot test 

Validating the Designs

You must validate the designs in a lab environment that contains hardware identical to the hardware that will be used in the production environment. You should verify the design aspects of the system according to the functional specifications and then test and verify installation procedures. It is important to approach the testing in a systematic way by using the test plan. For information about how and what to test, see "Setting Up a Test Environment" in this book.

Testing first begins with the individual components or servers to verify that the components will perform as configured according to the specifications. The tests identify possible problems that may arise in production because of a setting or configuration. After the individual components and servers perform as expected, you should test them at the systems level. In systems level testing, you test multiple servers or components to ensure proper operation.

Note Remember that these tests are still in a stable environment and final testing will be complete with the pre-pilot and user pilot testing. The verification tests merely verify the design and ensure that it is ready for the building of production systems.

Building the System

After you have successfully validated your designs in a lab environment, you can begin building the system with production hardware on the production network. At this point, the systems are almost ready for users. After the system is in place, you can begin the final testing phase.

Pre-Pilot Tests

The production hardware and systems are now in place and ready for a user pilot test. However, it is a good idea to perform a pre-pilot test of your system with a small group of technical users or project team members to verify the system operations. Having a group of technical users test the system before you make it available to mainstream users allows you to catch any bugs that slipped through the validation and testing. The chapter "Piloting Exchange 2000," will help you determine which features should be tested and how to test them. It is important to remember to follow the same procedures in the pre-pilot test as the procedures that will be used during the actual user migration, because the pre-pilot should test the procedures as much as it does the systems.

After receiving feedback from the pre-pilot participants, you can tune systems if required; then the system is ready for the final step: the user pilot.

User Pilot Test

After completing the pre-pilot test and reconfiguring the system, you should perform a user pilot test, which is the final step prior to actual deployment. The user pilot test should be performed with a group of users that are representative of all users. The size of the pilot group varies depending on the size of your deployment. Pilot users are usually volunteers because they must accept less reliability from a system not yet ready to be used by the whole company. Support, operations, and training should be in place as if it were a production deployment.

You should include the following items in the user pilot test:

  • Proper communications of the migration or rollout 

  • User training 

  • User documentation 

  • User install process 

  • User support 

  • Public folder, e-mail alias, or Web site setup for pilot feedback 

  • Pilot evaluation 

After the user pilot test is complete, you must perform an evaluation of the user pilot test. You must make a determination of whether the systems and procedures are ready to be deployed into production. It may be a good idea to partner with the pilot users to determine an acceptable criteria level for the new system. After approval by the project team and pilot users, the system is ready to be deployed.

It may be necessary, after receiving user pilot test feedback, to make modifications in migration procedures, user training, or the system itself. Remember to plan for this prior to deployment.

Caution Scope creep occurs when the customer of the new system attempts to add functionality to the system after the requirements are frozen. For example, often when the system undergoes pilot testing, users request features that may not have been included in the original requirements. There is a tendency to attempt to add this requested functionality at the last minute. However, it is best to deal with these requests in later versions of the system so that they do not impact the original scope of the project.

Phase IV: Deploying

The fourth and final phase of the project is deployment. In this phase, all users are migrated to the new messaging system according to the deployment or migration plan. Training is completed for users, and the operations team monitors the new system. After this phase is completed, the normal production and operations groups take control of the systems.

During this phase of the project, the deployment teams take control and the other teams are used to support the deployment as needed. Engineering and testing may be required for problem resolution, but the deployment teams are responsible for the majority of the work in this phase.

Migrating Users

Company-wide technologies such as messaging backbones, gateways to other systems, and Internet connections, should be deployed first. Server clusters in large data centers may also be considered core technology. After the core technologies are installed, you can identify servers to install in smaller locations.

Migrate users to the new system according to the migration plan that was finalized in the developing phase. Train users on the new system and train support staff to support the new system and users.

For example, Northwind Traders will deploy its main data center location first because it hosts the connectors to the Lotus Notes, Lotus cc:mail, and mainframe systems as well as the connection to the Internet for Simple Mail Transfer Protocol (SMTP). After the main data center is complete and stabilized, the deployment team deploys the local mailbox servers in the smaller regional offices.

Handing Off the Project to Production

When all of the user mailboxes have been migrated or deployed on the new system, hand the system off to the operations team. The systems are now considered production systems. The message operations team, or a similar group, monitors the systems and ensures proper operation.

Completing the Project

After the new system is in place and all of the deliverables are complete, the project team formally closes the project. The team establishes agreement that the project has been completed and deployed as specified in the project plan. The project team then conducts a project evaluation, in which it reviews areas that could be improved in future projects, and documents these findings for future project teams.

Proper project planning is a critical component to the overall success of your project and should be an integral part of your deployment of Exchange 2000. It is important to use a model that allows your team to be flexible but maintain a systematic approach that keeps the team on schedule while accomplishing the project goals. Many projects fail or run into difficulties partway into the deployment because the proper planning was not completed. By using these planning steps or a similar systematic approach to program planning, you will be on your way to a successful rollout of Exchange 2000.