Experts agree that the first person to consult before negotiating a managed service provider (MSP) deal is a lawyer. We've gathered some of the best legal minds on the topic and asked them to hand out some tips. The following essays should be required reading before you step into an MSP deal.
The MSP Contract: Work Visually
By Robert Zahler
A typical outsourcing contract is likely to be four to six inches thick. This heft of paper consists of legal terms and conditions and schedules describing the scope of services, the various service-level agreements, the price and pricing algorithms and a mix of another dozen or so schedules. Given all this paper, one is tempted to ask: For what purpose?
The outsourcing market is somewhat unique because there is very little litigation. There is, however, plenty of ongoing informal dispute resolution with constant renegotiation and restructuring of the outsourcing relationship. This would tend to indicate that detailed and voluminous contracts aren't actually necessary.
However, the outsourcing contract wasn't designed to be totally ignored. Rather, it was intended to be used daily to guide the ongoing nature of the relationship, much like a constitution specifying broad principles to be observed by all parties. We know from experience, however, that our clients hardly ever use the contract for this purpose because they find it too long and complex.
As a result, we have rethought the structure of our outsourcing contracts and how we can make them more useful to our clients. There are many things that can be done to improve the usefulness of the contract, but the one I want to highlight is the benefits from thinking and working visually. A key contact schedule that should get daily use is the scope of work. But because it is lengthy and not especially user-friendly, our clients routinely ignore it. In response, we have taken to depicting the schedule in pictorial form as a matrix, with:
The left-hand row headings specifying industry standard processes that describe what functions need to be performed (by both customer and supplier). The verbs in the scope of work.
The top column headings specifying, by geography, business unit and element, the things to which the various processes are applied. For example, computers, networks, hubs and routers, software and so on. The nouns in the scope of work.
At each intersection of a process and element, a color-coded box is used to describe which entity (customer or supplier) is responsible for performing that function. This scope model provides a clear, easily understandable picture of the entire outsourcing relationship in a form that is practical and useful to clients and suppliers. Behind the picture, short, unambiguous written narratives describe both the processes and the elements. If scope is changed, either by adding a new technology or location or by removing responsibility for a certain function at a specific location, the change can easily be reflected by adding or removing a column or by recoloring one or more intersections of process and element.
In addition to the benefits from using a picture paradigm to describe scope, thinking of an outsourcing relationship along the two dimensions of process and element makes fundamental changes in how the parties understand their relationship. It causes the parties to focus more on integrated, end-to-end processes rather than isolated towers of activity. It places greater emphasis on what should be done and leaves to the supplier the details of how that function should be implemented. By using industry-standard definitions for the processes, clients can easily replicate and reuse earlier work in new or follow-on outsourcing transactions.
And where clients are using multiple suppliers, a consistent set of process definitions ensures comprehensive scope coverage across the entire supplier base. By depicting the whole of the work, and not just that work assigned to the supplier, the scope model provides a broad picture to all concerned of the operating model being adopted and how all parties support and contribute to that model.
In short, moving to a visual approach for depicting the outsourcing contract can change much of the thinking that goes into sourcing in ways that are likely to lead to more robust and long-lasting relationships.
Zahler is an attorney at Pillsbury Winthrop Shaw Pittman LLP in Washington.
Taking the Risk Out of ASPs
By Michael Overly and James Kalyvas, Foley and Lardner
The use of application service providers (ASP) and hosted applications presents customers with a number of unique risks, particularly when critical applications are hosted. Key risks and potential mitigation approaches include the following:
Information Security. ASPs frequently have possession and control of their customer's most sensitive information. In many instances, this information is subject to state and federal protections (for example, personally identifiable financial and health care information). Business should conduct due diligence regarding the security practices of prospective vendors and include specific contractual protections relating to information security. These protections should include, at minimum, baseline security measures to be employed by the ASP and security incident management.
Service Levels. While most ASP agreements include performance requirements, they seldom provide any real protection. Service levels should be drafted to include all areas of critical performance (such as availability, response time, bandwidth and data-transfer requirements, and storage capacity), require periodic reporting from the ASP and include specific, escalating penalties/credits for failure to achieve those levels.
Regulatory Issues. Regulated entities, particularly those in the financial services industry, may be subject to strict requirements regarding their use of ASPs. For example, the Federal Financial Institutions Examination Council has provided specific guidance regarding use of service providers.
In-House Solution. For critical applications, the client should consider requiring the ASP to make available or develop an in-house solution. The more critical the application, the more important it becomes that the vendor be required to develop a long-term, in-house solution.
Bankruptcy. The potential bankruptcy of an ASP raises a number of issues, including the ability to quickly transition to an alternate provider or the availability of an in-house solution to retrieve critical data that might reside on the bankrupt ASP's systems. To avoid problems, clients should ensure that they periodically receive copies of all data maintained by the ASP and potentially obligate vendors to periodically provide reports on their financial condition.
Warranties. In addition to standard warranties regarding the ASP's performance of the services in accordance with the terms of the agreement, warranties should also be included to address the ASP's right to perform the services (for example, no pending or threatened litigation that would affect its ability to perform), information security, consumer privacy and regulatory compliance.
By keeping these areas in mind, businesses can substantially reduce the risks presented by ASP relationships.
Kalyvas is chairman of the e-business and IT practice group within Foley & Lardner LLP's Intellectual Property Department. Overly is a partner at the Los Angeles office of Foley & Lardner.
Getting Your Money's Worth
By Joel Agena, The Phoenix Law Group
Application service providers are a necessary evolution of our reliance on electronic technology and particularly our need for the incredible functionality provided by the multitude of available off-the-shelf and custom business software. ASPs are the alternative to hiring your own IT group and building your own hardware and software infrastructure. When engaging an ASP, there are a host of issues to consider. Below are just a few of the issues users should address.
Data Backup and Storage. Ensure that the ASP has established adequate data backup and recovery procedures. Ask for a copy of its disaster recovery plan to make sure that it has one in place. Know how your data is stored (for example, is it on separate servers?), what security measures exist for storage, and how and in what form you can get the data back.
Support and Maintenance. Make sure your service-level agreement adequately addresses the various levels of support and response times, from critical errors that require an immediate response, to noncritical errors that can wait for the next release. Determine whether support and maintenance includes updates, releases, upgrades, revisions and new versions. Identify the contact people and how can you reach them. Identify the hours they are available, what time zones they're in and the methods for contact (e-mail, pager and cell phone).
The Application. Know what you are paying for. How many users or seats are provided, and how are they determined (for example, by user name or by contemporaneous access to the application)? Ensure that your agreement provides an accurate description of the functionality and specifications of the application. This could be contained in a separate schedule, by reference to an online site, a response to a request for proposals or brochures and other sales material. If there is a conflict or dispute relating to application performance, these are the documents you will need to support your arguments.
Representations and Warranties. Ensure that the agreement has adequate representations and warranties about the application performance. Sometimes, this might be a simple reference to the specifications and functionality. If that isn't adequate, you might need additional representations about fitness for a particular purpose, or perhaps scalability. If you have performance obligations with third parties that are tied to the performance of the application, make sure the ASP's performance obligations are at least as great as yours, especially if there are penalties associated with your failure to perform.
It is estimated that U.S. companies will spend over $6 billion in 2005 on ASPs. Make sure you get your money's worth.
Agena is a partner at the Phoenix Law Group of Feldman, Brown, Wala, Hall & Agena PLC (www.phoenixlawgroup.com)
Disaster Recovery Planning
By James D. Troxell, Squire, Sanders & Dempsey LLP
In the wake of hurricanes Katrina and Rita, disaster recovering planning has been pushed to the top of the CIO's agenda. In-house counsel is grappling with questions surrounding regulatory requirements and corporate liability to shareholders, customers, vendors and employees should the company's disaster recovery planning prove inadequate if triggered through a natural or manmade disaster.
Disaster recovery planning has become more complicated as companies engage managed service providers. The issue is so confusing and complex that few CIOs nail down disaster recovery planning terms in their MSP contracts. Instead, they postpone, hoping to hammer out disaster recovery planning terms in postcontract documents. Unfortunately, by then, the CIO has less leverage with the MSP and is dealing with a host of other daily projects and emergencies that push this less-than-pleasant task to the bottom of the to-do list. Hope and good intentions are never part of a good disaster recovery plan nor any contract. CIOs should strongly resist pressure from MSPs to conclude a contract quickly and take the time to incorporate the following disaster recovery planning terms into the MSP contract:
Be Specific. Make sure the MSP contract includes a detailed description of the specific scope of disaster recovery planning work for the provider, objective performance standards and liability if the provider fails to perform the complete scope of the work or performs substandard work.
Put Teeth in Testing. The MSP should require annual testing of the disaster plan, specify the MSP resources required for testing, demand reports on the results of the tests, set penalties for any failures and, finally, provide for the implementation of changes necessary to address failures.
Avoid "Breach-Proof" Contracts. Avoid an MSP contract that either excludes damages or caps liability at a fraction of the contract price. Your provider should be willing to stand by its work.
Be Cautious of Subcontracting. Your MSP agreement should prohibit subcontracting or offshoring of your information assets without your written permission. Most countries where offshoring is a cost savings have no privacy protection laws and no effective intellectual property protection laws. Allowing assignment or subcontracting can place your data at risk.
Disaster recovery planning is no longer optional for any business of any size. Similarly, it must be addressed -- upfront, not after the fact -- in any third-party agreements, especially MSP agreements. The failure to do so could result in a disaster on two fronts.
Troxell is a partner in the Cleveland office of global law firm Squire, Sanders & Dempsey. He is an expert in business continuity and disaster recovery planning and is a member of the advisory council for the University of Akron School of Law's Center for Intellectual Property. He can be reached at jtroxell@ssd.com.
Negotiating Data Privacy Issues
By John D. Lanza, Choate, Hall & Stewart