Lesson 2: Building a Solid Project Foundation

There is a common misconception among computer experts that it takes only technical skills to master the challenges of implementing a messaging system. In reality, you do not need to be a technical expert to manage an infrastructure deployment project successfully—you only have to find the right people with the required technical skills and bring them together in your project team. The secret of success is your managerial skill to lead your project team and the organiza- tion through the project until the strategic goals are reached. The better you prepare yourself, the project team, and the organization for the project, the easier it will be to accomplish the actual infrastructure changes in the production environment.

This lesson covers several important issues that you need to address when preparing an implementation of Exchange 2000 Server. You will read about the structuring of a comprehensive project team according to MSF recommendations. You will also learn about the definition of project objectives and the clarification of project scope, constraints, and high-level risks.

After this lesson, you will be able to

  • Structure a project team according to the roles and responsibilities suggested in the MSF team model
  • Create a vision and scope document for an Exchange 2000 deployment project according to the recommendations in the MSF process model
  • Develop a risk management plan
  • Create the documents required to obtain a formal project approval from the project sponsor

Estimated time to complete this lesson: 60 minutes

Preparing the Deployment Project

The preparation of the deployment project is primarily the task of the product manager. However, you do not need to do all the work alone if you are able to assemble the project team right away. Appoint one or many program managers, depending on the extent of your project. As explained in Lesson 1, the program manager is primarily responsible for the technical specifications and should therefore be involved in the task of developing the strategic project goals as well as the assessment of project risks. With the help of the program manager and other team members, you will be able to prepare for the project more easily. Figure B.1 in Appendix B further illustrates the preparation phase.

Forming the Project Team and Team Structure

You have to master several tasks if you want to form an efficient project team. First, you need to clarify the individual roles and responsibilities in your team and find the right people to fill the open positions. Next, you need to define the relationships and communication paths between the team members. You don’t have to create a complex team hierarchy, but the clarification of communication paths helps every member to define his or her position in the team.

To assemble the project team, accomplish the following steps:

  1. Clarify the individual roles and responsibilities in your team.
  2. Appoint appropriate team members with managerial and technical skills.
  3. Define the communication paths in the team.

Identifying Project Team Members

As outlined in Lesson 1, the MSF team model suggests a structure of six roles for the project team, each with distinct responsibilities (that is, product manager, program manager, operations development, testing and quality assurance, user education and documentation, and logistics management), plus a project sponsor. For the purposes of the project preparation, it is usually sufficient to name the project sponsor, product manager, and the program manager, although additional team members may also be helpful. The project sponsor is typically an executive, director, vice president, or other member of upper management with the authority to make final project decisions. This person is not necessarily an active team member. More actively involved are the product manager, program manager, and others.

It is important to note that you can appoint team members at any time during the project. If you encounter specific requirements, just define additional roles as appropriate. For instance, you may want to contract an external technical trainer if an Outlook 2000 expert is not available in-house for end user training. It would not be necessary to involve this external trainer in every project activity. You can contract the trainer when the production rollout begins and dismiss this resource again when the last user is trained.

