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.
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.
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:
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.
Tip
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:
Tip
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
Figure 2.3 - A project team structure with relationships to external teams
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:
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
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.
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:
Tip
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:
Note
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.
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:
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:
Figure 2.4 - Risk prioritization based on probability and impact
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.
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."
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
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:
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
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
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
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:
It is your task to prepare Consolidated Messenger to implement Exchange 2000 Server.
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.