2.4 Transferring responsibility to the operations team

---

I have worked with many corporate IT organizations in a variety of industries. No two IT organizations have been structured in the same manner. However, almost all IT organizations, regardless of industry, corporate size, or geographic dispersion, share one common feature: All tend to isolate their operations team from the groups that design and implement new technologies. Unfortunately, only the more enlightened Exchange deployment and migration project teams include representation from the people who will be tasked with managing the Exchange environment once it becomes operational.

It is not unusual for Exchange deployment and migration project teams to simply not consider how the Exchange environment will be managed until the migration project nears completion. The migration project team is doing daily battle with issues that demand immediate attention. Management issues can too easily be postponed while the migration team is busy with more immediate issues. As a result, many companies design and implement complete Windows domain model and Exchange organizational infrastructures with little concern for operational staff or procedures. The operations team and the help desk can provide valuable insight because they routinely deal with the reality of how users interact with software products. These key people often have better insight for how a particular implementation or design will affect the users.

Concern, panic, and lengthy meetings often result after the deployment and migration team transfers management responsibility to the operations team. Too often, this 'transition' takes the form of a migration project team member passing a stack of design and migration project documents over the cubicle wall as the project team heads out the door to their project completion celebration. At least, that is how it often seems to the operations team.

There are several ways to improve transition from the project team to the operations team. First and most important, the operations team should be represented on the Exchange deployment and migration team. Their representation on the team should be on an equal basis with other project team members. Their participation is no less important than that of the technologists designing the Exchange infrastructure, the network designers, and the training coordinators. It is also important to remember that the operations team consists of a variety of different functions, including individuals who will manage and monitor the Exchange environment, the help desk personnel, and the operators responsible for backups. Every decision made during the Exchange deployment project needs to factor in the future operational considerations.

The operations group should begin managing the Exchange environment early in the deployment project while the environment is still relatively small. Operational errors are more easily forgiven when only 100 pilot users are impacted than when 100,000 users find themselves without electronic mail (e-mail) capabilities.

Finally, the deployment and migration team-including the operations team representatives-should fully document all staffing and management requirements for the Exchange environment. This should not be a random selection of migration project documents. Instead, it needs to be a wellorganized set of documents that will be used far beyond the end of the deployment project. This should be a living set of documents that evolve as the environment and available tools change. Note that 'documents' does not necessarily restrict you to something printed on paper. Web pages are an acceptable, and perhaps preferred, format for this documentation. Regardless of the chosen media, the documentation should minimally address the following areas:

• Exchange deployment mission statement. What were the original goals for deploying Exchange in the organization? How have these evolved over time?

• Architectural design. What is the Exchange organizational topology? What implementation decisions were made regarding the Exchange architecture? This should include naming conventions that were selected.

• Network infrastructure. What requirement does Exchange have regarding the underlying network infrastructure? What is the topology of the underlying network? I am constantly amazed-and disappointed-by the number of otherwise well-managed organizations that do not have a current network map and do not know the available bandwidth between their various locations.

• Monitoring baseline. A monitor baseline should be taken once the Exchange environment is working correctly and consistently. This can be used for comparison in the future if the environment begins to exhibit unwanted characteristics.

• Server build documentation. The Exchange servers deployed during the initial migration project are unlikely to be the last. Additional servers will be required as the organization grows. The team that deployed the original set of Exchange servers may no longer be available when it is time to install new servers. How should these additional servers be configured?

• Server connection documentation. If new connector servers need to be added, how should they be configured? How should servers in different routing groups be connected? What is the corporate-approved method for connecting the Exchange e-mail environment to other corporate e-mail environments such as Novell GroupWise or Lotus Notes? How should the Exchange environment be connected to external environments such as the Internet?

• Client build documentation. New versions of Outlook will be developed. How was Outlook tailored for the corporate rollout? What were the critical factors considered when building the Outlook client kit?

• Application installation instructions. New desktop devices will be added. What are the steps for installing Outlook? How should the desktop operating system and network services be configured to support Outlook?

• Operational procedures. What procedures need to be followed to keep the Exchange environment healthy and happy? This should include a timetable showing which procedures should be performed daily, weekly, monthly, and so on.

• Backup and recovery procedures. What needs to be done to prevent loss of data when disaster strikes? What are the correct procedures for backing up an Exchange server? How can these backups be used in various situations, such as recovering from loss of a server, recovering from loss of a disk drive, recovering individual mailboxes, and so on?

• Administrative procedures. How should common administrative functions be performed, such as adding and removing users, creating system distribution lists, and so on? Who should perform these administrative functions?

• Service level agreements. What are the expectations of the departments who rely on the Exchange environment? How much, if any, scheduled downtime is acceptable? What documented agreements, such as SLAs, have been made with these groups of users?

• Escalation procedures. How does a user report a problem? If the problem cannot be corrected in a timely manner, how-and to whom- should the problem be escalated? How are reported problems logged and tracked? What type of problem/resolution knowledge database will be maintained to help solve problems?

• Frequently asked questions. What were the most frequently asked questions during the Exchange rollout? What were the most common problems reported to the help desk during the migration?

• Management model. Will a centralized operations team manage the entire corporate Exchange environment or will some tasks be delegated to regional personnel? Will regional administrators be allowed or required to add and remove users, or will these functions be centralized? Will regional operators perform Exchange backups? Will they also be responsible for restoring data from the backup tapes?

• Roles and responsibilities. Who is involved in the ongoing management of the Exchange environment? What skills and expertise are required to perform each of these roles?

• Training recommendations. What training is recommended for each of the essential operational roles?

These documents should act as the basis for the ongoing implementation of the Exchange environment. Changes over time to the standard configurations or any part of the Exchange environment need to go through a standard change control process, which ensures that the documented procedures always reflect the actual operational environment.

Including the operations team in the Exchange deployment and migration-project and providing this level of documentation should result in a much smoother transition from rollout to full operation and will help to reduce future user satisfaction issues as the operations staff becomes completely informed.

---