When appointing individual members, keep the following typical responsibilities of the various MSF team roles in mind.

  • Project sponsor Makes final decisions, emphasizes the importance of the project across the company, and ensures the commitment of management and staff.
  • Product manager Assembles the project team, develops strategic project goals, sets project priorities, manages the budget, maintains the risk assessment plan, and ensures that technical specifications correspond to business objectives. The product manager must have practical experience in project management and must be familiar with Exchange 2000 Server.
  • Program manager Defines and documents the future messaging infrastructure, including required features and functionality, and assists the product manager in formulating strategic goals. The program manager also ensures that the project stays on schedule, and should have project management experience. This person should have a Microsoft Certified Systems Engineer (MCSE) certification or equivalent experience with detailed knowledge of Exchange 2000 Server.
  • Operations development Assists the program manager in developing technical specifications. This person or group provides ideas on technical possibilities and explores options for an optimal implementation of Exchange 2000 Server. Operations development should have practical experience in deploying Exchange 2000 Server and should be familiar with the client applications that the organization intends to use, such as Outlook 2000.
  • Testing and quality assurance Prepares the test plans to verify the technical specifications and rollout strategies from operations development. This person or group tracks critical issues and performs scalability and performance checks. Testing and quality assurance works independently but in close relationship with operations development. Testing and quality assurance must be familiar with Windows 2000 and Exchange 2000 Server as well as the client applications that the organization intends to use for messaging.
  • User training and documentation Responsible for system documentation, designing, developing, and publishing user manuals and training material. User training and documentation helps the program manager to identify and meet end user needs. The user training and documentation team must have the skills to write clear and useful documentation and should have practical experience providing technical training to end users. Familiarity with Exchange 2000 Server and Outlook 2000 is required.
  • Logistics management Responsible for a smooth transition from project development to operations according to the project schedule. This person or group coordinates the installation of the system and client applications and is responsible for troubleshooting and handling of administration and support issues. The logistics management team must be familiar with the organiza-tion’s network infrastructure and should have a good relationship with external teams, such as network administration, system support, user help desk, solution providers, and vendors.

Tip


You can find a Microsoft Excel workspace to structure a project team according to the MSF recommendations in the \Chapter02\Worksheets directory on the Supplemental Course Materials CD. The filename is PROJECTTEAM.XLS. Complete the worksheet "Names and Titles" (the first tab in the Excel file); the remaining worksheets are filled automatically.

Building the Team Structure

Depending on your organization’s size and the extent of your project, it may be reasonable to assign individual members multiple roles. The program manager, for instance, could also be responsible for user education and system documentation. However, you should avoid delegating contrary roles to a single person. The developer of the deployment concepts, for example, should not test them as well. In fact, the operations developer should not be assigned any additional roles at all (Table 2.5). Otherwise, you risk delays in the project due to the reduction of resources for developing functional specifications and implementation procedures.

Table 2.5 Combinations of Team Roles According to MSF Recommendations

Project Sponsor Product Mgr. Program Mgr. Operations Dvlpmt Test & QA User Ed & Doc Logistics Mgmnt

Project Sponsor

X

U

U

U

U

U

U

Product Mgr

U

X

U

U

P

P

P

Program Mgr

U

U

X

U

U

P

P

Operations

Dvlpmt

U

U

U

X

U

U

U

Test & QA

U

P

U

U

X

P

P

User Ed & Doc

U

P

P

U

P

X

U

Logistics Mgmnt

U

P

P

U

P

U

X

P = Possible     U = Unlikely     X = Not Possible

Medium and large organizations often delegate individual tasks to groups of people, leading implicitly to a hierarchy of subteams underneath the core team. In this case, you should appoint a representative in each subteam to assume full responsibility for his or her group. Somebody must be in charge. The representatives of subteams then interact with each other as members of the core team to coordinate their activities. The representatives should have a full-time commitment to the project. Members of subteams can focus on carrying out their specific work. The following are the advantages of subteams:

  • The project responsibilities can be subdivided into small units relating to specific functional areas.
  • The work on planning documents can be accomplished in parallel, while the tasks are managed within each subteam autonomously.

Tip


The Microsoft Excel workspace PROJECTTEAM.XLS contains a worksheet called "Role Verification" to check whether a particular team member has been assigned conflicting roles. Click Check Role Assignments to highlight critical appointments. Switch back to the "Names and Titles" worksheet to resolve any conflicts.

Clarifying Team Hierarchy and Communication Paths

Proper team structure is not a guarantee of project success, but it is one of its foundations. All team members, while communicating with each other directly, typically report to the program manager, who in turn communicates progress, results, and other information to the product manager. The product manager, in turn, keeps the project sponsor and management updated. It is a good idea to document the communication paths in a chart to give every person involved in the project a precise outline of the team hierarchy. It is also helpful to document the communication paths to external contacts, such as system administration and user help desk (Figure 2.3).

Note


In addition to the actual communication paths, it is a good idea to define a meeting schedule and list communication media, such as a dedicated e-mail alias, to facilitate communication in the team. The team must meet on a regular basis to synchronize their activities. PROJECTTEAM.XLS contains a "Communications Plan" worksheet that can be used as a guide to document the communication requirements of your project team.

