June 1999

Implementing Call Center Software Packages

BY ROBERT TEKIELA, SAPIENT CORPORATION

Package implementation is essentially adapting pre-built software, which provides some generic functionality common to a broad market. Call center packages are commonly available, with vendors offering modules such as customer support, help desk and sales automation. This paper presents the approach we have used on successful package implementation projects.

Why Packages?
A significant percentage of new business applications is implemented using packages. The primary reason behind this drive is to reduce software development and maintenance costs and reduce the implementation timeframe. The advantages of packages over the custom development include:

• Quicker development time
• Lower costs
• Lower risk by using a proven solution
• Simplified design process using proven architecture
• Simplified design process using vendor tools and methodologies
• Multi-platform support
• Built-in interfaces to other major products (e.g., computer-telephony applications)
• Built-in international support
• Ongoing vendor support and documentation
• Vendor training available for developers and end users
• Availability of multiple consultants to install and maintain systems
• Annual upgrades and enhancements to the latest technology and tools
• Built-in year 2000 compliance.

There are also some disadvantages:

• Reduced functional flexibility
• Reliance on vendor to provide fixes and enhancements
• Lack of control over what is included in the next release
• Risk of business changes happening faster than packages can support them
• Forced upgrades to new releases based on the vendor schedule even if there are few benefits for the company
• New releases may include unwanted functionality, which is difficult to remove
• Risk of relying on vendor, who might go out of business or stop supporting the product
• Reduced differentiation from competition
• Possible inferiority of development tools to the best custom development tools
• Package may require a specific version of the operating system otherwise not used by the company
• Customization, especially extensive customization, reduces package advantages
• Integration of customization with new releases of the package is almost always highly problematic.

Misconceptions
A typical user will start the package implementation project with an assumption that the package will support most of the required business functionality as is and that only minimal customization will be required. This is rarely the case! Word processors and spreadsheets offer enough common functionality to work off-the-shelf for most businesses. Accounting systems are not in the same category, in spite of the fact that all businesses require similar accounting functionality. When dealing with the core business processes, each company has its own ways. Even companies in the same industry and of similar size tend to have significantly different processes. Hence, the assumption that the package customization will be minimal generally proves to be overly optimistic. Forrester analyzed 68 major package deployments recently. Only six of these were implemented with zero customization, while 16 had more than 20 percent of the product modified. Customization is an unavoidable fact of life. Users don't want to customize but packages are not complete enough. It is predicted, however, that levels of customization will be decreasing as the packages get better over the next few years.

Project Phases
A typical package implementation project involves several phases as shown on the diagram below:

Project Initiation
One of the most important initial project tasks, providing executive buy-in has been achieved and the business case is understood, is formation of the project team. This needs to include both technical people (internal IT staff and/or team provided by the system integrator) and business people. User involvement is always the key to the project success. The team should have good horizontal coverage (i.e., it should involve representatives from all departments associated with the project). It should also have good vertical coverage (i.e., include managers up to the project sponsor level as well as the end system users.) One common mistake is to assume that the team members will be able to perform their project duties in addition to their normal workloads. This usually has negative impact on the people involved as well as the project. During implementation, the process should be made the full-time jobs of the project team members; their regular duties should be off-loaded to other staff members and temporary staff. Project team members need to have assurance that they will be able to go back to their regular jobs after the project is over. It is also usually advantageous to establish a bonus or reward system linked to successful launch of the project on time and budget. This helps to focus all involved on the project objectives.

Business Design And Vendor Selection
Business Design
The focus of the business design is gathering and understanding the user requirements. The typical tasks involved include the following:

• Understanding the project vision and objectives
• Defining project scope (i.e., agreeing on what the project boundaries are, what the scope of the project is and what is outside of it). Implementing a plan to track and manage changes in the project is also recommended
• Understanding business processes and workflows (escalation process). These can be expressed as process flows
• Understanding data requirements or attributes describing products. These can be captured in the data model.
• Designing the look and feel through prototyping
• Understanding reporting requirements.

A significant percentage of software projects go overtime and over budget. One of the common reasons for this undesirable outcome is a lack of scope management. The design and development process cannot be rigid, as there are often valid reasons to change the scope. However, the change process must be well-defined and managed. Any additions may be offset by removal of some lower priority features or requirements to keep balance in the project.

