Flash-Cut Migrations Example and Overview Benchmark: 35,000 Voicemail Only Subscribers Total Time from Unity Sale to Deployment: 13 Months Total Staffing Involved: 25 Equivalent Headcount total across customer, partner and Cisco Strategy: Perform extensive lab testing, bring Unity up in parallel with legacy system, cut over a small number as a pilot followed soon after by remainder of the enterprise.   Benefits of the Flash-Cut Approach Migration is much shorter and therefore can be more cost effective. Training can be synchronized corporate-wide. This leads to economies of scale as a single message campaign goes out to the whole company. The only integrations with legacy voicemail systems are intended to be long term, therefore the effort expended getting them configured and working properly is not "throw away" work. Full new feature set uniformly available to all users. Simplified integrations to legacy systems and simplified VM dial-plan complexity. Simplified user training. No need to train users or confuse users on how to message to legacy users and retrain when those users are migrated to new platform. IE: Network message. The process to send a message to Joe User might/could change after they're migrated to new platform. Simplified Distribution List creation. (For example, in one deployment with 2500 DL's and 20k users, there would have been no way to properly maintain the DL's between the 2 systems.)   Drawbacks of the Flash-Cut Approach If an issue is experienced system-wide, it will impact a larger number of subscribers than if the rollout was incremental. Lack of Internal Support staffing exposure and time to ramp up could lead to possible extended downtime. Initial additional work to import subscribers and perform validation tasks. More demand on user training since training might be limited to a single week. Not all users might get trained due to PTO etc. Higher demand on the system during self-enrollment period. Self/Pre-enrollment needs to be open sooner depending on user base. Help desk demand and staffing following the cut is higher for the first few weeks so higher staffing needs may be required. Requires a significantly larger amount of pre-planning compared to an incremental migration. Depending on the configuration and integration, the fall-back plan can be complicated. Requires that deltas be maintained between the two systems for user changes, for example, new employee addition or termination and deletion between the time when subscribers are imported and the cut-over date. Likely requires more total peak staffing to execute and follow up at cut-over time and 1-2 days after.   Gradual Roll-Out Migrations Example and Overview Benchmark: 35,000 Voicemail Only Subscribers Total Time from Unity Sale to Deployment: 20 Months Total Staffing Involved: 20 Equivalent Headcount total across customer, partner and Cisco Strategy: Perform extensive lab testing, progress through cutting subscribers over to Unity incrementally starting with pilot deployments and following up with cutting over per logical partition such as departments or geographic area.   Benefits of the Gradual Roll-out Approach Limits the exposure to smaller groups of subscribers with each cutover, therefore allowing for more focused attention if things go wrong. Allows additional time for support staffing exposure and training. Allows additional time to import/create user base and validate feature sets. Lower demand on the system during each self enrollment period. More uniform demand/impact on Help desk and staffing during the migration. Depending on the configuration and integration, the fall-back plan may be simpler than in a flash-cut migration. No requirement to maintain deltas between the 2 systems on users changes. IE. New employee, Employee termination and deletion prior to cut.   Drawbacks of the Gradual Roll-out Approach During migration, this approach complicates integrations to legacy systems and adds to VM dial-plan complexity. Each incremental step requires integration work to the legacy system that is only temporary and will be removed once the following incremental steps are taken. This can actually create more risk, as there are more opportunities for things to go wrong. Increases risk of allowing customer to go back to old system simply because new system is different (seen at CCE w/PIMG). Gives competition more time to FUD the customer and position their newer offerings. New feature set is not uniformly available to all users during deployment. Some features may not be available until all users have migrated. Complicates user training. During depoyment, users must be trained on how to message to legacy users, then retrained when those users are migrated to new platform. Adds complexity to Distribution List creation, as distribution lists must be maintained on both legacy and new systems during migration. ... View more

The legacy system analysis ensures that you thoroughly understand the existing voicemail system usage from a technical standpoint. This step actually tells you how to configure Unity, allowing you to develop configuration details such as schedules, call handlers, and routing rules. If you skip a step in data collection here, you may end up under- or over-sizing your Unity deployment for the actual system load and usage. ... View more

The preliminary design options give you a better idea of what type of work will need to be performed, and how it will be performed. They are the meat of the preliminary design proposal, which helps formulate the beginnings of the high-level design, and allows you to determine which design areas will need additional work and focus. You will refine the preliminary design over the next two phases (Planning and Design), ultimately preparing a very detailed design plan. ... View more

The feature/functional evaluation step builds upon the initial solution requirements exercise and the preliminary design proposal. In this step, you really put together the picture of required infrastructure and training that will be a foundation of your Unity deployment process. If you don't do your homework thoroughly at this point, you're likely to run into serious issues during Day 2 support, as users begin to realize that they lack the knowledge or tools to perform the operations they're used to doing with their previous messaging system. ... View more

The preliminary design proposal gives you a rough idea of how Unity will fit into the existing infrastructure, how it will replace the existing voice messaging system(s), and what additional infrastructure will be required to support Unity. (You will build on this and refine the required infrastructure when you perform a feature/functional evaluation of Unity.) The preliminary design proposal also serves to collect and organize all of the site-specific information in one place, for future reference. ... View more

You develop solution requirements so that you can determine up front whether Unity meets the needs of the organization. Any gaps that you identify between requirements and functionality will need to be addressed in your subscriber training plan. ... View more

  Project Plan for Ocsi-Co Unity Deployment Overview Need to migrate approximately 4000 Outlook/Exchange users per site at each of three nationwide sites from legacy voicemail to Cisco Unity Unified Messaging. Critical Dates, Critical Paths, Etc. Support contract for legacy vm systems ends--approx 9 months from start of project. IT department end-of-quarter network change freeze--last week of April, last week of May. Training department resources must be engaged--three months prior to start of training. Team Project Sponsor: Jay Warren, CTO, Ocsi-Co Customer Project Team: Kelly Bader, BJ Price, Win Stetter Cisco Team: Robin Arnel, Pat Wallace, Chris Jenkins Partner Team: Pat Jones, Jas Wright ... View more

An overall project plan allows you to collect, organize and sequence the high-level tasks that need to be accomplished for the deployment to be successful. It will also get you thinking about who will perform the various tasks, and what dependencies may arise between tasks or between team members. You create the project plan early in the project, but you will continually refine your plan as you move through the six phases of the deployment. At the end of the project, it's a good idea to review the project plan once more, noting down areas that were missed or that needed more attention and up front planning. ... View more