Figure 2.3 - A project team structure with relationships to external teams

Defining Strategic Objectives and the Project Scope

The vision and scope document describes the most important reasons for the deployment of Exchange 2000 Server and clarifies the desired results. It is vital that you clarify the most important project objectives to focus your team on relevant issues and to prioritize the various activities during the planning, testing, and deployment phases. The project sponsor and your team should provide you with input and review the objectives. All those involved need to agree with all of the objectives. As mentioned in Lesson 1, the sponsor’s signature on the vision and scope document represents the actual commencement of the planning activities.

You need to accomplish the following tasks to create the vision and scope document:

  1. Discuss the possible business benefits of Exchange 2000 with the project team and the sponsor to determine two or three compelling reasons for the project.
  2. Clarify the desired deployment methods.
  3. Define strategic goals based on the desired deployment methods and the business benefits.
  4. Define the scope of the project according to existing constraints.
  5. Propose a first solution for the deployment of Exchange 2000 Server.

Identifying Compelling Business Objectives

Compelling reasons for deployment of Exchange 2000 differ from business to business. Reducing the total cost of ownership (TCO) by consolidating thousands of users on a single server is not of interest for a small company, for instance, whereas another organization with 5000 users in one location may find this a very convincing argument. More often than not, your organization will have a messaging system in place. It is helpful to compare the features of your existing system with those of Exchange 2000 Server to find possibilities for improvements by using the latter. If you discuss the outcome of your product comparison within the project team and with the project sponsor, you will quickly identify two or three compelling reasons for implementing Exchange 2000. The com-parison of Exchange 2000 Server to other messaging systems was a topic in Chapter 1, "Introduction to Microsoft Exchange 2000 Server."

Note


Technical features and technological advantages help organizations to realize business benefits. Review the technical features and benefits of Exchange 2000 Server to outline how your organization can achieve business benefits.

Clarifying the Desired Deployment Method

When formulating strategic goals, concentrate on the most important objectives. Your strategic goals should describe the overall results you intend to achieve with the project. Intermediary stages are not of interest. The ultimate goal is usually the deployment of Exchange 2000 Server across an entire enterprise, but more specifically, such an undertaking can be classified as a new implementation, an upgrade, a migration, or a combination of these (see Figure B.2 in Appendix B).

It is important to refer to the desired deployment method explicitly because each method has different dependencies and requirements. A new implementation, for instance, refers to an installation of Exchange 2000 where no messaging system currently exists. An upgrade, on the other hand, describes the process of converting the resources of an earlier version of Exchange Server to Exchange 2000, which entails, among other things, integrating Exchange Server with Active Directory. A migration is synonymous with replacing a foreign messaging system with Exchange 2000 Server. Using available migration tools, you need to convert existing user data, such as messages, folders, and address books, and workgroup applications. New implementations, upgrades, and migration are covered in detail in Chapters 5 through 7.

Creating the Project Vision

Microsoft recommends formulating strategic goals in the form of a project vision, which needs to describe the future in measurable parameters. Examples of measurable parameters are the selected deployment methods, the number and names of locations where you want to install Exchange 2000 Server, the number of users, and whether you will deploy Outlook 2000 as part of the project. It is also practical to define a reasonable start date and estimate the project duration. However, keep in mind that it is not possible to provide an exact time line at this point. Determining an exact project schedule requires planning, but this is not a task in the project preparation phase. It is good practice to align the project start with a typical business event, such as the start of the new fiscal year, the next quarter in the calendar year, or any other event that suits you, and leave the duration open.

The following are some important questions to consider when formulating the project vision:

  • Is your organization planning to standardize its entire messaging environment on Exchange 2000 Server?
  • Is your organization planning to upgrade from an earlier version of Exchange Server?
  • Is your organization intending to replace foreign messaging systems with Exchange 2000 Server, and, if so, which foreign messaging systems do you intend to replace?
  • In how many locations are you planning to deploy Exchange 2000 Server, and what are their names?
  • Are you planning to deploy Outlook 2000 as part of the project?
  • How many users do you intend to support?
  • When is the deployment project supposed to begin?