Screen design and prototyping are frequently used in the design process. The prototype visualizes proposed solutions and enables the users to make better design decisions. Prototyping is usually done using rapid application development (RAD) tools such as Visual Basic. In case of package implementation, it is worth considering whether to prototype using Visual Basic or the package tools. The advantage of using the package tools is full compliance with the target look and feel. The prototyping may also be used as a training opportunity if the developers are unfamiliar with the package. One disadvantage is that the package tools are frequently not as flexible as Visual Basic and changing the prototype can take a great deal of effort. Tools like Visual Basic allow the developer to build impressive prototypes quickly. However, it is easy to overlook some of the package limitations and make overly ambitious promises to users. The decision regarding which tool to use for prototyping depends on the package itself. It should also take into account team members' experience in using the tools.

Reports form an integral part of the business applications, yet report design and development is commonly an afterthought. This leads to omissions and designs lacking completion. It is a truism that to be able to report, the required data need to be captured in the first place. Reports can be implemented late in the project lifecycle. However, understanding the reporting data requirements needs to be accomplished up front. Packages frequently come with a set of pre-built and ready-to-go reports, which may save some of the design and development time. On the downside, packages frequently integrate with a specific report writer engine. This may be a drawback, as report writers vary widely in terms of features and capabilities. A report writer offered with the package is not always a preferred solution, especially if the users are already familiar with and are using different reporting tools.

Vendor Selection
Vendor and package selection has a huge impact on the package implementation process and acceptance of the application.

A common mistake is to select a vendor using only the very high level criteria prior to business design. A typical customer tends to gain only a very superficial knowledge of the package functionality. The result is usually selection of the vendor with the largest market share, the lowest price or the best salesperson  not necessarily the best match for the company's business requirements.

An in-depth vendor selection process, based on the business requirements of the company, produces the most effective results and saves the project from later surprises. The business design phase should produce business scenarios to aid in codifying the business processes and drill down on the requirements. Vendors should be asked to demonstrate their wares based on these scenarios rather than using their standard software demos. Customization labs, in which the vendors customize packages to support the desired functionality, should be included in the process. These help to judge package flexibility and the ability to customize the off-the-shelf functionality. In addition, these will help to identify constraints of the package. Understanding the package constraints is equally or more important than understanding its functionality.

It is also crucial for the vendor to demonstrate that the system can handle the required load. Demonstrations rarely use databases, which mirror the volume of data required by the customer. In many instances, the customer does not discover this until it is too late. The network infrastructure is also something which is commonly overlooked. Packages frequently store screen images in databases. In a wide area network environment with tight bandwidth, the customer's network architecture might not support this requirement. Again, this is something that is usually discovered too late.

Gap Analysis
Gap analysis is essential to the package implementation. A selected package will rarely meet all business requirements as is. So it is very important to analyze the gap between built-in and required functionality. Understanding the gap will help to make decisions on how to address it. Several options are available. The gap can be addressed through customization, purchase and integration of modules from different vendors or development of fully custom modules. It is also possible to change some of the business processes from the ideal to those matching the processes built into the package, thus reduce development costs.

Technical Design And Development
Technical Design
Technical design of the package implementation is fairly straightforward. This is where a lot of benefits of the packages pay off. Typical tasks include:

• Closing On The System Architecture. Logical and physical system architecture of the package system is very much driven by the package chosen. However, packages frequently run on different hardware platforms and under different operating systems and support different database engines. Selection of these should take into account internal IT preferences, experience and industry trends.
  
  
• Capacity Planning And Sizing. This has to be done for all but the smallest projects. Package vendors frequently provide information which helps in capacity planning. Hardware sizing and selection in particular may be based on the vendor recommendations. Database sizing always requires going through the calculations based on the estimates of the data volumes provided by the users.
  
  
• Defining Security Model. Packages usually come with a built-in security model. This certainly simplifies design, which requires only focusing on defining user groups and permissions within the security model.

Package Customization
Package customization involves using the package configuration tools, which allow the developers to implement required functionality without programming. How flexible the configuration is depends on the package itself. The ideal package implementation project involves only configuration. Beyond the limits of package configuration tools, packages provide the ability to add functionality by writing code using the built-in customization language. Derivatives of Basic are the most common languages provided by packages. The unfortunate reality is that the tools offered by the packages are frequently inferior to the best custom tools. The package vendors must concentrate on key package functionality and usually cannot devote the same energy and resources to developing tools as the tool vendors can. Integration with third-party tools is usually limited, as well. These issues can make the development work harder.