Operate Phase Solution moves from cutover to production. Take care to monitor the hardware and software as well as the subscriber experience. TECHNICAL TRACK GOAL: Monitor the solution, baseline performance and troubleshoot as necessary. Keep an eye on your support staff and mechanisms.  Look for opportunities to improve results with additional training. T5.1 Read and Follow Existing Documentation Why Follow Documentation       T5.1.1 Cisco Unity Maintenance Guides       T5.1.2 Cisco Unity Maintenance Checklists       T5.1.3 Vendor-specific maintenance and operation guides       T5.1.4 Vendor-specific Best Practices guides       T5.1.5  Build a baseline of system operation and performance T5.2 Monitor the solution Why Monitor The Solution?       T5.2.1 Cisco Unity            T5.2.1.1 Event logs            T5.2.1.2 EMS            T5.2.1.3 CUPID            T5.2.1.4 Perfmon            T5.2.1.5 Connectivity to DC/GC            T5.2.1.6 Port usage reports            T5.2.1.7 DbWalker            T5.2.1.8 Permissions Wizard in Report Mode            T5.2.1.9 Physical disk space            T5.2.1.10 Anti-virus software / CSA            T5.2.1.11 Failover monitor            T5.2.1.12 Licensing / License Pooling            T5.2.1.13 Backup and restore procedures            T5.2.1.14 Updates and patches            T5.2.1.15 Recommended Engineering Specials            T5.2.1.16 Cisco Unity Networking            T5.2.1.17 Integration into existing network management/monitoring utilities       T5.2.2 Telephone system             T5.2.2.1 Legacy PBX                 T5.2.2.1.1 Traffic analysis                 T5.2.2.1.2 Alarms, warnings, errors                 T5.2.2.1.3 Intermittent call flows and transfers            T5.2.2.2 Dialogic devices                 T5.2.2.2.1 Alarm log                 T5.2.2.2.2 Call log                 T5.2.2.3.3 Config.ini files            T5.2.2.3 Callmanager                      T5.2.2.3.1 RTMT                      T5.2.2.3.1.1 Alert Central                      T5.2.2.3.1.2 Cisco Unified Reporting       T5.2.3 Mailstores             T5.2.3.1 Exchange                 T5.2.3.1.1 Microsoft Exchange Server Analyzer Tool                 T5.2.3.1.2 Performance console                      T5.2.3.1.2.1 System Monitor                      T5.2.3.1.2.2 Performance Logs and Alerts                 T5.2.3.1.3 Exchange Management and Status Tool            T5.2.3.2 Domino                 T5.2.3.2.1 Domino Performance Tuning document       T5.2.4 Active Directory            T5.2.4.1 Domain controller performance using various counters                 T5.2.4.1.1 DCDiag                 T5.2.4.1.2 Netdiag            T5.2.4.2 Active Directory replication                 T5.2.4.2.1 ReplMon                 T5.2.4.2.2 Repadmin            T5.2.4.3 Event logs            T5.2.4.4 DNS                 T5.2.4.4.1 On DC/GC                      T5.2.4.4.1.1 Microsoft TechTip "Verifying Your Basic DNS Configuration"                      T5.2.4.4.1.2 IPconfig /flushdns                 T5.2.4.4.2 Cisco Unity                      T5.2.4.4.2.1 ipconfig /flushdns                      T5.2.4.4.2.2 nslookup       T5.2.5 Network            T5.2.5.1 All hardware NICs            T5.2.5.2 All switch ports            T5.2.5.3 Firewalls            T5.2.5.4 WAN traffic            T5.2.5.5 QOS T5.3 Staff Why Pay Attention to Staff       T5.3.1 Identify Roles and Responsibilities       T5.3.2 Moves/Adds/Changes            T5.3.2.1 Monitor the number of requests.            T5.3.2.1 Monitor time to completion - SLA.            T5.3.2.2 Check accuracy.            T5.3.2.3 Assess their technical capabilities.       T5.3.3 Troubleshooting            T5.3.3.1 Tools and utilities            T5.3.3.2 Problem reporting procedures            T5.3.3.3 Opening TAC cases            T5.3.3.4 Escalation procedures       T5.3.4 Backup/Restore procedures            T5.3.4.1 Nightly/weekly backups            T5.3.4.2 Disaster recovery       T5.3.5 Inter-departmental communication                 T5.3.5.1 Change Management       T5.3.6 Network documentation SUBSCRIBER PREP TRACK GOAL: Continue to solicit feedback from your subscriber community. Document their problems and issues.  Include both problems that are real and those that are perceived. Act on them in a timely fashion to prevent The List. S5.1 Subscriber communityWhy Monitor Subscribers       S5.1.1 Cut-over punch list            S5.1.1.1 Continue to staff the Help Desk as long as required.       S5.1.2 Schedule regular meetings to get feedback from subscribers.            S5.1.2.1 Go-To people            S5.1.2.2 FBR -- Feedback by roaming.            S5.1.2.3 Web site/Wiki/Email/Voicemail.  Encourage end user feedback.            S5.1.2.4 Stay in touch with your power users.            S5.1.2.5 Stay in touch with your key departments.       S5.1.3 Identify and act upon issues.            S5.1.3.1 Real problems            S5.1.3.2 End-user perceptions            S5.1.3.3 Differences between the old voicemail system and Cisco Unity       S5.1.4 Address the issues before negativity festers. S5.2 The List       S5.2.1 What is The List?            S5.2.1.1 The List is a prioritized document of every problem and complaint subscribers have regarding the new Unity voice mail system.       S5.2.2 What causes The List?            S5.2.2.1 Several factors cause The List:                 S5.2.2.1.1 Not resolving Unity related problems in a timely fashion                 S5.2.2.1.2 Allowing complaints and problems to bubble up to senior management                 S5.2.2.1.3 Not staying in touch with the subscriber community                 S5.2.2.1.4 Not accounting for key features of the old voicemail system in the new Unity deployment                 S5.2.2.1.5 Ineffective subscriber training       S5.2.3 What happens once The List gets created?            S5.2.3.1 Nothing good:                 S5.2.3.1.1 Meetings are held on a regular basis.                 S5.2.3.1.2 The Unity deployment is now under a microscope.                 S5.2.3.1.3 Time and effort are spent on managing the political issues that could be used on the technical issues.       S5.2.4 How do you stop The List once it happens?            S5.2.4.1 Indentify and resolve all technical issues as quickly as possible.            S5.2.4.2 Engage the subscriber community and solicite feedback.       S5.2.5 How do you keep it from happening?            S5.2.5.1 Monitor the new Unity deployment closely.            S5.2.5.2 Isolate and resolve all technical problems immediately.            S5.2.5.3 Stay in close contact with the subscribe community.            S5.2.5.4 Actively seek out user feedback. ... View more