Tip


You can find a Microsoft Excel workspace to develop a vision and scope document according to the MSF recommendations in the \Chapter02\ Worksheets directory on the Supplemental Course Materials CD. The filename is VISIONSCOPE.XLS. Complete the worksheets "Vision Statement," "Business Objectives," and "Scope and Constraints." A simple vision and scope document is created for you automatically on the "Vision and Scope Example" worksheet.

Determining Project Scope and Constraints

Your project vision does not need to take any constraints into account: It simply describes where you want to go. To determine an achievable scope, you need to analyze the factors that limit your ability to realize your goals. For example, your organization may consider a global deployment of Exchange 2000 Server, but if you cannot allocate the required budget resources, you will have to restrict the deployment to a specific region or a subset of offices and departments. The same is true if the project timeline is too aggressive (for instance, if you need to meet a certain deadline) or if the project team cannot handle such an enormous task right away. Technical factors can also limit the scope of the project. It may turn out, for instance, that important prerequisites are missing to migrate all users to Exchange 2000, such as connectivity or migration tools. In this case, you need to take a different approach (that is, return to the previous step and determine a different deployment method) or postpone the implementation of Exchange 2000 Server. Constraints are the real-world factors that force you to make compromises between the best imaginable and the best attainable solution.

The following constraints may force you to make trade-off decisions and narrow the scope of the project:

  • Budgetary limitations There is not enough money to accomplish the project to its full extent. A migration to Exchange 2000 Server, for instance, will likely require you to purchase new hardware, software, and licenses for additional users. Money also has to be invested in training on Windows 2000 Server, Active Directory, Exchange 2000 Server, and Outlook 2000.
  • Human resource limitations There are not enough people or there is not enough knowledge to implement Exchange 2000 Server to the desired extent. The members of your project team may be involved in other projects with a higher priority, or the sum of upgrade or migration issues may be too difficult to master. In all of these cases, it is advisable to scale back and perform the deployment in stages of subsequent projects. Multiple-phase deployments enable members of the project team to focus on more specific implementation issues.
  • Restricted schedule The project team must accomplish the deployment within a certain time frame. You may be forced to consider critical end dates, such as a rollout before a year-end closing. If this does not leave enough time to acquire the required work experience to ensure a successful rollout of Exchange 2000 Server in all locations of the organization, you need to limit the project scope.
  • Technical limitations Essential connectivity components and migration tools are missing or the migration of existing messaging and workgroup solutions requires too many resources. If you cannot migrate the user data and applications, you may consider a new implementation without preserving existing information or postpone the project until the required prerequisites and tools are available.

Note


Setting the project scope requires you to balance available resources and the project schedule with the desired extent of the deployment. In this context, you may have to separate essential features that the new messaging organization must provide from those that may be postponed until a later project.

Drafting a Solution Proposal

One of the quickest ways to achieve a common understanding of the future messaging environment is to demonstrate it visually with a drawing or diagram. For this reason, you should include a brief proposal of the future Exchange 2000 organization in the vision and scope document. It is sufficient to give a high-level description of the organization’s architecture, technical features, and services. You will create the actual functional specifications during the planning.

Assessing High-Level Project Risks

Every deployment project depends on a number of prerequisites that will not be delivered as part of the project. For instance, every messaging system requires a functioning computer network, but you will not start implementing the network in an Exchange 2000 project. The bad news is that every issue outside the scope of your project implies uncertainties that may have a negative impact on your undertaking. To continue the example, if your computer network does not function properly, Exchange 2000 Server cannot provide reliable messaging services to your users.

Uncertainties can be approached in two ways: Either you simply assume that the worst case will not occur (that is, the computer network will operate reliably) or you analyze the uncertainties more carefully to identify possible risks and develop corresponding mitigation strategies. For instance, you may take into consideration that there is a risk that the computer network does not operate reliably. A possible mitigation strategy could then be that the project team will stress test the computer network to ensure it can cope with the workload generated through e-mail messages. The less you assume and the better you manage, mitigate, and eliminate the risks in your project, the higher the likelihood of a successful project completion.

