Software Procurement in the Telecommunications Industry<

Author(s):

Edward J. Kovac, C.P.M.
Edward J. Kovac, C.P.M., Procurement Director — Network Services, AT&T, Middletown, NJ 07733, 732/420-2917, ekovac@att.com

86th Annual International Conference Proceedings - 2001 

Introduction. The telecommunications industry uses sophisticated software to operate their internal computer systems and to provide voice, data, and video services to their customers. Initially, telecom service providers developed much of this software themselves. But, as the industry has evolved, they have come to rely more heavily on procurement from outside suppliers. Both commercial and custom-developed software are used. This paper describes the software procurement process as it has evolved in the telecommunications industry. It also endeavors to explain why software procurement is complex, who is involved, what the procurement processes are, and how the processes can be managed more effectively.

Software in the Telecom Industry. Software is used extensively by the telecom industry to provide both internal and external services. Internal services software supports desktop computers and corporate systems and is similar to IT (Information Technology) software used in other industries to increase productivity and decrease operating costs.

External services software, on the other hand, supports revenue generation for the company and can be a determinant factor in a telecom company's competitiveness. Software is used extensively in telecom network elements (switching, transport, signaling), operations systems (service provisioning, billing, fault monitoring), and service nodes (operator services, message services, calling card processing).

Initially, many telecom service providers developed the software for both internal and external services themselves. (i.e. make vs. buy). But, as the telecom industry has evolved, the service providers have come to rely more heavily on software procured from outside suppliers.

The procured software can be categorized into three distinct types:

• Commercial (off-the-shelf product)
• Custom (customer-specific product)
• Hybrid (part commercial and part custom)

Commercial software is standard, off-the-shelf software that anyone can buy (i.e. license). Typically, it is easier to procure and less expensive but it doesn't always match the customer's needs. Custom software, on the other hand, is a unique product built by a supplier to the customer's specifications (usually involving intellectual property). It is typically more difficult to procure and more expensive but usually comes closer to matching the customer's needs. To gain the advantages of each approach, hybrid software systems have evolved which include some commercial modules, like operating systems and databases, combined with other modules that are custom-developed, like user-interfaces and applications.

Why Software Procurement is Difficult. Software has several attributes which complicate its procurement. Basically, software is

• Abstract
• Complex
• Intellectual Property Intensive

A software product is multi-faceted. It includes source code and object code which can only be deciphered by specialists. In addition, it requires documentation and training in order to use it. Furthermore, on-going maintenance and support are required to keep it functioning properly. A software product may also be frequently changed via upgrades and enhancements. All these software product deliverables are supposed to be developed in response to requirements provided by the customer, but the match up is seldom 100%. Hence, the procurement process for software tends to be complicated from start (bid solicitation) to finish (contracts, remedies). It usually involves more than a one-time buy and, instead, involves numerous buys of various deliverables over extended timeframes.

Who is involved in software procurement. The parties involved in software procurement have some attributes that set them apart from the norm:

• Suppliers can range from small start-ups to mega-companies. This is because software development does not require large amounts of capital to get into the business. Also, since the product depends on the creativity of the supplier, competition on a particular software purchase can range from multi-source to sole-source. In addition, MWBE suppliers can be difficult to find in many cases.
  
  
• Internal Business Partners are the ultimate customers for the software. In the telecom industry these customer organizations include Corporate IT, Network Technology, Operations Systems, and Services Development. The people in these organizations tend to be engineers and information technologists who generally are technical, detail-focused, and jargon-oriented.
  
  
• Legal interfaces tend to go beyond the usual contract law attorneys. Intellectual Property (IP) experts and patent attorneys are also frequently involved in the software procurement process.
  
  
• Supplier Management (purchasing) personnel must have a high-level of computer / software knowledge in order to communicate in this jargon-intensive area. They must be aware of the current state of intellectual property law. Also, because software procurements can occur over long time frames, they need strong project management skills and must be expert negotiators.

Procurement Process for Commercial Software. Typically, the process for procuring commercial software for enterprise applications is relatively straightforward. First, an RFP is used to solicit and evaluate competitive bids in response to the customer's requirements (statement of need). Then, a contract is negotiated with the successful bidder which includes right-to use (RTU) licenses, warranty terms, support and maintenance terms, and conditions regarding upgrades and enhancements.

The RFP process can involve software suppliers who sell direct or who are re-sellers. Some suppliers sell either way. Re-sellers offer additional services including the administration of orders and licenses as well as the management of customer introductions of new software releases. In addition, many re-sellers are MWBE. The evaluation of RFP responses should not be based solely on price. Other factors such as the level of on-going support and acceptance of contract T's and C's should be included in the evaluation.

The resulting contract should specify RTU license terms including specification of whether individual, site or enterprise-wide licenses are involved. In addition, the duration of the licenses, either "term" or "perpetual", should be specified. The contract should also spell out warranty terms. Post-warranty maintenance terms which usually do not include bug-fixes but do include upgrades should also be specified. The price for post-warranty maintenance should always be included in the original contract negotiations and never be put off until the warranty expires and the customer has lost leverage.

Procurement Process for Custom Software. Custom software procurement is usually more complicated. First, since intellectual property is involved, Non-Disclosure Agreements (NDAs) should be established before meeting with suppliers. During the RFP process, detailed Statements of Work (SOWs) are used to ensure that the customer clearly conveys his expectations to the supplier. In addition, since new computer code will be delivered to the customer, extensive acceptance tests are required. A separate trial agreement is often used to specify the scope and direction of software acceptance tests. Finally, warranty terms for the initial release and for future releases must be clearly stated in the contract.