Operate Phase Solution moves from cutover to production. Take care to monitor the hardware and software as well as the subscriber experience. [edit] TECHNICAL TRACK      GOAL: Monitor the solution, baseline performance and troubleshoot as necessary. Keep an eye on your support staff and mechanisms.  Look for opportunities to improve results with additional training. T5.1 Read and Follow Existing Documentation Why? Examples More Info T5.1.1 Cisco Unity Maintenance Guides T5.1.2 Cisco Unity Maintenance Checklists T5.1.3 Vendor-specific maintenance and operation guides T5.1.4 Vendor-specific Best Practices guides T5.1.5  Build a baseline of system operation and performance T5.2 Monitor the solution Why? Examples More Info T5.2.1 Cisco Unity T5.2.1.1 Event logs T5.2.1.2 EMS T5.2.1.3 CUPID T5.2.1.4 Perfmon T5.2.1.5 Connectivity to DC/GC T5.2.1.6 Port usage reports T5.2.1.7 DbWalker T5.2.1.8 Permissions Wizard in Report Mode T5.2.1.9 Physical disk space T5.2.1.10 Anti-virus software / CSA T5.2.1.11 Failover monitor T5.2.1.12 Licensing / License Pooling T5.2.1.13 Backup and restore procedures T5.2.1.14 Updates and patches T5.2.1.15 Recommended Engineering Specials T5.2.1.16 Cisco Unity Networking T5.2.1.17 Integration into existing network management/monitoring utilities T5.2.2 Telephone system  T5.2.2.1 Legacy PBX T5.2.2.1.1 Traffic analysis T5.2.2.1.2 Alarms, warnings, errors T5.2.2.1.3 Intermittent call flows and transfers T5.2.2.2 Dialogic devices T5.2.2.2.1 Alarm log T5.2.2.2.2 Call log T5.2.2.3.3 Config.ini files T5.2.2.3 Callmanager      T5.2.2.3.1 RTMT T5.2.2.3.1.1 Alert Central T5.2.2.3.1.2 Cisco Unified Reporting T5.2.3 Mailstores  T5.2.3.1 Exchange T5.2.3.1.1 Microsoft Exchange Server Analyzer Tool T5.2.3.1.2 Performance console T5.2.3.1.2.1 System Monitor T5.2.3.1.2.2 Performance Logs and Alerts T5.2.3.1.3 Exchange Management and Status Tool T5.2.3.2 Domino T5.2.3.2.1 Domino Performance Tuning document T5.2.4 Active Directory T5.2.4.1 Domain controller performance using various counters T5.2.4.1.1 DCDiag T5.2.4.1.2 Netdiag T5.2.4.2 Active Directory replication T5.2.4.2.1 ReplMon T5.2.4.2.2 Repadmin T5.2.4.3 Event logs T5.2.4.4 DNS T5.2.4.4.1 On DC/GC T5.2.4.4.1.1 Microsoft TechTip "Verifying Your Basic DNS Configuration" T5.2.4.4.1.2 IPconfig /flushdns T5.2.4.4.2 Cisco Unity T5.2.4.4.2.1 ipconfig /flushdns T5.2.4.4.2.2 nslookup T5.2.5 Network T5.2.5.1 All hardware NICs T5.2.5.2 All switch ports T5.2.5.3 Firewalls T5.2.5.4 WAN traffic T5.2.5.5 QOS T5.3 Staff Why? Examples More Info T5.3.1 Identify Roles and Responsibilities T5.3.2 Moves/Adds/Changes T5.3.2.1 Monitor the number of requests. T5.3.2.1 Monitor time to completion - SLA. T5.3.2.2 Check accuracy. T5.3.2.3 Assess their technical capabilities. T5.3.3 Troubleshooting T5.3.3.1 Tools and utilities T5.3.3.2 Problem reporting procedures T5.3.3.3 Opening TAC cases T5.3.3.4 Escalation procedures T5.3.4 Backup/Restore procedures T5.3.4.1 Nightly/weekly backups T5.3.4.2 Disaster recovery T5.3.5 Inter-departmental communication      T5.3.5.1 Change Management T5.3.6 Network documentation [edit] SUBSCRIBER PREP TRACK      GOAL: Continue to solicit feedback from your subscriber community.  Document their problems and issues.  Include both problems that are real and those that are perceived.  Act on them in a timely fashion to prevent The List. S5.1 Subscriber community Why? Examples More Info S5.1.1 Cut-over punch list S5.1.1.1 Continue to staff the Help Desk as long as required. S5.1.2 Schedule regular meetings to get feedback from subscribers. S5.1.2.1 Go-To people S5.1.2.2 FBR -- Feedback by roaming. S5.1.2.3 Web site/Wiki/Email/Voicemail.  Encourage end user feedback. S5.1.2.4 Stay in touch with your power users. S5.1.2.5 Stay in touch with your key departments. S5.1.3 Identify and act upon issues. S5.1.3.1 Real problems S5.1.3.2 End-user perceptions S5.1.3.3 Differences between the old voicemail system and Cisco Unity S5.1.4 Address the issues before negativity festers. S5.2 The List S5.2.1 What is The List? S5.2.1.1 The List is a prioritized document of every problem and complaint subscribers have regarding the new Unity voice mail system. S5.2.2 What causes The List? S5.2.2.1 Several factors cause The List: S5.2.2.1.1 Not resolving Unity related problems in a timely fashion S5.2.2.1.2 Allowing complaints and problems to bubble up to senior management S5.2.2.1.3 Not staying in touch with the subscriber community S5.2.2.1.4 Not accounting for key features of the old voicemail system in the new Unity deployment S5.2.2.1.5 Ineffective subscriber training S5.2.3 What happens once The List gets created? S5.2.3.1 Nothing good: S5.2.3.1.1 Meetings are held on a regular basis. S5.2.3.1.2 The Unity deployment is now under a microscope. S5.2.3.1.3 Time and effort are spent on managing the political issues that could be used on the technical issues. S5.2.4 How do you stop The List once it happens? S5.2.4.1 Indentify and resolve all technical issues as quickly as possible. S5.2.4.2 Engage the subscriber community and solicite feedback. S5.2.5 How do you keep it from happening? S5.2.5.1 Monitor the new Unity deployment closely. S5.2.5.2 Isolate and resolve all technical problems immediately. S5.2.5.3 Stay in close contact with the subscribe community. S5.2.5.4 Actively seek out user feedback. ... View more