The risk management process involves the following activities:

  1. Identifying and documenting the risks to forewarn the project team
  2. Prioritizing the risks according to their probability of occurring and their potential impact on the project
  3. Devising a risk mitigation plan, including an outline of appropriate actions, metrics, and triggers that indicate when the project team must execute the mitigation plan
  4. Monitoring the metrics and triggers and tracking applied mitigation steps
  5. Creating an emergency plan for high-priority or critical risks to prepare the project team for worst case scenarios

Risk Identification and Prioritization

The first steps in risk management are risk identification and prioritization. You need to document any issues that you discover during the project in a master list of risks. Prioritization is important to direct the efforts of your project team toward the most critical issues. Ideally, you can eliminate all those risks that have a potentially extreme impact on the project. If this is not possible, monitor these risks continuously until they become irrelevant. For instance, the risk that a messaging connector to a foreign system cannot cope with the workload becomes irrelevant as soon as you have migrated all users to Exchange 2000 Server. Risks with a very low impact, on the other hand, may not require any attention at all.

To fully prioritize a risk, you need to assess its probability in addition to its impact. The risk probability is the likelihood that an adverse event will actually occur. For instance, a risk with a high impact (that is, a high severity) may have a low probability and may therefore be safely ignored. On a scale for impact and probability from 1 (low) to 3 (high), a risk’s priority can easily be determined using the formula Priority = Impact + Probability – 2, which results in a scale from 0 (none) to 4 (critical), as shown in Figure 2.4.

Typical risks that may adversely affect your deployment project include the following:

  • The Active Directory environment is not established or has been configured improperly.
  • Business units resist their migration to Exchange 2000 Server.
  • Direct connectivity between Exchange 2000 Server and legacy messaging systems is not supported.
  • Not all workstations meet the hardware requirements for Outlook 2000 when the deployment of Exchange 2000 Server begins.
  • The project exceeds its schedule or budget.
  • A project sponsor was not assigned.
  • The project team has no experience or limited experience with project management.
  • Storage capacity of existing servers is insufficient for Information Store requirements.
  • Hardware performance will not be sufficient to meet user demands.
  • Team members do not have the required knowledge to implement, administer, and maintain Windows 2000, Active Directory, or Exchange 2000 Server.
  • Third-party and custom workgroup solutions are not portable to Exchange 2000 Server.
  • Users have no previous experience with Outlook 2000 or other messaging clients supported by Exchange 2000 Server.

Figure 2.4 - Risk prioritization based on probability and impact

Risk Mitigation and Emergency Planning

You have two options to mitigate the risks in your project. As risk priority is measured in terms of probability and impact, mitigation can be achieved through lowering either or both of these elements. For example, the design of Active Directory has a measurable impact on the deployment of Exchange 2000 Server. It is unlikely that you can lessen the severity of impact, but you might be able to reduce the probability that the Active Directory design is critical, or unable to cope with the demand generated by servers and clients. You can reduce this risk by actively involving your project team in the design or optimization of the Active Directory environment.

A mitigation strategy may be a single action or a full plan of activities to lessen the risk. It is a good idea to create an emergency plan for all those risks that are deemed of high or critical priority, just to make the project team aware of them and to plan ahead. It is often too late to think about coordinated emergency plans when a critical problem occurs. The risk assessment workspace called RISKASSESSMENT.XLS, which you can find in the \Chapter02\Worksheets directory on the Supplemental Course Materials CD, allows you to specify an emergency plan for significant risks.

Preparing a Deployment Project for Contoso, Ltd

Contoso, Ltd is a fictitious firm that specializes in cutting-edge electronic design tools. With 4500 employees, headquarters in London, and offices in New York, Liverpool, and Edinburgh, Contoso is considering a move to Exchange 2000 Server. Currently, the company is using a variety of messaging systems, such as Lotus cc:Mail, Lotus Domino/Notes, Microsoft Mail, Exchange Server 5.5, and an in-house Professional Office (PROFS) system running on an IBM S/390. Contoso has a very difficult time keeping support and training costs under control. "It costs as much as £1500 annually to support each e-mail user," says Dan K. Bacon, Jr., Director of Information Systems. "I’m going to pull my hair out if our company continues its exponential growth."

