| Call Center Setup | |
|
Call center models range from the simple internal IT help desk, to a fully staffed customer care department, to the more complex multi-channel systems with IVR (Intelligent Voice Recognition) and ACD (Automatic Call distribution) call handling. All call centers will require software to track and manage customer issues, a voice and data network to support the software, and adequate staff to handle call volume. The following project documents cover varying aspects of call center setup and provide a project management framework for successful deployment of a call center. Project Documents
|
 |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Aside from the standard clauses (liability, force majeure, cancellation, etc.), a website development contract should specifically address the following: Scope Many website development contracts will be signed before the project scope has been fully defined. In cases such as this, the contract should require the development firm to fully document project deliverables, budget and schedule before formally beginning work on web site. Contractually, this could be considered the first project milestone. If this milestone is not reached (and the contract would need to specify criteria for acceptance of this and all project milestones), then the contract would be void. If a scope of work has been developed, then, as part of the project plan, the project deliverables need to be included in the website development contract. The scope of work includes all work to be done as part of the project. Items not specifically included in the scope of work are considered out of scope and would be addressed as part of a change management process. A website development project scope of work might include:
Change Management Change management procedures outline how changes from the initial scope are handled by both the service provider and the customer. Most change management policies call for documenting the nature of the change and allowing time for proper evaluation of the costs of change and subsequent impacts on schedule, quality and risk. In the case of a website development contract, particular attention should be paid to managing design changes, as these can be both time consuming and expensive. Project Responsibilities A responsibilities clause provides clarity to the various roles and responsibilities of team members and management involved in the website development project. If the client is responsible for generating content, for example, then this should be documented under the responsibilities clause. The contract should cover at the very minimum: design, media and content sources, search engine optimization, testing, maintenance, hosting. Payment Terms Most contracts that cover a technology deliverable will use milestones for determining the payment schedule. It is essential that these milestones be clearly defined, with documented milestone acceptance criteria. An example milestone for a website development contract might be delivery of design proofs, completion of content, or successful testing of a data management application. User Acceptance Testing Testing is essential, as a company’s website is often the first interaction that a potential customer, partner or employee has with the organization. Like all company documents, sales and marketing materials, the website must be free from error. Completion of testing should signify a project milestone. Warranty A warranty period will ensure that underlying web applications, components, scripts and other site developments are free from error for a period following project sign off by the client. The contract should detail the specifics of the warranty (e.g. length of warranty, what elements are covered by the warranty, time frame for remedy and what costs, if any, will be incurred by the client in the event that warranty repairs are required). Ongoing Responsibilities If the development house is responsible for site maintenance, then a regular maintenance schedule should be included in the contract, as well as a listing of the items which are covered by the maintenance agreement (e.g. data archiving, product catalog updates, content updates, design refreshes). Copyright In addition to underlying web applications, scripts and source code, the contract will need to cover copyright of site design, logos, graphics, illustrations, images or other media produced for the website. Project Timelines The development contract should specify in as much detail as possible the proposed delivery schedule. If a formal scope of work has not yet been established, then defining a project timeline will not be possible. Rather, the development contract should be used to specify expectations and state that as part of the formal project scope, a project schedule will be created for the client to review. The most important part of the website development contract and procurement process is having a legal expert who is familiar you’re your business and the project review the contract!
The Project Risk Register is a summary risk document. The risk register should contain a listing of all sources of risk, risk impact, risk probability, contingency plans, risk owner and the status of the risk. The risk identification, impact assessment and risk ranking, contingency planning and project execution tasks are all inputs to this document. The risk register should be actively maintained throughout the project. The below example project risk register is based on a generic website development project.
1. General Call Center Software Project Requirements 1.1. Scalable to support multiple call center locations 1.2. Track both inbound and outbound customer communications 1.2.1. Provide performance metrics and reporting on call queue 1.2.2. Provide performance metrics on staff call handling 1.2.3. Associate all communications with appropriate customer account(s) 1.2.3.1. Maintain log and provide management and center staff access to historic call data 1.3. Call Center software must integrate with CRM (Customer Relationship Management) application 1.3.1. Support screen pop based on dialing number for existing customers 1.4. Call Center software must integrate with Billing System 1.5. Call Center software must integrate with Help Desk application to 1.5.1. Track and manage open issues 1.5.2. Escalate and/or dispatch issues to appropriate department (e.g. level II support, engineering, management) 1.5.3. Support the work order management process 1.5.4. Provide incident statistics and management reporting 1.6. Call Center software must provide Knowledge Database 1.6.1. Automatically update knowledge database with issue and resolution information 1.6.2. Provide administrator facilities for managing knowledge database 1.6.3. Knowledge database should be searchable and available to customers via the WWW 1.7. Call Center software Quality management 1.7.1. Support the ability monitor calls for call quality 1.7.2. Support the ability to record calls 1.8. Comply with e-911 standards and provide support for lawful intercept
2. Call Center Software Email Routing Requirements 2.1. Support intelligent routing based on customizable rules definition 2.2. Ability to associate email with customer account
3. Call Center Software Voice Routing Requirements 3.1. Use ACD (Automated Call Distribution) and IVR (Intelligent Voice Routing) to direct calls 3.2. Use Auto Attendant features to greet customer based on time of call 3.2.1. During business hours 3.2.2. After business hours 3.2.3. Holiday 3.2.4. Outage notification 3.2.5. Special announcements 3.3. Routing, Auto Attendant, new extension setup should be manageable by in house technical staff 3.4. Support WWW to phone call center applications
Example Project Assumptions for a Data Migration Project.
Data Migration projects, especially those across platforms or into new database structures, are inherently complex. Identifying project assumptions early in the project planning process is necessary to facilitate the scope of work definition. Assumptions should be documented clearly, without use of department specific acronyms or terminology which might not be understood by all members of the project team. Project assumptions, especially those initially identified by the Project Manager without input from the rest of the project team, should be distributed to the whole team as early in the project planning process as is reasonable.
… The purpose of this document is to provide project managers and team members with an overview of the requirements for a data center relocation. This data relocation plan document can also be used as a checklist in support of an existing data center relocation project. 1.1. Data Center Relocation Project Management 1.1.1. Scheduling 1.1.2. Procurement Management 1.2. New Data Center Requirements Definition 1.2.1. Business 1.2.1.1. Service Level Agreement 1.2.1.2. Insurance 1.2.2. Technical 1.2.2.1. Current Data Center 1.2.2.1.1. Inventory 1.2.2.1.2. Communications Migration Requirements 1.2.2.1.3. Contract Review 1.2.2.2. New Data Center 1.2.2.2.1. Rack Diagrams 1.2.2.2.2. Communications Interconnects 1.2.2.2.3. Cabling 1.2.2.2.4. Power 1.2.2.2.5. Environmental Controls 1.2.2.2.6. Security Access 1.3. Acquisition 1.3.1. New Data Center 1.3.1.1. Site Visit 1.3.1.2. Contract 1.3.2. Hardware 1.3.2.1. Issue RFP 1.3.2.2. Selection Criteria 1.3.2.3. Purchase 1.3.3. Communications 1.3.3.1. Data Interconnect 1.3.3.2. Voice Interconnect 1.4. Installation Prerequisites 1.4.1. Resource Allocation 1.4.2. Notifications 1.4.2.1. Internal 1.4.2.2. Customer 1.4.3. Site Preparation 1.4.3.1. Circuit Cut Over Plan 1.4.3.2. Rack Space Allocation 1.4.3.3. Power 1.4.3.4. Cabling 1.4.3.5. Network 1.4.3.5.1. IP Allocation 1.4.4. Testing 1.4.5. Configuration Backups 1.4.6. Detailed Installation Documentation 1.5. Migration 1.5.1. Hardware 1.5.1.1. Installation 1.5.1.2. Testing 1.5.2. Routing and Switching 1.5.2.1. Cut Over 1.5.2.2. Testing 1.5.2.3. Cancel Circuit to Old Data Center 1.6. Operations Switch Over 1.6.1. SLA monitoring 1.6.2. Documentation 1.6.3. Disaster Recovery Testing Microsoft Office Format of Data Center Relocation Plan Work Breakdown Structure
This example risk matrix uses the Office Relocation project assumptions and Office Relocation work breakdown structure documents as input. This is not an
Note A: Historically, vendor has had difficulty deploying high speed circuits to this part of town. For additional reference, review the Project Risk Register and Risk Impact and Probability Assessment documents. Trade shows are a fantastic opportunity for companies to showcase new products and services. If a show is well planned and managed, companies can expect to meet numerous potential customers and generate strong sales leads. A poorly planned and managed show, however, can tarnish a company’s reputation and provide a poor return on investment. As part of the trade show project planning process, the project manager must lead the show team in identifying all risks associated with the trade show. The goal of this process is to document all essential information relating to project risk. The below information is intended to assist in this trade show planning process and is not intended to be a complete risk assessment. Each company will have unique business objectives supporting with the trade show project. The risk identification process must support these business objectives For additional information relating to risk, refer to the Project Diva article on project risk identification and management.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Copyright © 2016 The Project Diva - All Rights Reserved Powered by WordPress & Atahualpa |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