Implement Phase This phase varies depending on the company's approach, but typically lasts between 3 and 12 months. TECHNICAL TRACK GOAL: This is all about progressing from testing Cisco Unity in a very controlled lab       environment all the way through until the last subscriber is cut over. T4.1 Why Create a Project Plan       T4.1.1 Develop a project management plan.            T4.1.1.1 Flash or Phased cut?            T4.1.1.2 Identify project leaders.                 T4.1.1.2.1 Who is the ultimate decision maker?                 T4.1.1.2.2 Who has input into the decision making process?                 T4.1.1.2.3 How will you resolve deadlocks?            T4.1.1.3 Define minimum requirements to move to next phase.       T4.1.2 Determine Project Schedule            T4.1.2.1  Per-site schedule                 T4.1.2.1.1 What are the minimum requirements to move on to the next site?       T4.1.3 Develop Resource Plan.            T4.1.3.1 Who needs to be where when?       T4.1.4 Identify Risks and Risk Mitigation Plans.            T4.1.4.1 Go/No Go Decision points            T4.1.4.2 Develop Escalation Plan.                 T4.1.4.2.1 Define technical escalation procedures.                      T4.1.4.2.1.1 What is your escalation path?                      T4.1.4.2.1.2 Will escalation resources be local or remote?                 T4.1.4.2.2 Define management escalation procedures.                      T4.1.4.2.2.1 Who are your escalation points?                 T4.1.4.2.3 Define change order escalation procedures.                      T4.1.4.2.3.1 Have emergency change management approval/process in place.            T4.1.4.3 Identify key business units.                 T4.1.4.3.1 Create prioritized list.            T4.1.4.4 Identify key subscribers.       T4.1.5 Develop communications plan.            T4.1.5.1 Define project visibility status meetings and procedures.            T4.1.5.2 Define project visibility progress reports and procedures.            T4.1.5.4 Determine end-user communication procedure.                 T4.1.5.4.1 Create designated go-to people per department.                 T4.1.5.4.2 Web content                 T4.1.5.4.3 Drop sheets            T4.1.5.5 Determine communication procedure surrounding escalations.            T4.1.5.6 Define executive and technical email aliases.            T4.1.5.7 Create list of key support personnel names, numbers and email addresses.            T4.1.5.8 Determine user feedback mechanism -- how will you stay in touch with user community?       T4.1.6 Internal kickoff meeting            T4.1.6.1 Review Project Plan, Dates, Roles, and Responsibilities.            T4.1.6.2 Review Communications Plan.            T4.1.6.3 Review Escalation Plan.            T4.1.6.4 Review Risks.       T4.1.7 External kickoff meeting.            T4.1.7.1 Confirm Project and Milestones Dates.            T4.1.7.2 Confirm Project and Day 1 Cutover Roles and Responsibilities.            T4.1.7.3 Review Communication Plan.            T4.1.7.4 Review Escalation Plan. T4.2 Thoughts on Staging the Solution       T4.2.1 Hone the site-specific implementation plan.             T4.2.1.1 Define specifits of implantation strategy (flash or phased).            T4.2.1.2 Produce hardware configurations for each site.            T4.2.1.3 Produce software configurations for each site.            T4.2.1.4 Produce hardware installation task checklist.            T4.2.1.5 Produce software installation task checklist.            T4.2.1.6 Produce a cut sheet for each site.       T4.2.2  Install            T4.2.2.1 Install and test new and upgraded circuits.            T4.2.2.2 Install and test new and upgraded trunks.            T4.2.2.3 Have spare hardware on site where possible.            T4.2.2.4 Install core products.                 T4.2.4.4.1 Rack and stack equipment.                 T4.2.4.4.2 Install UPS.            T4.2.2.5 Document serial numbers.            T4.2.2.6 Load software.                 T4.2.2.6.1 Confirm against most recent version.       T4.2.3 Configure            T4.2.3.1 Network infrastruture            T4.2.3.2 Cisco Unity                 T4.2.3.2.1 Legacy system MAC freeze date                 T4.2.3.2.2 System configuration                 T4.2.3.2.3 Subscriber information            T4.2.3.3 Phone System integration                 T4.2.3.3.1 CallManager                 T4.2.3.3.2 Legacy Integration                      T4.2.3.3.2.1 Configure Legacy PBX Line Cards                      T4.2.3.3.2.2 Configure Analog Gateways                      T4.2.3.3.2.3 Configure Legacy Dial Plan                      T4.2.3.3.2.4 Configure TIE Signaling (QSIG) Features            T4.2.3.4 Voicemail Integration                  T4.2.3.4.1 Configure Networking Cisco Unity Bridge (AMIS VPIM Bridge).                 T4.2.3.4.2 Configure System Settings.                 T4.2.3.4.3 Configure Features / Class of Service.       T4.2.4 Test            T4.2.4.1 Develop a comprehensive test plan that includes at least the following:                 T4.2.4.1.1 Basic internal call flows to correct subscriber greetings (Bsy, RNA)                 T4.2.4.1.2 Basic external call flows to correct subscriber greetings (Bsy, RNA)                 T4.2.4.1.3 MWI On and Off                 T4.2.4.1.4 Message retrieval                 T4.2.4.1.5 Message forwarding                 T4.2.4.1.6 Transfers from Cisco Unity                 T4.2.4.1.7 Notification outcalls to both internal and external devices                 T4.2.4.1.8 Load testing                 T4.2.4.1.9 TRaP                 T4.2.4.1.10 Cisco Unity networking to other Cisco Unity servers                 T4.2.4.1.11 Cisco Unity networking to third-party voicemail systems (AMIS, Bridge, VPIM)                 T4.2.4.1.12 Cross-box login                 T4.2.4.1.13 Transfers and call flows from application specific Call Handlers                 T4.2.4.1.14 Fail over to secondary Cisco Unity server and retest.            T4.2.4.2 Execute the test plan well in advance of Day 1 Cutover.            T4.2.4.3 Resolve any call failures.            T4.2.4.4 Check network for errors.       T4.2.5 Monitor                 T4.2.5.1 Start monitoring the solution for errors, warnings, alarms, etc.                 T4.2.5.1.1 May be able to prevent problems during Day 1 Cutover            T4.2.5.2 Introduce the customer's staff to the monitoring process                 T4.2.5.2.1 Effective monitoring is critical to Day-2 success T4.2.6 Subscriber Aclimation           T4.2.6.1 Allow subscribers to access the new system - see below. T4.3 Implementation  (Implement Phase Details Page)       T4.3.1 Pre-cut procedures            T4.3.1.1 Review hardware for warnings/errors.            T4.3.1.2 Review hardware configurations.            T4.3.1.3 Enable diagnostic traces.            T4.3.1.4 Establish technical and executive conference bridges.            T4.3.1.5 Create "tiger" teams for problem resolution.            T4.3.1.6 Have emergency change management procedures in place.            T4.3.1.7 Have access to system components readily available.            T4.3.1.8 Have a way to send data to and receive data from outside parties.       T4.3.2 Provide Implementation Support            T4.3.2.1 Provide Helpdesk Support                  T4.3.2.1.1 Prepare to staff for longer than expected.            T4.3.2.2 Provide Onsite Technical Support per Implement Phase Details Page.                  T4.3.2.2.1 Prepare to staff for longer than exptected.            T4.3.2.3 Provide support for Receptionist.            T4.3.2.4 Provide support for Executive Assistance.            T4.3.2.5 Contact go-to team members on a regularly scheduled basis.            T4.3.2.6 Keep in touch with end-user community.            T4.3.2.6 Monitor the key business units/users identified earlier. T4.4 Monitor SUBSCRIBER PREP TRACK GOAL: The focus here is on sequencing the communications and training and      differentiating the power users of voicemail from those that only use     it casually. Also, just like the Technical, it is good to test out      the training materials in a "lab" environment. S4.1 Why Staff and End User is Important       S4.1.1  Prepare for End-User Training        S4.1.1.1 Customize End-User Training       S4.1.2 Conduct End-User Training         S4.1.2.1 Conduct technical training       S4.1.2.2 Train Users on Self Help Tools.       S4.1.2.3 Set customer expectations that first few days may be rocky.       S4.1.2.4 Define potential problems and resolutions.       S4.1.2.5 Review Help Desk and Go-To procedures.       S4.1.3 Staff Training       S4.1.3.1 Conduct staff training.       S4.1.4 Access System During Staging       S4.1.4.1 Subscriber Access       S4.1.4.1.1 Open enrollment       S4.1.4.1.2 System familiarity and practice            S4.1.4.1.2.1 Normal users            S4.1.4.1.2.2 Power users            S4.1.4.1.2.3 Special requirements users            S4.1.4.1.2.4 Executive level users        S4.1.4.2 Staff Access       S4.1.4.2.1 Administrative practice       S4.1.4.2.2 Help Desk rehersal       S4.1.4.2.3 System monitoring and maintenance S4.2 Staff Training IT Admin and Help Desk  (Day 2)            S4.2.1 Prepare for IT Admin and Helpdesk Training based on plans developed earlier in the project.         S4.2.1.1 Consult Staff Development Plan for Details on Formal and Information Training Requirements for Helpdesk, IT Admins, and Operations       S4.2.1.2 Customize Informal Training for Helpdesk, IT Admins, and Operations S4.2.2 Informal Basic Training for All (Helpdesk, IT Admin, and Operations)       S4.2.2.1 Detailed Review of "As Built" Documentation       S4.2.2.2 Train on Changing Configuration on Cisco Systems and 3rd Party Applications       S4.2.2.3 Train on Gotchas Associated with Making Changes (access lists, etc.) ... View more