The Project Team

Contoso is facing a complex deployment project in a challenging environment with numerous messaging systems. A high-performance team of technical experts is required to master the rollout. Dan K. Bacon, Jr., in his role as the product manager, has decided to structure his team according to the MSF team model.

Julia Moseley, Assistant Vice President and Chief Information Officer at Contoso, Ltd, will assume the position of the project sponsor. Moseley is a member of upper management with adequate power to promote the project across the entire organization. She is responsible for the departments of Information Systems, Office Integration, and User Services and reports to the Vice President, with a dotted-line to the Vice President of Finance and Administration.

Kelly Focht, Senior Messaging Administrator at Contoso, will assume the position of the program manager. As a member of the telecommunications team in the Information Systems department, she is responsible for administration and maintenance of client/server messaging systems. Kelly is an MCSE with detailed knowledge of Windows NT Server 4.0 and Exchange Server 5.5. As a Senior Messaging Administrator with more than 10 years of experience, she has superior analytical and problem-resolution skills.

Dan K. Bacon, Jr. has appointed Scott Cooper, Manager of IT Solutions, as the head of the operations development team with responsibilities for system engineering and deployment planning. John Fredericksen, Support Engineer, will be responsible for testing and quality assurance as well as the management of the production rollout. Yvonne Schleger, User Help Desk Specialist, will develop the training materials and system documentation, and Laura Norman, an external messaging consultant from Trey Research, will assist Kelly Focht in developing the functional specifications and rollout plans. To monitor project expenses against allocated budget, Ido Ben-Sachar, Business Accountant, will assume the position of a financial officer to assist the product manager (Figure 2.5).

Tip


For more information about Contoso’s project team, see CONTOSO_PROJECTTEAM.XLS, which is in the \Chapter02\Examples directory on the Supplemental Course Materials CD.

Vision and Scope for the Deployment Project

As Dan K. Bacon, Jr. mentioned, Contoso is planning to drastically decrease their annual support costs per desktop. The company can achieve this goal by standardizing their entire messaging environment on a high-end enterprise system that supports seamless Internet connectivity and Web-based and instant workgroup solutions and simplifying access to messaging resources through a tight integration with the network operating system. Contoso intends to increase its productivity and competitiveness and improve the user friendliness of its communications infrastructure.

Figure 2.5 - The project team of Contoso, Ltd

To develop an appropriate vision for the deployment project, Dan K. Bacon, Jr. considers the following goals:

  • Standardize the messaging environment for all 4500 employees on Exchange 2000 Server and Outlook 2000.
  • Upgrade from earlier versions of Exchange Server where necessary.
  • Replace all existing foreign messaging systems with Exchange 2000.

Accordingly, Bacon has developed the following vision statement: "Contoso, Ltd is planning to standardize its entire messaging environment on Exchange 2000 Server, which will be deployed in the four sites of London, New York, Liverpool, and Edinburgh. The company intends to upgrade the existing Exchange Server base. The existing messaging and collaboration systems, including Lotus cc:Mail, Lotus Notes, Microsoft Mail, and PROFS, will be migrated to the new platform. Microsoft Outlook 2000 will be installed on 4500 workstations during the rollout. The project will begin Q2/2001."

Bacon also assumes that he does not have the required resources to fully deploy Exchange 2000 Server. To avoid overwhelming the project team with too many challenges, he decides to narrow the project scope and focus on a migration of the numerous foreign messaging systems only. This involves plenty of work and helps to reduce the maintenance costs of Contoso. He postpones the upgrade of Exchange Server 5.5, which becomes the task of a follow-up project.

