Development and Customization in Outsourcing | Article

history of outsourcingMany businesses outsource IT solutions because they have not forgotten history, and they do not intend to repeat it. History has shown them that developing and running IT solutions in-house is often expensive and sometimes disastrous. Despite their best intentions, however, they may not be able to avoid repeating past mistakes simply by avoiding the development process.

Increasingly, development and customization are a necessary part of outsourcing. Existing solutions are not always a perfect fit. Also, as the benefits of outsourcing become more apparent, businesses are willing to outsource even if the outsourced solution needs to be built from scratch.

Fortunately, lawyers and business people are (or should be) well prepared for this trend. IT development agreements have been common for years, and the issues, agreements, and project management methodologies are familiar.

Nevertheless, businesses and their attorneys cannot blindly apply past learning from IT solution development to the current outsourcing context. Outsourcing raises new issues in structuring a development agreement, and development raises new issues in structuring an outsourcing agreement.

This article addresses four key issues that should be considered when development or extensive customization is necessary in an outsourcing arrangement:

  1. Ownership Issues. The familiar issue of allocation of intellectual property rights in deliverables between service provider and customer must be reexamined.
  2. Updates, Renewals, and Termination. Outsourcing important functions creates vulnerabilities for the customer, and introducing development into the picture makes certain vulnerabilities greater.
  3. Specifications, Acceptance Criteria, and Performance Problems. The parties can and should move some of the focus from the development phase to the services phase.
  4. Intellectual Property Due Diligence. The parties may need IP rights in addition to the ones they would need in a transaction that involved only outsourcing or only development.

Ownership Issues

Anyone who has negotiated development agreements knows that intellectual property rights are often a bone of contention. In a traditional development agreement, customers often get the better of this argument (at least since the recent downturn in professional services). In the long run, the customer is responsible for the solution and needs sufficient rights to fix, update, and modify it. Moreover, despite what the service provider often contends, it is unlikely to re-use a solution custom-designed for the customer’s systems.

The logic changes when the customized solution is outsourced. The solution resides on the service provider’s systems and the service provider is responsible for ongoing performance. It often contains, or relies on, proprietary service provider technology or a third-party value add. It is also more easily adapted for use by a third-party.

These considerations tend to tip the balance in favor of the service provider. Nevertheless, the discussion usually does not end there.

The ability to re-deploy the solution more easily for other customers raises new issues. The customer may want to share in the revenue from such re-deployment. In addition, the customer will naturally object to providing the solution to third parties it perceives as competitors. The parties should address these issues beforehand in their agreement.

In addition, the customer will not want to provide a blanket grant of IP rights to the service provider, at least not if it carefully considers the implications of patent rights. Patents cover entire processes, methods, and inventions, and patent holders can prevent others from using these discoveries.

Thus, if the service provider secures patents in inventions that it discovers in the course of providing services to the customer, it could block the customer from using or improving inventions crucial to its business. The patent problem is particularly acute for the customer where development occurs in the context of outsourcing, as the service provider may become deeply involved in a portion of the customer’s business. One likely scenario is that the service provider would exploit patent rights to prevent the customer from replacing the service provider.

Therefore, any agreement that gives a service provider ownership rights will likely require careful negotiation and drafting of IP rights provisions.

Updates, Renewals, and Termination

Outsourcing any key function creates vulnerabilities. These vulnerabilities are heightened when an outsourced IT solution is heavily customized or custom developed. The following issues are likely to arise:

  • Updates and Improvements. When a service provider sells a widely available IT solution in a competitive market, the market pushes the service provider to provide reasonably priced updates. When the “market” consists of one customized solution, what incentive does the service provider have to update it? What price can and will it charge for creating those updates?
  • Renewals. Renewals raise a similar issue. The service provider may offer an attractive price for the initial term of an agreement, but what incentive does it have to offer a reasonable renewal price? If walking away would require the customer to hire another service provider to re-invent the wheel, the service provider will have far more leverage than the customer would like.
  • Termination and Transition. What happens if it becomes necessary to terminate the relationship, if the service provider goes out of business, or if it wishes to stop providing the solution?

To some extent, a customer must accept that these vulnerabilities are risks of outsourcing and factor them into the decision to outsource. However, a good agreement can and should mitigate these risks by addressing them up front. For example, the parties can address and price further development services and renewals in the agreement.

The issue of termination and transition is particularly thorny. At the very least, transition periods should be lengthy, and duties with respect to transition should be detailed. A knee-jerk response to the termination problem may be to ask for source code escrow. The parties should consider whether this answer is realistic for an outsourced solution. The customer will likely find it difficult to reproduce and scale down the infrastructure that the service provider uses to serve all of its customers. Also, an outsourced solution is not conceived or designed so that a third party can easily assume its operations. A third party may find it nearly impossible to pull together and understand all the pieces.

Specifications, Acceptance Criteria, and Performance Problems

A recurring and often fatal problem in development projects is the failure to establish a detailed statement of work and project plan before the work starts. In any substantial development project, the parties should create specifications, acceptance criteria, and change procedures as part of the agreement or as the very first phase of the project.

The good news is that this issue becomes somewhat easier to address in an outsourcing arrangement. If the service provider must both develop and run the customized solution, then it must live with the solution as much as the customer. While good project design and management are still essential, the service relationship presents a second chance to address problems. In such cases, the customer will want the service provider to fix defects in addition to other remedies available under the parties’ agreement (e.g., service credits). Conversely, the service provider will want to place limits on such responsibilities. The agreement should address these issues to avoid later misunderstandings.

Intellectual Property Due Diligence

If the customer wants the service provider to customize and integrate third-party solutions, the parties need to determine whether they have the necessary intellectual property rights to do so. The customer’s existing licenses may not be sufficient. In addition, the third party software provider may require the service provider to have two different types of licenses and certifications: first, to perform customization and integration, and, second, to host and maintain the solution. The parties should address these issues prior to entering and pricing their project, as they can have a major impact on price and ability to perform.

Lessons from the Outsourcing Journal:

  • Outsourcing changes the discussion regarding ownership of intellectual property rights. The service provider has a more compelling case for ownership, but the parties need to consider the more realistic possibility that the solution may be re-deployed for other customers and the potential issues raised by patents.
  • Development and customization make the customer more vulnerable to the service provider with respect to updates, renewal pricing, and termination. The customer should address these issues in its agreement with the service provider, and the service provider should anticipate that the customer will raise them.
  • Any successful development project needs a detailed statement of work and project plan in place before the work starts. However, the existence of an ongoing service relationship creates the need and opportunity to address problems that arise after development.
  • If the parties are customizing and integrating third-party solutions, they may need to secure licenses and certifications in addition to the ones that they would need for an agreement that was either just an outsourcing or just a development agreement.

Written by Michael S. Mensik, Global Coordinator of Baker & McKenzie’s Information Technology Practice Group, who can be reached at [email protected]; and Mark F. Schultz, Associate in Baker & McKenzie’s Global Information Technology Practice Group, who can be reached at [email protected].


Post a Comment

Your email address will not be published.

( required )

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>