This phase can also last several weeks. High level architectural decisions are made during this phase: how many Cisco Unity servers? what is the general arrangement? how will it fit into the customer's current environment?
T2.1.2 Confirm project milestones, roles, and responsibilities.
T2.1.3 Set a clear expectation as to what type of information the customer will provide during the Plan Phase Details Page.
T2.1.4 Confirm site(s) and logistics.
T2.2 Create the Why Create a High Level Design -- a summary of everything that you plan to do, including your migration strategy and how you expect the design to look after Cisco Unity is deployed. If you have a phased-migration strategy, show how your voice messaging/unified messaging and electronic messaging infrastructure will look at the end of each phase.
T2.2.2 Indicate the mailstore options and configurations that will be used with Cisco Unity.
T2.2.3 Indicate how Cisco Unity will integrate with the existing phone systems.
T2.2.4 Perform a Why Do a Feature Evaluation of Cisco Unity – with a goal of thoroughly understanding the available feature set, including features that you might not plan to use.
T2.2.5 Perform a dependency assessment – understand the dependencies that Cisco Unity has on the existing messaging and voice infrastructure. If possible, investigate the dependencies in a lab setting.
T2.2.6 Perform an impact analysis – how will Cisco Unity impact the current messaging and voice environment, and vice versa? You can perform focused before-and-after trend periods, or you can evaluate the current and past performance of your messaging systems. This includes understanding how often these systems are unavailable and also how often their dependencies are unavailable (this includes domain controllers, name-resolution hosts, network gear, and so on).
T2.3.1 For each site (Include the messaging infrastructure in your diagram.)
T188.8.131.52 Include each PBX, the number of voice ports and the integration method.
T184.108.40.206 Include your messaging servers and their dependency servers, such as domain controllers and name-resolution hosts. During your survey, confirm that each messaging system uses the name-resolution hosts and domain controllers/Global Catalog servers that you survey. Cisco Unity uses these same servers when deployed.
T220.127.116.11 Indicate the domain and Windows site that the messaging servers and other dependency servers are installed into. Even if you have a Domino installation, Cisco Unity needs to be installed into a Windows domain, even if it is for Cisco Unity only. So, you still need to either use existing Windows domains or create new ones for Cisco Unity, depending on how many locations you have.
T18.104.22.168 Indicate the subscriber density. Note the organization of the user population for each location and messaging system that Cisco Unity will serve. This is actually quite important when you grant permissions to the service accounts that Cisco Unity uses to service its subscribers. So, if you note that mail-enabled users on Exchange server A and server B at location X are organized in domain Y in OU containers C and D, you have the information that you need for the Cisco Unity server that will install into that same location.
T2.3.2 Include the network infrastructure in your diagram.
T22.214.171.124 Indicate the LAN topology.
T126.96.36.199 Indicate the WAN topology.
T188.8.131.52 Indicate the Quality Of Service specifications.
T184.108.40.206 Indicate the placement and function of firewalls.
T2.3.3 Indicate the physical placement of Cisco Unity and dependency servers.
T220.127.116.11 Note infrastructure requirements (rack space, switch port space, power).
T2.3.4 Indicate the voicemail networking methodology that will be used between Cisco Unity and legacy voice messaging servers, or between Cisco Unity sites.
T2.4 Conduct a Why Do a Gap Analysis between requirements and the customer's existing network hardware and software to determine which core infrastructure and technologies may be necessary to implement Cisco Unity.
T2.4.1 Review the feature/functional analysis to verify that the solution will work for the customer.
T2.4.2 Identify any gaps that require workarounds, and any critical paths to implementation.
T2.4.3 Adjust the project timeline accordingly.
T2.4.4 Prepare a system report, discusing gaps and alternatives to gaps; confirm that the customer understands the implications of the changes, including cost and/or functionality.
T2.6.1 Estimate hardware and software costs. Take into account capacity, any planned overprovisioning, and licensed features that may be deployed.
T2.6.2 Estimate service costs for project management, installation and cut-overs.
T2.6.3 Create a Bill of Materials.
T2.7 Perform Why Do Lab Trials as part of your feature evaluation of Cisco Unity. The important part of this effort is to put Cisco Unity in a semiproduction environment and test it under load or in different ways.
T2.7.1 Verify interoperability.
T18.104.22.168 Determine whether Cisco Unity can integrate with each legacy PBX. Does Cisco Unity already have support for the PBX, or will you need to perform an out-of-box test procedure? For more information, refer to the Cisco Interoperability Portal.
T22.214.171.124 Determine the mechanism Cisco Unity will use to integrate with each legacy PBX, and how it differs from the current system integration.
T126.96.36.199 Determine if the PBX can support Cisco Unity.
T188.8.131.52 Determine the PBX hardware, software and programming requirements for interoperability with Cisco Unity.
T184.108.40.206 Determine the Cisco Unity configuration options required for interoperability with the PBX.
T220.127.116.11 Execute test plans to verify PBX interoperability. If necessary, perform Out-of-Box Qualification testing.
T2.7.2 Pilot Cisco Unity in production, if required. This should give you a very good idea of what your users expect and how the Cisco Unity system will behave in your production environment.
T2.7.3 Review the results of your Why Do Lab Trials and out-of-box testing, and adjust the project timeline accordingly.
S2.3.1 Obtain and review the customer's current operational procedures and policies.
S2.3.2 Interview the appropriate operations personnel and key stakeholders to determine the "project handoff" policy. Gather information about the customer's current support infrastructure, including data network and telephony processes, network and network management documentation, and metric reports.
S2.3.3 Document systems, processes, flow-through, tools, people, skills, and best practices for the customer's future reference.