Call Center Setup Project Planning

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

Call Center Software Setup Example WBS

Call Center Software Requirements Definition

Call Center Setup Project Risk Matrix

Website Development Contract Considerations

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:

  • Design – site graphics, layout, color schemes, logos, images, illustrations, maps, etc. If these are to be developed by an external design studio, then issues of copyright and use will specifically need to be addressed as part of a development contract. If the art works are to be provided by the customer, then the contract should specifically state this. The contract should specify the designs to be provided in as much detail as is possible. For example, “the development house will design 3 proof logos based on existing marketing materials and corporate color schemes for review by the client.”

  • Content – content includes all text, media, downloads. Content development is perhaps the most time consuming task in developing a web site. Content is extremely important! Sites that plan on deriving revenue from traffic will need content to attract and retain site visitors.

  • Supporting applications – most websites will utilize applications to support content delivery and information collection. These may include bulletin board systems, forms, database systems, shopping carts, product catalog management systems, etc. Many of these applications are available as open source. The website contract should specify the source of the applications, whether open source or custom development and document any license restrictions or rights associated with these applications. In instances of custom development, license and right to use should be specified in the contract.

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!

Project Risk Register

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.

Risk ID

 

Description

 

Risk Impact

 

Impact Description

 

Risk Probability

 

Risk Severity

 

Risk Contingency

 

Risk Owner

 

Status

 

Date

 

Content will not be available when required 

4

 

Missed deadline will result in funding cut. 

3

 

12

 

Hire additional copy editors 

Marketing 

Currently recruiting for additional staff 

10/10/08

 

Project resources may be reallocated for other (higher) priority
project 

3

 

Resources are currently 100% committed to this project. Losing a
resource would severely delay project. 

2

 

6

 

Work with Portfolio Manager to ensure resource availability 

PM 

Portfolio Manager will not reallocate staff. 

10/11/08

 

End users may be resistant to new site workflow 

4

 

Customer feedback was instrumental in site design, but not all
customers will like the site changes. May result in bad publicity or
customer satisfaction issues. 

3

 

12

 

Implement online help facility. Provide additional customer support
staff for transition. 

Support Manager 

Additional staff will be brought online 1 month prior to release.
Online help facility added as change request. 

9/9/08

 

Data loss 

5

 

Data migration may result in loss of customer data. Customer data is
key for day to day business operations. 

2

 

10

 

Revisit backup procedures. Execute manual backup prior to
migration. 

Developers 

   

Call Center Software Project Requirements Definition


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

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.


Example Billing Project data migration project assumptions

  • Business rules relating to billing processes (e.g. invoice cycles, pro-rating logic, re-connection and other fee structures) remain the same. A summary of used business rules will be distributed by the Finance Department.
  • Data for active billing subscribers will be migrated. As at (date), there are 1000 active subscribers.
  • Data for recently disconnected subscribers will be migrated. As at (date), there remain 250 inactive subscribers. Given current churn rates, there is a high probability that 75% of these currently inactive subscribers will request re-connection.
  • Data for customers with an account balance (debt or credit) will be migrated.
  • Data for customers with un-returned equipment will be migrated
  • Data for customers currently in the collections queue will be migrated.
  • Data to be migrated includes (refer to data dictionary for format and detailed description of data to be migrated):
    • Customer name
    • Customer contact details
    • Customer billing package details
    • Customer equipment details
    • Customer invoices generated since (date)
    • Current, 30, 60, 90, > 90 day balances
    • Notes on customer account
    • Service call history details
    • Method of Payment details (Credit Card, Direct Deposit details)
  • Data to be migrated must be exported and cleaned before formatted for import into new platform. Cleaning can be completed by the Customer Service team before the end of (date).
  • Data transformation can be completed by the Billing Administration department.
  • The transformation tools identified and tested by the Billing Administration department will be adequate for the scope and duration of the project.
  • Existing and new platform documentation is accurate.
  • Internal staffing resources will be made available to complete required system testing.

Data Center Relocation Work Breakdown Structure

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

Office Relocation Example Risk Matrix

This example risk matrix uses the Office Relocation project assumptions and Office Relocation work breakdown structure documents as input. This is not an
exhaustive list of all Office Relocation project risks and may not be applicable to your particular project. Rather, this matrix is intended to provide a framework for
identifying, prioritizing and managing risk.

Risk Description

Impact

Probability

Severity

Mitigation Strategy

Priority Scale 1-5 (5 = most severe, greater probability)

(A)

(B)

(A*B)