Design Phase This phase typically lasts a couple months and involves the customer working  with their partner, and possibly Cisco Advanced Services and/or UCBU  representatives. TECHNICAL TRACK GOAL: The focus here is to get down to nuts and bolts detail on the design. T3.1 Create the Why Do Low Level Design -- a very detailed, thorough plan that  contains all the data necessary to build an Implement Phase Details Page.           T3.1.1 Create the Cisco Unity system description -- the criteria necessary  to build each Cisco Unity server you install. Include the following information:             T3.1.1.1 Cisco Unity system configurations -- How each Cisco Unity server  should be configured including how you should set up your subscriber templates,  classes of service, distribution lists, naming conventions, extensions, other  subscriber data.           T3.1.1.2 Cisco Unity hardware configurations -- The physical layout of the  hardware including how you plan to organize files and applications on the hard  drives of each server.           T3.1.1.3 Cisco Unity networking configurations -- For each Cisco Unity  server, detail the dialing plan that you use with Cisco Unity. Show how  subscribers on each Cisco Unity server can be addressed by subscribers on other  Cisco Unity servers or legacy voicemal systems. Show a digital networking table  depicting how it will be set up for each Cisco Unity server.           T3.1.1.4 Physical network connectivity -- Show exactly how each Cisco Unity  server connects to the network and communicates with each and every server that  it services or depends upon. Show the IP addresses and server/DNS names of each  server that Cisco Unity communicates with. Show switch port settings such as  speed/duplex, VLAN, etc.      T3.1.2 Identify the Cisco Unity switch integration detail -- explain exactly  how Cisco Unity will integrate with each switch that each Cisco Unity server  services. This includes the voice ports and the switch-integration  configuration.            T3.1.2.1 If you are using Dialogic gateways to integrate with a legacy PBX,  document their IP addresses, switch port settings, physical location and  connection to the PBX. Document PBX settings such as LTN assignments, hardware  assignments, serial port settings, extension numbers, hunt group pilot numbers.           T3.1.2.2 If Cisco Unity is integrated with CallManager, show the network  connection. Does it use the same VLAN or a different VLAN? Show the actual IP  addresses on the cards           T3.1.3 Identify the Cisco Unity messaging infrastructure detail -- Include  the following:           T3.1.3.1 Cisco Unity domain usage -- Indicate for each Cisco Unity server  the domain names and domain controllers that Cisco Unity will use, and the  Global Catalog server that Cisco Unity will use.            T3.1.3.1.1 Remember that Cisco Unity for Exchange must be installed into the  same Windows site as the Exchange servers that it services and must use the same  domain controller and Global Catalog server as these Exchange servers. List the  directory OUs where all  mail-enabled users are located in Active Directory for  the same Exchange servers that Cisco Unity services.           T3.1.3.1.2 If your Cisco Unity design involves Domino only, you must  indicate which Windows domain Cisco Unity is installed into. Remember that Cisco  Unity uses the Windows domain and that Domino might not; also note that Cisco  Unity's interaction with Domino primarily depends on DUC and the Domino domain  and not the Windows domain, even though a Windows domain is required for Cisco  Unity only. If you dedicate a Windows domain for your Cisco Unity installations,  note that in your design. Also note how each Cisco Unity server accesses and  uses the domain controller for the Windows domain where it is installed.           T3.1.3.2 Cisco Unity directory usage - Your directory capacity-planning  exercise should have helped you determine the impact that legacy voice-messaging  objects created in Active Directory have on your directory. Indicate location  and where these objects will be created. Include particulars about the detail  and activities involved in performing the schema extension, in the case of  Active Directory, or in installing DUCS, in the case of Domino.           T3.1.3.3 Name resolution -- For each Cisco Unity server, indicate which  name-resolution hosts will service Cisco Unity.           T3.1.3.4 Messaging system - For each Cisco Unity server, indicate which  server will be its partner server and which servers Cisco Unity will service.           T3.1.3.5 Service accounts and administrative access -- Indicate how each  Cisco Unity server will be accessed and how the service accounts will be used,  as well as their names, their level of permissions, who will manage them, and  what is necessary for management (such as password policies, permissions checks  and verification, auditing, and so on).            T3.1.3.5.1 For each Cisco Unity server, note the service accounts that will  be used or created for Cisco Unity.           T3.1.3.5.2 You also must consider how the servers will be accessed  administratively. Is OS-level access treated differently than the Cisco Unity  application level?           T3.1.3.5.3 If you plan to use an existing administrative policy or procedure  within your organization, indicate that and note how it will be applied to Cisco  Unity.           T3.1.3.5.4 When you indicate the accounts that you will use, you might want  to address both the installation of and operations of Cisco Unity, which can be  considered two different activities.           T3.1.3.6 End-user access -- For each Cisco Unity server, indicate which  levels of access are to be allowed for your end users. Will it be TUI only? Are  only some end-users allowed to access the GUI web? What about directly accessing  the server? Are any end-users allowed or required to access the Cisco Unity  server directly?           T3.1.3.7 Security considerations -- Make sure that you not only include  security considerations in your design, but that you also use the lab trials and  production pilot to ensure that Cisco Unity is capable of supporting whatever  you indicate in your design,           T3.1.4 Indicate Cisco Unity administration and management design specifics.  Address how Cisco Unity should be administered and indicate any design issues  associated with your administrative plan. If bandwidth is an issue for remotely  accessing the Cisco Unity System Administrator, or if you need to run remote  administrative clients to access the server, indicate that in this section.            T3.1.4.1 Consider administrative access -- which accounts or which users  need to access each Cisco Unity server and how.            T3.1.4.1.1 Your administrative plan should include how mail-enabled users  are imported into Cisco Unity and also how those users are managed after they  are imported.           T3.1.4.1.2 As a part of your design topology, indicate your administrative  model and how it will support normal Cisco Unity administration, including  subscriber management (subscribers, distribution lists, and so on), audio-text  applications, and the Cisco Unity server system configuration, especially its  connectivity to a legacy switch, Cisco Unified Communications Manager, or both.           T3.1.4.1.3 What tools do you use? Indicate this and set up a policy for how,  when, and where these tools are used.           T3.1.4.2 Document Cisco Unity system management -- monitoring the server's  resources and performance, as well as also proactively monitoring the server's  ongoing, daily activity. This means that you will monitor Cisco Unity at  different levels: the OS (event logs, SNMP service, Performance Monitor), Cisco  Unity itself (traces, port status, Cisco Unity-specific performance activity,  logs, and so on), application event viewer logs (possibly using the  event-monitoring service), and other components, such as security, antivirus,  and other management tools.           T3.1.4.3 Indicate the subscriber account-naming conventions, and make sure  that your design uses the same naming conventions as your existing user accounts  database.           T3.1.4.4 Indicate support considerations. Whom do subscribers call for  problems? Whom do your tech support engineers contact for operational issues  during each phase of the migration? How does moving from legacy voice messaging  to unified messaging affect how subscribers are supported?           T3.1.5 Create and perform any customer certification testing (if required).           T3.1.6 Conduct a detailed Design Phase Details Page.            T3.1.6.1 Prepare for the Why Do Low Level Design presentation. Customize a letter  of understanding with design specifics and customer remediation  responsibilities.           T3.1.6.2 Present the Why Do Low Level Design.            T3.1.6.2.1 Present Letter of Understanding.           T3.1.6.2.2 Obtain Signed Letter of Understanding. SUBSCRIBER PREP TRACK      GOAL: Refine and finalize training materials and subscriber communications plans. S3.1 Continue working on your subscriber preparation.           S3.1.1 Determine the scope of the migration from a legacy voicemail system  to Cisco Unity.            S3.1.1.1 What data will need to migrate from the legacy voicemail system to  Cisco Unity?           S3.1.1.2 Who will perform the research on the legacy voicemail system and  mine the data?           S3.1.1.3 What access to systems or documentation will they require?           S3.1.1.4 How will you handle their requests for additional information?           S3.1.2 Continue to document the existing legacy voicemail configuration.            S3.1.2.1 What menu services are currently in use?           S3.1.2.2 What announcement services are being used? How will the new  messages get recorded?           S3.1.2.3 How many system distribution lists are being used?           S3.1.2.4 What zero-out targets are used?           S3.1.2.5 How will the migration impact voicemail networking?           S3.1.2.6 Are there any special departments or groups that have unique  configurations in the existing legacy voicemail system?           S3.1.3 Begin to develop your migration support plan.            S3.1.3.1 How soon before the Day 1 Cutover will subscribers be able to access the  new voicemail system and record new personal greetings?           S3.1.3.2 How long after the Day 1 Cutover will subscribers be able to access old  messages on the old voicemail system?           S3.1.3.3 What impact will the Day 1 Cutover have on the existing voicemail pilot  numbers and remote access?           S3.1.4 Start thinking about your subscriber support strategy.            S3.1.4.1 Who will staff the help desk? How long will it be available to  end-users? Will you have live bodies, a group mailbox or both? What turnaround  time do you plan to commit to for new requests/problems?           S3.1.4.2 What printed documentation will you distribute?           S3.1.4.3 What web-based resources will you utilize?           S3.1.4.4 Think about having dedicated contact points per department.           S3.1.4.5 How will you communicate status to the end-user community?           S3.1.5 Continue work on your subscriber training plan.            S3.1.5.1 Who will need be trained?           S3.1.5.2 Who will be your trainers?           S3.1.5.3 What training documentation will be required?           S3.2 Develop the Why Do Staff Training Plan.           S3.2.1 Job Role Training Requirements            S3.2.1.1 Determine job role tasks and responsibilities.           S3.2.1.2 Determine knowledge and skill requirements.           S3.2.2 Develop curriculum maps.            S3.2.2.1 Determine training requirements.           S3.2.2.2 Determine who will conduct training.           S3.2.2.3 Determine who will be trained. ... View more

