So, Youre Thinking About a New Software Package? Selection, Implementation and Pitfalls

The days of building your own systems are over. According to a Standish Group report, in 1997 only 16 percent of the IT development projects in the United States were successful; with 31 percent canceled and 53 percent challenged because of late delivery, over-budget problems, or wrong/limited functionality issues. In today's fast-paced, competitive market, service providers do not have the luxury of time and capital to invest in internal IT development. Incumbent providers and new competitive players alike continue to look to vendors to offer them "package" solutions. Because no single vendor has a complete back office solution that can provide everything, the service provider must purchase and integrate packages from multiple vendors. Integration of these packages becomes the major challenge.

DMR Consulting Group, a systems integration and consulting firm, recently surveyed both incumbents and new entrants that have developed a new OSS infrastructure through package implementations.

Business Areas and Business Drivers

In general, service providers tend to purchase a package for just about any business function. Areas of full consensus are ordering, billing, provisioning, network management, trouble management, financials and human resources. The only area of disagreement is customer care. Some service providers view customer care as a strategic advantage that requires a build, not a buy strategy, to allow for differentiation. Meanwhile, others embrace package solutions and differentiate through unique business processes or through customization of the package.

Several business drivers fuel the push for packages. Time-to-market is the main reason that service providers implement packages. Typically, a package solution can be configured, integrated, and implemented within nine to 12 months, compared with a minimum of 24 months for a build approach. In addition, most service providers recognize the difficulty in recruiting and retaining technical talent, and neither have, nor want to develop, the IT capability required to develop software solutions. They have a strong "Why reinvent the wheel?" attitude and perceive a lower risk in implementing a package than in developing their own solutions. Clearly, sharing the investment with other package customers reduces cost for the core applications and for future upgrades. Package solutions are less expensive than development only if the service provider successfully keeps customization of the package to a minimum.

Key Challenges in Implementing Packages

The two biggest challenges in selecting a package solution are:
* Trade-off decisions between functionality requirements and technology and architecture requirements - the more established vendors have more functionality to offer but do not support desired architectures (such as object oriented and NT). The newer packages have strong architectures, but limited functionality;
* Finding the right vendor - many vendors know their package but not the business application, which makes it difficult to secure the right vendor resources to customize and configure the system appropriately.

Once a package or vendor has been selected, the biggest challenge becomes integration. As one service provider summarizes, "All packages work great in a vacuum; the trick is getting them to work together." The package needs to be integrated with the existing infrastructure. The environment is usually heterogeneous with legacy applications and newer client/server packages and in various stages of implementation. Some newer applications may not have a standard architecture or a standard hardware and software platform. For example, a provisioning package may run on an HP/UNIX server and support Oracle, but the billing applications may run on an AS/400 system, or on a Sun/UNIX server while supporting Sybase.

Another problem area is data integrity. Each package has its own data model. As multiple packages are implemented, data redundancy becomes an issue. Integrating the data models within an enterprise-wide data architecture is important for minimizing data integrity problems.

Other challenges include:
* Customization of the package to support internal requirements;
* Scaling to volume;
* Conversion, specifically the clean up of bad data before the new system is implemented; and
* Maintenance of old systems while planning and implementing the conversion, including resource allocation and skill set issues.

Critical Success Factors

The two most important critical success factors are systems integration and program management. Integration of the packages with each other and with the existing infrastructure is non-trivial. Most vendors do not have predefined interfaces with other packages, and even APIs that come with a system are not enough to ensure tight integration with other packages and legacy applications. Integration is important to ensure data integrity and to maximize flow through.

Program management is also important for setting firm budgets and schedules, and for controlling changes from the original plan. Program management is required to integrate the implementation schedules of multiple packages and to minimize user confusion in an environment of massive OSS change. Process changes must be managed and implemented together with the package rollout.

Other critical success factors include:
* Determining the vendor's commitment - picking a vendor that can be a partner and one that will respond to your priorities and needs;
* Picking only a few vendors with which to work;
* Securing user involvement throughout the entire process;
* Securing dedicated, high-quality vendor resources for implementation;
* Changing your business process to fit the system rather than customizing the system to meet process requirements; and
* Getting the vendors to work together on the interfaces.
Surprises Respondents Found in Implementing Packages

Almost all package customers are surprised by the amount of customization required. Separating actual functionality from the "glossy-ware" is clearly a challenge in the selection phase. Service providers are often surprised at how vendors oversell functionality. Service providers are often faced with decisions to either "force fit" the package or perform massive customization to meet requirements.

Product and vendor maturity also causes problems. Product customization is often required for what service providers view as basic functions. In addition, vendors typically do not have conversion tools, off-the-shelf interfaces, or other aspects of a mature off the shelf software package. Some service providers are also disappointed with the package data models, which are often limited by the inability to handle exceptions and other than plain-vanilla products.

Finally, schedule and budget overruns are a big surprise. As one service provider states, "Everything takes more time and money than you think." Many service providers advise novice package customers to "take whatever you have budgeted and double it."

What would you do differently:
* Spend more time on the contract and make sure it includes some leverage such as penalties and out clauses, because once you have signed, you are locked in;
* Use the vendor's data model to determine the package's capability to handle requirements and to highlight gaps before you buy it;
* Spend more time planning;
* Set measurable goals and track whether they were achieved at the end of each phase; and
* If major customization is required, get credit for the intellectual property gained by the vendor.
Implementation Realities

To implement an entire OSS suite, service providers should plan on an implementation timeframe of two to three years. The recommended project approach is to fix the implementation date and vary the scope and dollars to meet it.

Individual package implementations typically take nine to 12 months. Budget overruns vary widely from 15 percent to 25 percent to more than 200 percent if unplanned customization is required. Although license-to-implementation ratios vary by package, they run between 1:1 to 1:2 for billing systems, and 1:3 to 1:4 for network and provisioning packages. Maintenance fees are relatively standard, between 15 percent to 20 percent of license fees.

Project timeframes are estimated as follows:
Project Stage
Percent of Project Schedule
Vendor/package selection
10-15%
Implementation planning
15-20%
Customization/implementation
65-75%

Service providers should note one final challenge. How do you differentiate your service if you are implementing the same packages as those of your competitors? Approaches to differentiation include unique business processes, customization of packages, and very tight integration to support flow through and to minimize manual processes.

DMR, together with Billing World, has conducted functional and technological surveys of package solution vendors in telecommunications billing service activation and provisioning, and energy billing. Deborah Strong, Vice President, Strategic Services, DMR Consulting Group, can be reached at 203-618-0705 or dstrong@dmr.com. Shailendra Jain, Chief Operating Officer, DMR Consulting Group, can be reached at 732-744-8080 or sjain@dmr.com.