Testing And Rollout
Testing
The purpose of testing is twofold:

• Validation that the system design meets the requirements of the business
• Verification that the system functions correctly to meet the above requirements in both expected, unexpected and error conditions.

Initial testing (testing of the individual system modules as well as integration testing) is performed by the system developers. User testing follows shortly afterwards and focuses on business functionality and stabilizing the application for the rollout. It is important to include users as early in the testing process as possible. Late user involvement does not allow much time for reaction to the issues and can lead to project delays or lower user acceptance of the system. The primary objectives of user testing are:

• Verification that the system functionality meets design specifications and user expectations
• Successfully running all user test scenarios, thus testing the entire breadth of the application
• Discovery of as many issues as possible
• Managing and prioritizing the issues so that those of highest priority are addressed first
• Ensuring that the application is architecturally and technically sound and works as specified

A variety of tests can be used to ensure thorough coverage of all the functional modules during the testing. These tests can include:

• Scenario Testing. Scenario testing involves executing the test cases that pertain to workflows. These test cases should exercise the breadth of functionality as the testers simulate real-world situations.
  
  
• Mouseless Navigation. The mouseless navigation test is simply a variation on the scenario test, but users are expected to perform the tasks without the aid of a mouse, using only the keyboard shortcuts. The objective is to test the functionality of keyboard shortcuts, which are especially important in the call center environment.
  
  
• Bumper Car Testing. The bumper car test may or may not involve specific test cases. It is a test session in which users execute the same tests and commands at exactly the same time. The objective is to test the system's ability to deal with possible simultaneous commands.
  
  
• Failure And Boundary Testing. Failure and boundary testing involves simulation of unexpected and error conditions such as hardware failures. The system should report expected errors and recover from the failures gracefully.
  
• Stress (Load) Testing. Stress testing involves simulation of a large number of simultaneous users. Testing tools are frequently used to conduct the test. The objectives are to make sure that the system does not break under heavy load and that the performance is adequate under such circumstances.
  
• Scavenger Hunt Testing. The scavenger hunt test does not involve any specific test cases. It is used as a diversion from the rather tedious test case testing, and to allow the users to use the system outside the bounds of test cases or normal usage.
  
  
• Regression Testing. Regression testing is used to verify that new software changes do not cause new problems with previously developed functions. Regression testing involves, at a minimum, re-executing the test cases in the regression test matrix. Additional test cases may be warranted if the software change is unique or incorporates new functionality.

Change Management
Deploying new systems involves significant levels of changes. There are new business processes, new tools to learn and potential organizational changes. Managing the changes and assuring the acceptance of all the parties involved must be an integral part of the project. The larger the impact of the solution on the organization and its people, the more important change management becomes.

Change management should be planned early and executed throughout the duration of the project. All project stakeholders need to taken into consideration. These include:

• System users
• Line management
• IT
• Senior management
• Public relations
• Marketing department
• Finance department.

For each of the stakeholder groups, the following issues need to be considered:

• The message to be communicated, including benefits of the project to the company and to the recipient group
• A communications vehicle, such as presentations, software demonstrations, question and answer sessions, internal newsletters or an Intranet
• The individual or group designated to oversee the communications.

Rollout
System rollout is the pinnacle of the project. If this step is not planned and executed properly, it can cause a lot of stress and may lead to system downtime. Preparation for the rollout should include the following:

• Assuring high application quality through testing
• Development of the documentation and online help
• User training
• Processes and resources for the system support
• Testing of the data migration if the system to be deployed is a replacement for the existing system
• Multiple dress rehearsals of the rollout process.

Summary
Packages can make sense from the benefit to cost ratio point of view. Provided the gap between the package and the business requirements is manageable and providing package limitations does not raise any red flags, package implementation is a better approach than a full custom development.

Are packages easier to implement than the fully fledged custom solutions? Certainly. However, this does not mean all package implementations are trivial. Package implementation reduces development risks and simplifies some of the design activities in areas where design decisions have been made by the vendor. However, packages do not eliminate the need to undertake a properly structured design and development process. Proper methodology and best practices are a must for the success of any project.

Robert Tekiela is a director of Sapient Corporation. He can be reached at [email protected].