Plan Phase 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? TECHNICAL TRACK GOAL: Produce a Why Create a High Level Design. T2.1     Hold a projectWhy Do Planning Kick Off.            T2.1.1     Confirm project and milestones dates.            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.1     Create a Why Create a High Level Design description.            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.2.7     Review the Why Develop Preliminary Design Options.                      T2.2.7.1     Phased cutover                      T2.2.7.1.1     Document how deployment will look after each phase.                      T2.2.7.2     Flash cutover                      T2.2.7.2.1     Think about potential intermittent/split deployment options. T2.3     CreateWhy Create Site Specific Diagrams.            T2.3.1     For each site  (Include the messaging infrastructure in your diagram.)                       T2.3.1.1     Include each PBX, the number of voice ports and the integration method.                      T2.3.1.2     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.                      T2.3.1.3     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.                      T2.3.1.4     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.                      T2.3.2.1     Indicate the LAN topology.                      T2.3.2.2     Indicate the WAN topology.                      T2.3.2.3     Indicate the Quality Of Service specifications.                      T2.3.2.4     Indicate the placement and function of firewalls.            T2.3.3     Indicate the physical placement of Cisco Unity and dependency servers.                      T2.3.3.1     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.5      Perform a Why Do a Security Analysis.            T2.5.1     Obtain and review the customer's current security procedures and policies.            T2.5.2     Assess and document the security procedure and policy requirements for the proposed solution. Document any issues and gaps and the plan to remediate them. T2.6     Perform a Why Do a Budget Analysis.            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.                      T2.7.1.1     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.                      T2.7.1.2     Determine the mechanism Cisco Unity will use to integrate with each legacy PBX, and how it differs from the current system integration.                      T2.7.1.3     Determine if the PBX can support Cisco Unity.                      T2.7.1.4     Determine the PBX hardware, software and programming requirements for interoperability with Cisco Unity.                      T2.7.1.5     Determine the Cisco Unity configuration options required for interoperability with the PBX.                      T2.7.1.6     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. SUBSCRIBER PREP TRACK GOAL: Begin the subscriber training process. S2.1     Create your Why Create a Communication Strategy for how you will communicate this change to your subscribers.            S2.1.1     Identify a subscriber training plan.                      S2.1.1.1     Who needs to be trained?                      S2.1.1.2     What training is required?                      S2.1.1.3     What training materials are available?                      S2.1.1.4     What training materials need to be created?                      S2.1.1.5     How will users be trained?                      S2.1.1.6     Who will provide training?            S2.1.2     Determine the Cisco Unity subscriber density.                        S2.1.2.1     Note the organization of the user population for each location and messaging system that Cisco Unity will serve.                      S2.1.2.2     Review and clean up the existing database from each voice messaging server, in preparation for importing users into Cisco Unity. S2.2     Review the Why Review Planning Outcomes, and adjust the project timeline accordingly. S2.3     Perform an Why Do an Operational Readiness Assessment.            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.            S2.3.4     Perform an Why Do an Operational Readiness Assessment Why Do a Gap Analysis. S2.4     Compile the data needed for Why Prepare for Design Phase from your preparation and planning activities.            S2.4.1     Include the outcomes of the feature/functional analysis.            S2.4.2     Include the outcomes of the subscriber usage analysis. ... View more

