Chapter 21 - Performance-Based Contracting and Service Level Agreements

21.10.3 SLAs in a technology transfer relationship

Refer to Chapter 27, Software Licensing and Maintenance, for a comprehensive discussion of intellectual property. In relation to technology transfers from U.S. federally funded resources, you may want to become familiar with the Bayh-Dole Act or Patent and Trademark Law Amendments Act that deal with intellectual property arising from federal government-funded research. Technology transfers are more likely to be used in projects by universities and institutions, including technology and knowledge transfers between colleges and non-profit organizations; however, they may also occur between states and the federal government for major initiatives like health, medical, social services, homeland security and such. In rare cases, technology transfers may be used in projects where the agency business owner is familiar with existing technology from other states.

In all technology transfers, an agreement of associated usage, transfer, access, modification, etc. rights and restrictions between the transferor (granting source) and transferee (agency) will be required to actually use the technology in your project. It is advisable to have the Commonwealth's Office of Attorney General review any such agreement your agency may need to sign prior to confirming the technology transfer in your project strategy. Be sure to pass on any restrictions of use, confidentiality, etc., to all involved suppliers and agency agents like VITA. Also, your agency may need to discuss using the technology with VITA's Enterprise Architecture division to ensure any infrastructure compatibilities, limitations, dependencies, governance requirements or approvals.

SLAs are critical to a technology transfer relationship because they provide accountability and serve as the basis for measuring the supplier's performance. The closer the application is to the core of an agency's business processes, the more important the service level agreement becomes. Such agreements should detail the specific quality, availability, performance levels and support services the agency can expect from its service provider. In addition, the SLA should address the factors that directly affect the agency's business, such as expected response times for computer applications, system capacity and interface compatibility.

Response time metrics are often developed in contract negotiations. The minimum threshold in negotiating performance expectations in the service level agreement may be the existing service levels the agency is receiving from its prior technology. In addition, particularly where the supplier is developing new technology, the agency should consider involving user groups for establishing metrics. Suppliers are typically hesitant to provide warranties regarding response times because of the effect of external factors such as hardware, software and telecommunications. The contract should specify a system's components. Once the equipment is clearly identified, the supplier may commit to certain performance levels based upon use of the specified equipment. The supplier also may be willing to give a terminal response time warranty if the hardware and software configurations are stated with specificity. Agencies may seek financial penalties for failure to meet established minimum requirements, or offer positive incentives based on performance. Response time terms also protect an agency from the effects of a successful supplier's inevitable difficulties in handling growing business. Below are special considerations for including in technology SLAs:

• Software functionality: A technology transfer agreement should describe in detail the functionality of the software. Functional specifications should outline the business operations that are to be performed. If these specifications are determined prior to the signing of the final contract, they should be included as part of the contract. Otherwise, the agreement typically should establish milestones for development goals. The agreement should also call for delivery of documentation. User documentation provides essential operating instructions and identifies the functions of the computer system, while systems documentation provides a computer programmer with the information necessary to modify the computer software (assuming that the user can negotiate modification rights). Documentation is often a neglected step in software development as the developer strives to meet its schedule and stay within its budget. While there is no industry standard for the quality of computer documentation, the technology transfer agreement should explicitly specify the minimum documentation required, including documentation for changes to the technology. Future changes to the technology received in the transfer could impact your use of it either negatively or positively, or could render your use of it obsolete, invalid, etc.

• System configuration: Compatibility between an agency's existing system and the products selected by the supplier is essential to the efficacy of any technology transfer relationship. The agreement should specify the compatibility requirements of the supplier's system with the agency's existing system. For example, in an outsourcing deal, the supplier may transfer the customer's existing software and hardware operations to its more powerful operating system, which is used in common by a number of the supplier's clients. The contract should allocate the responsibilities to ensure a proper flow of operations. Another important element that must be included in an agreement is a specification of the system's capacity. A system should have room to grow as the user's needs expand, without having to replace the system or otherwise spend unreasonable amounts of money and time.

• Software development: Specifications governing the development and creation of new software are often the most critical part of any technology transfer agreement. There are many factors to be addressed in contracting for software development, including software functionality, implementation schedules, acceptance testing, trial periods and payment schedules. At the outset, the agency's specific needs and requirements, such as data analysis, data processing and output must be specified to ensure both parties clearly understand their duties.

• Anti-vaporware protection: Vaporware can be defined as software or another computer product that is promised but never delivered. To protect against losing money or time because of vaporware, the parties should identify where products stand in the development cycle: designed, coded, built out, alpha tested, beta tested or in production. In addition, the agreement should set forth contingency plans if the products are never developed or if they fail to satisfy the stated specifications.