Technology:  Data and/or Voice circuits will not be available by (date).  Company will not be able to communicate. (Note A)

5

3

15

1. Contact wireless solution vendor as redundant provider.
2. Seek alternate fixed data / voice provider
3. Allow employees to work from home
4. Extend existing lease by 1 mo nth to provide additional circuit implementation time.

Operations:  Inadequate insurance.  Company may be underinsured.

4

1

4

1. Check coverage
2. Review policy

Construction:  Construction build not complete by (date) (Note B).  Company will not be able to relocate according to schedule.

5

3

15

1. Delay lease termination notice

Construction:  Construction deficiencies.  Office environment may be hazardous.

3

2

6

1. Construction warranty
2. Phased payments
3. Use known good contractor
4. Request inspection

Move:  Equipment breakage.  Core networking gear and/or peripherals would need to be replaced.

5

2

10

1. Adequate packing
2. Hire professional packing/moving company
3. Employees responsible for laptops
4. Ensure spare equipment available

Note A: Historically, vendor has had difficulty deploying high speed circuits to this part of town.
Note B: Project is currently 1 month ahead of schedule. However, project is complex, so some delays are expected.

For additional reference, review the Project Risk Register and Risk Impact and Probability Assessment documents.

Trade show risk planning, identification and management

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.

Risk ID

Category

Description

Conditions

Impact Description

Possible mitigation

1

Overall

Poor event turnout

Unforeseen conditions may also contribute (e.g. weather,
etc.)

Poor ROI; minimal sales leads; poor sales; over-purchase of give-aways,
materials

Vetting of show venue; show attendee profile; purchase re-useable
give-aways; marketing campaign to target specific key
customers

2

Overall

Poor ROI

 

 

Define measurement of show success; clearly define show goals and
objectives

3

Scope

Lack of site traffic to booth

Booth location

 

Staff to physically direct potential customers to
booth

4

Budget

Trade show costs limit booth location and size options

Limited budget

Reduced traffic to booth; reduced sales leads; poor ROI

Consider partnering with a supporting product vendor; show business
case analysis

5

Materials

Manufacturer delay in shipping show materials to home
office

 

Materials not available for show; negative credibility

Research and identify alternative vendors; order materials
early

6

Materials

Booth/materials damaged in shipping to show venue

 

 

Professional packing and unpacking; contingency plan for display;
verify insurance coverage

7

Staffing

Personnel not available; show marketing and/or execution plans are too
labor intensive.

 

Negative credibility; technical trade show staff are unavailable to
support normal business operations

Schedule at least 1 month in advance; identify and train alternative
staff; financial incentives

8

Technical

Technical display failure

 

Poor sales; negative credibility

Full system testing; budget for and bring redundant
equipment

9

Technical

Demo errors

 

Negative credibility

Full system testing using multiple test groups

10

Technical

Useless prospect data gathered from show

 

Poor ROI

Standardized forms; staff bonus based on data
usability

11

Technical

Positive risk of overselling units

 

Unable to deliver on time

Review historical trade show sales records;

Trade show risk planning, identification and management (.docx format)

Trade Show Project Planning

Trade Show Planning, Execution, Project Closure

Trade shows are a cost effective way to meet many potential customers within a short period of time. These potential customers are interested in the show venue, and by extension, in the products and services which your company offers. The Trade Show Bureau claims that the average total cost of closing a sale in the field is $1,080, while the cost of closing a sale to a qualified trade show prospect is $419 (data taken from http://www.sba.gov).

For the small business, trade shows level the sales and marketing playing field. Floor space is relatively inexpensive, and as such, even small companies can afford a savvy display booth. The success of the trade show, however, does not depend solely on booth design or even the product or service being sold. Successful trade shows depend on how well the show plan is developed and executed.

A trade show is one component of a comprehensive marketing plan, which begins months prior to a show and ends only after the project team have fully explored all of the successes and lessons learned from the trade show project. The trade show project plan will include activities such as researching potential venues, direct marketing to both existing and potential customers, booth design, staff training, well designed product demonstrations, delivering effective seminars, and coordinating all of the show activities to ensure that time spent at the show brings in quality leads that result in sales.

Project Documents

Trade Show Project Plan (.mpp format)

WBS for Trade Show Project Plan

Trade show risk planning, identification and management (.doc format)

Point of Sale (POS) Project Documents

Point of Sale Implementation Project Planning

These documents provide information and assistance in planning and deploying a Point of Sale system.

Project Documents

Point of Sale WBS

Point of Sale Needs Assessment Checklist