Preparation Phase This phase typically lasts several weeks. The purpose of this phase is to spend time understanding what the current voice messaging system offers, taking a look at current voicemail usage behavior, and then capturing that as the requirements that Cisco Unity must meet. TECHNICAL TRACK GOAL: Develop project timelines, solution requirements and create a preliminary design. T1.1  Develop an overall project overview and plan. Why? Example More Info       T1.1.1  Identify the "Compelling Event" -- capture and document the high-level project plan, goal or objective for the project.       T1.1.2  Determine critical timelines -- identify the critical dates and any major technical and stakeholder roadblocks.       T1.1.3 Identify team players -- who is the project sponsor at the customer, project team at the customer, Cisco team, partner team? T1.2  Define and develop solution requirements. Why? Example More Info       T1.2.1 Make a first pass at collecting solution requirements.            T1.2.1.1 Start by developing high-level system requirements (for example, the solution must replace a legacy voicemail system).            T1.2.1.2 Document the network availability and redundancy requirements for the overall system, including hardware and software.            T1.2.1.3  Document any high level integration requirements.            T1.2.1.4  Document any migration requirements for the overall system.            T1.2.1.5  Document and understand how business-level requirements will impact the proposed solution.            T1.2.1.6  Identify critical business units.            T1.2.1.7  Determine the customer support model and support requirements for the overall system.            T1.2.1.8 Determine the high-level training requirements. High-level training requirements should cover the necessary user and administration training that will be needed. It is important to factor in number of users, how to address geographically dispersed users, available online tools, and types of users who will have specialized needs.       T1.2.2 Review the requirements and develop acceptance criteria that determine which requirements are mandatory, and what is acceptable or unacceptable for each requirement.       T1.2.3 Match the requirements to Cisco Unity's capabilities.  Determine which requirements can be met, and which cannot.       T1.2.4 Finalize the decision.  Determine if a Cisco Unity solution can meet the mandatory requirements and acceptance criteria.       T1.2.5 Create a rough timeline for the project based on a review of the requirements you've developed. T1.3  Put together a preliminary design proposal. Why? Example More Info       T1.3.1  Perform a site survey.            T1.3.1.1 Gather existing documentation, such as directions to each site, site maps, descriptions of network centers, descriptions of the physical network topology at each site, and any other documentation related to the architecture at each customer location.            T1.3.1.2  Perform an equipment survey.            T1.3.1.2.1  Determine the current number of voice-messaging systems, and the number of voice-messaging systems to be replaced.            T1.3.1.2.2  Identify the quantity and location of circuit-switched PBXs or CallManager clusters to be used by Cisco Unity.            T1.3.1.2.3  Identify the quantity and location of messaging systems to be used by Cisco Unity.            T1.3.1.2.4  Identify the quantity and location of other messaging components to be used by Cisco Unity (AD, DC, GC, DNS).            T1.3.1.2.5  Identify any voicemail networking requirements.       T1.3.2 Create a deployment model specification. Determine which deployment model combinations you will employ. You might end up with multiple combinations, depending on the size of your organization and your site classifications.            T1.3.2.1  Microsoft Exchange deployment models            T1.3.2.2  IBM Lotus Domino deployment models            T1.3.2.3  Cisco Unity Connection deployment models            T1.3.2.4 Centralized vs. Distributed deployment            T1.3.2.4.1 Centralized deployment            T1.3.2.4.1.2 Advantages/Disadvantages            T1.3.2.4.2 Distributed deployment            T1.3.2.4.2.2 Advantages/Disadvantages T1.4 Perform a feature/functionality evaluation of Cisco Unity -- with a goal of thoroughly understanding the available feature set, including features that you might not plan to use. Why? Example More Info       T1.4.1 Understand differences between traditional voice-mail functionality and unified messaging, including message storage and handling differences.       T1.4.2 Perform a dependency assessment -- understand the dependencies that Cisco Unity has on the messaging infrastructure. If possible, investigate the dependencies in a lab setting.       T1.4.3 Perform an impact analysis -- how will Cisco Unity impact the current messaging 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).       T1.4.4 Perform capacity planning -- evaluate your messaging infrastructure to determine if it can handle the extra load placed on it as a whole or on separate servers. If you are migrating from a legacy voice-messaging system, you must understand what the expected traffic increase is and also what the increase in the number of messages and message size means to your messaging infrastructure.       T1.4.5     Perform a UM readiness assessment (See chapters 13 and 14 of the Deployment & Solutions Guide.)            T1.4.5.1     Microsoft Exchange            T1.4.5.2     IBM Lotus Domino T1.5 Develop preliminary design options, and include them in the preliminary design proposal. In this step, consider how legacy systems will be replaced (1-for-1? Consolidate systems? Flash cut, or gradual migration?) and the impact this will have on subscribers. Why? Example More Info       T1.5.1 Finalize the preliminary design. Keep in mind that the design is only preliminary, and may change over the course of the project.       T1.5.2 Create a high-level design diagram.       T1.5.3 Review the timeline for the project based on the information gathered in the preliminary design proposal, feature/functional analysis, and legacy system end-user analysis. SUBSCRIBER PREP TRACK GOAL: Thorough understanding of existing VM system and its usage. S1.1 Perform a legacy system configuration analysis. This step actually tells you how to configure Cisco Unity, allowing you to develop configuration details such as schedules, call handlers, and routing rules.Why? Example More Info       S1.1.1 Document the legacy voice-messaging system configuration.       S1.1.2 Identify call flows, auto-attendant and other transfer features.       S1.1.3 Document the way that the switch integration is set up between the voice-messaging system and the legacy circuit-switched PBX,       S1.1.4 Document traffic patterns. You should be able to use this information along with the capacity-planning analysis to understand how Cisco Unity and your messaging systems should be configured to support the added capacity.            S1.1.4.1 Understand and document the type and amount of traffic on the voice-messaging system.            S1.1.4.1.1 Indicate the volume in size and quantity of messages.            S1.1.4.1.2 Indicate the number of subscribers using the system each day.            S1.1.4.1.3 Attempt to quantify messages left from outside callers per hour.            S1.1.4.1.4 Attempt to quantify messages left from subscribers to other subscribers per hour.            S1.1.4.1.5 Attempt to quantify messages retrieved by subscribers per hour.            S1.1.4.1.6 Indicate the number of subscriber logon sessions per hour.            S1.1.4.1.7 Indicate the number of calls per hour to transfer features, such as auto-attendant.       S1.1.5 Identify how users use voicemail networking to send messages between current systems, if applicable.       S1.1.6 Identify features that are turned on and how they are used in the system.       S1.1.7 Identify key business units that are critical to the operation of the company or that have unique needs for the migration process.            S1.1.7.1 Understand their specific usage or migration requirements.       S1.1.8 Document the way subscribers are managed.       S1.1.9 Document how subscribers are configured. S1.2 Document how the subscriber community currently uses voicemail. Why? Example More Info       S1.2.1 Create one or more questionnaires that ask important questions about how subscribers use their existing legacy voice-messaging system. For example:            S1.2.1.1 "What features do you find most important when you dial into voice mail?"            S1.2.1.2 "What features do you dislike the most?"       S1.2.2 Survey different types of end-user groups. Observe user activities including the key presses that they use and how they use the system.       S1.2.3 Create focus groups with representatives of different areas. These users can carry feedback from their areas to a group of users who can provide consolidated input into the entire usage-analysis effort.       S1.2.4 Seek out special-case users who have specific configurations that are unique to the mass population of users on the system, and understand their specific usage requirements.       S1.2.5 Seek out the voicemail power users and understand their needs.       S1.2.6 Understand how senior executives use voicemail.       S1.2.7 Identify the features that your end users take for granted.            S1.2.7.1 Compare those with Cisco Unity's features.            S1.2.7.2 Determine any functional usage gaps.       S1.2.8 Identify business units that are critical to the operation of the company or that have unique needs for the migration process.            S1.2.8.1 Understand their specific usage or migration requirements.       S1.2.9 Identify training criteria.            S1.2.9.1 Feature gaps that can affect the way subscribers operate.            S1.2.9.2 Features in the legacy voice-messaging system that may require some Cisco Unity training so that your subscribers understand them. ... View more

At this point, you're simply collecting the outcomes of all of your preparation and planning activities so that you're organized and ready to tackle the detail-oriented design mode without the distractions of having to go back and forth tracking down information you've already seen before. ... View more