Correspondingly, Bacon proposes the following solution: Contoso will replace their PROFS environment with Exchange 2000 Server while utilizing the PROFS connector of Exchange Server 5.5 for message transfer and directory synchronization. The migration from PROFS involves the conversion of user messages and address books. Following this migration Lotus cc:Mail and Microsoft Mail will be replaced. The Exchange Server/Exchange 2000 organization will coexist with the Lotus Notes environment until existing Notes applications and information from Notes databases can be converted. Transfer strategies must be developed. To minimize hardware and software requirements, all migrated users will be placed on the same server system. At project completion, Contoso will have reduced their number of messaging systems to two, Exchange Server and Exchange 2000 Server, with one Exchange 2000 Server installed in each location. The existing PROFS, Lotus cc:Mail, MS Mail, and Lotus Notes connectors will be retired, and users can communicate in an Exchange 2000 organization operating in mixed mode.

Tip


For a complete example of a vision and scope document, see CONTOSO_VISIONSCOPE.XLS, which is in the \Chapter02\Examples directory on the Supplemental Course Materials CD.

High-Level Risks in the Deployment Project

Decades of IT experience have turned Bacon into a very cautious director. "People often criticize me for rating the risks of computer problems and failures higher than they probably are," he says, "but it’s better to put more effort into their prevention than into their resolution during the production rollout when the entire company is looking over your shoulder." The Director of Information Systems at Contoso prefers to do his homework well and thoroughly prepare for worst case scenarios. Bacon has identified three risks with a high or critical priority, as shown in Table 2.6.

Table 2.6 High-Priority and Critical Risks with Mitigation Strategies and Emergency Plan

Risk 1 Risk 2 Risk 3

Priority

High

Critical

Critical

Risk Description

Project team has no experience or limited experience with project management.

Team members have insufficient knowledge of Windows 2000, Active Directory, and Exchange 2000 Server.

Users have no previous experience with Outlook 2000 or other messaging clients supported by Exchange 2000 Server.

Owner

Product manager (Dan K. Bacon, Jr.)

Product manager (Dan K. Bacon, Jr.)

User education (Yvonne Schleger)

Due Date

June 2002

June 2002

July 2002

Suggested Mitigation

Provide training to ensure all team leaders have the required skills to manage their pro- ject tasks.

Develop training plan to ensure all team members receive appropriate training on Windows 2000 and Exchange 2000 Server.

Develop end user training material for Outlook 2000 and provide access to documentation and user manuals via the internal network.

Success Metrics

The team leaders understand their roles and responsibilities and can prepare the project according to MSF guidelines.

The team members are able to develop structured action plans within the project schedule.

The development of online training material is finished two weeks before the production rollout.

Trigger

Sponsor and team cannot agree on business objectives and scope.

Preparation of project plans slips more than two weeks behind schedule.

Online material is not available one week before the deployment.

Emergency Plan

Involve an external consultant with sufficient project management experience to assist the team in preparing the project.

Involve an external consultant with working knowledge in deploying Exchange 2000 Server.

Order self-paced training materials.

Tip


For a more detailed list of high-level project risks and mitigation strategies, see CONTOSO_RISKASSESSMENT.XLS, which is in the \Chapter02\Examples directory on the Supplemental Course Materials CD.

Activity: Preparing a Deployment Project

In this activity, you will assemble a project team, create a vision and scope document, and assess high-level project risks for a fictitious company called Consolidated Messenger, which was already introduced in Chapter 1, "Introduction to Microsoft Exchange 2000 Server."

Tip


You can use the various workspaces from the \Chapter02\Worksheets directory on the Supplemental Course Materials CD to accomplish this activity. Completed workspaces are available in the \Chapter02\Examples directory. Their file names start with CONSOLIDATED_*. You can change the information in these files to produce different versions of the vision and scope document.

Scenario: Consolidated Messenger

Consolidated Messenger is a local broadcasting company with 1500 employees in Portland, Oregon. The company is currently operating a Microsoft Mail environment. All employees use Outlook 2000 as their messaging client. According to Senior IT Administrator Gregory J. Erickson, Consolidated Messenger is planning to implement Exchange 2000 Server to modernize its communications infrastructure and lower maintenance costs. Ideally, the project will begin with the third quarter of 2001. Erickson has performed a functional gap analysis, which you can find in the \Chapter01\Examples directory on the Supplemental Course Materials CD. The filename is CONSOLIDATED_MESSENGER.XLS.