Post-warranty maintenance costs and levels of support should always be included in the original contract. Maintenance support for custom software differs in several ways from maintenance for commercial software. First, bug-fixes are often included but upgrades/enhancements usually are not. Performance warranties (i.e. up-time) are often required for custom software but usually not for commercial. Finally, maintenance costs for custom are usually X% of cumulative development costs whereas maintenance costs for commercial are often included in the license fees.

Procurement Process for Hybrid Software. Hybrid software procurement combines the processes for commercial and custom-developed software. For example, a hybrid software system might be comprised of the following modules and procurement modes:

• User Interface   ......................  Commercial
• Operating System   ...............  Commercial
• Database   .............................  Commercial
• Applications   .........................  Custom
• Integration   .............................  Custom

Note that in addition to the various functional modules (e.g. operating system, database, etc.) a separate set of integration software is required to enable the various commercial and custom modules to interwork. This integration software also allows the hybrid system to interface with other software systems used by the company.

Hybrid software in the telecommunications industry has evolved as a result of a series of alternative approaches:

• Totally Custom: Initially many telecom companies designed and built their own custom-developed software from scratch (i.e. make). To control costs and "stick-to-their-knitting" they next tried to procure (buy) their custom-designed software from suppliers who specialized in software development.
  
  
• Totally Commercial: To avoid the high costs of custom software, many telecom companies tried the alternative of using only standard commercial software from suppliers. Since the software did not exactly meet their needs, they tried to change their processes or service requirements to match the software systems. To procure software that more closely matched their needs they tried to mix-and-match commercial modules from different suppliers. But this multi-vendor approach exacerbated the software integration issue.
  
  
• Hybrid: To get software that both controlled costs and met their needs many telecom companies started using hybrid software comprised of both commercial and custom modules. Initially, they tried to mix-and-match the best commercial modules from multiple suppliers with a number of custom modules. Since integration across software modules has remained a major issue, some telecom companies have tried a single-vendor-hybrid approach for software. Here, all the commercial modules (e.g. operating system, database, etc.) are procured from a single supplier so they already interwork with each other. The custom modules then have a minimum amount of integration requirements to fulfill.

How to manage software procurement more effectively. Some tools that have proven to be effective in managing software procurement include the following:

• Procurement Checklists & Action Plans are internal project management tools used by the software purchaser. The procurement checklist assures that roles and responsibilities within the purchasing company are clearly defined for a particular project. The action plan, on the other hand, spells out the time intervals allocated for the major procurement activities such as RFP's, contract negotiation, etc.
  
  
• Communication Plans are agreements between the purchasing company and the supplier identifying the organizational contacts in each company (contracting, legal, etc.) and specifying between whom the official intercompany documents should be transmitted.
  
  
• Procurement Metrics for software involve more than the typical "savings" and "MWBE" metrics. In some cases, the "new revenues" and "risk avoidance" involved in a software procurement can be much more significant than the savings and MWBE. In addition, time-to-market can be critical in revenue-affecting software procurement. Hence, "cycle time" for the overall software procurement process is something worth measuring. Finally, "competitive pricing" can be a more meaningful metric than savings for software since it is a measure of how well a particular software procurement compares to industry averages.
  
  
• Make vs. Buy Analyses are coming back into prominence. With the "hybrid" approach to software procurement, telecom companies are seriously evaluating the make vs. buy decision for the minimal number of custom-developed modules that must interwork with the commercial modules in the software system.
  
  
• E-Procurement is coming to software procurement. Initially, it could be effective when commercial products are involved. It will take more time, however, to adapt e-procurement to the complexities of custom and hybrid software.

Conclusions. Software procurement is a complex process that must be managed carefully. As a general rule, it is advisable to initiate procurement strategies in the following order:

1. Use Commercial Software whenever possible since it is more straight -forward to procure and the outcome is more predictable with regard to cost, time, and quality.
   
   
2. Use Hybrid Software next with the commercial modules preferably from as few suppliers as possible so that the custom and integration modules are kept to a minimum.
   
   
3. Use Custom Software with caution since it is difficult to procure (e.g. involves IP) and the outcome is less predictable with regard to cost, time and quality.

In all cases, the extra effort expended early in the software procurement process to define realistic schedules and to define clear communication paths between supplier and customer will help align the expectations of all parties involved in the process. Also, assuring that Non-Disclosure Agreements are in place before any negotiations begin is critical for custom software and can be a reasonable precaution for commercial software as well. Finally, ensuring that the purchasing professionals assigned to software procurement have the required technical, legal and business knowledge, as well as project management skills, enhances the likelihood that the software procurement will be successful.

REFERENCES

• "Negotiating through the Software Minefield," by Patrick Egan, Purchasing Today®, February 2000.
• "Demystifying the Software Purchase," by Michael D. Feldman, C.P.M., A.P.P., Purchasing Today®, June 1999.
• "The Art of the Software Deal," by Michael D. Feldman,C.P.M., A.P.P., Purchasing Today®, January 1999.
• "Computer Software Acquisition — Issues and Best Practices," by Michael D. Feldman, A.P.P., NAPM 83rd Annual International Purchasing Conference Proceedings, 1998.
• "Issues in the Procurement of Software," by Charles A. Tyrrell, C.P.M.,A.P.P., NAPM 83rd Annual International Purchasing Conference Proceedings, 1998.
• "Controlling Software Development," by Lawrence Putnam and Ware Myers, IEEE Computer Society Executive Briefing, 1996.

Back to Top