Potential key players for the deployment project of Consolidated Messenger are as follows:

  • Richard Carey, Network Administrator Carey has many years of experience in administering Windows-based computer systems. He is an MCSE and has successfully designed and deployed Windows 2000 Server and Active Directory in Consolidated Messenger’s computer network. Richard has sufficient project management experience and knowledge of Outlook 2000 but no experience with Exchange 2000 Server or earlier versions so far.
  • Gregory J. Erickson, Senior IT Administrator Erickson has already familiarized himself with Exchange 2000 Server and is convinced that this platform is the right choice for Consolidated Messenger.
  • Eva Corets, System Support Specialist Eva is responsible for system design and maintenance at Consolidated Messenger. Among other things, it is her daily responsibility to ensure proper server backups.
  • Jonathan Perera, President and CEO Perera believes that his company can gain a competitive edge by modernizing its communications infrastructure.
  • Prasanna Samarawickrama, system consultant, self-employed Consolidated Messenger has hired Samarawickrama to help the project team master the deployment of Exchange 2000 Server successfully. She has been an Exchange expert for many years and has been involved in Exchange 2000 deployment projects since October 2000.

It is your task to prepare Consolidated Messenger to implement Exchange 2000 Server.

  1. Assign each key player one or multiple appropriate roles in the project team.
  2. Answer the following questions to develop an appropriate vision statement for Consolidated Messenger.

    1. Is the organization planning to standardize its messaging environment on Exchange 2000 Server?
    2. Is the organization planning to upgrade from an earlier version of Exchange Server?
    3. Does the organization intend to replace foreign messaging systems with Exchange 2000 Server?
    4. Which foreign messaging systems do you intend to replace?
    5. In how many locations are you planning to deploy Exchange 2000 Server?
    6. What are the names of the locations where Exchange 2000 Server will be deployed?
    7. Are you planning to deploy Outlook 2000 as part of the project?
    8. How many users do you want to support?
    9. When is the deployment project supposed to begin?

  3. Formulate a vision statement for Consolidated Messenger.
  4. Identify three compelling objectives for the deployment of Exchange 2000 Server at Consolidated Messenger. (Refer to the functional gap analysis CONSOLIDATED_MESSENGER.XLS from Chapter 1.)
  5. Answer the following questions to determine relevant project constraints.

    1. Are the necessary funds available to fully deploy Exchange 2000 Server in the network infrastructure?
    2. Do you have to meet an aggressive deadline with your deployment of Exchange 2000 Server?
    3. Can you ensure through training and other measures that the project team has the required knowledge to fully deploy Exchange 2000 Server?
    4. Describe the resulting project scope.
    5. Propose a high-level solution for Consolidated Messenger.
    6. List three high-level risks and possible mitigation strategies.
    7. Lesson Summary

      Deployment of Exchange 2000 Server typically affects the entire enterprise. It is therefore vital to obtain official approval from a project sponsor. For this purpose, you should create a vision and scope document containing a statement that describes the strategic goals of the project. These goals will help you guide the project team through the deployment project. It is also important to define the project scope and propose solutions or sample scenarios for implementing Exchange 2000 in the production environment. You need to clarify the scope of your undertaking to ensure the achievability of the project goals within existing limitations and constraints.

      It is primarily the task of the product manager, with the help of the program manager and other members of the project team, to prepare the deployment project. The individual roles, responsibilities, and structure in the project team are defined as part of the project preparation. Another important task in this phase is risk management, which remains an important task during later project phases as well. To ensure project success, it is vital to assess high-level risks as early as possible and identify possible mitigation strategies and emergency plans. The project team must be aware of and prepared for critical issues.



MCSE Microsoft Exchange 2000 Server Design and Deployment Training Kit(c) Exam 70-225
MCSE Training Kit (Exam 70-225): Microsoft Exchange 2000 Server Design and Deployment (Pro-Certification)
ISBN: 0735612579
EAN: 2147483647
Year: 2001
Pages: 89

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