A long-term IT outsourcing agreement can be a sizeable document that addresses various aspects of this important relationship in great detail. For the uninitiated, it may seem a bit intimidating, but it doesn’t need to be — not if you’ve done your homework in advance.
What follows, then, is a lesson for CIOs on IT outsourcing basics. As there’s a fair bit of ground to cover, we’ve called this Part I. Class will continue in an upcoming issue of CIO Canada.
A large outsourcing deal can involve the transfer of the user’s entire IT department — sometimes upwards of two or three hundred staff — to the vendor, together with the sale of a lot of IT equipment and software. In this sense, the outsourcing starts with a significant asset purchase deal, and the outsourcing contract will reflect this.
On the software front this raises interesting assignment issues. Software that the user owns — for example, custom software developed in-house — can be transferred with little difficulty, though you will want to check your intellectual property agreements with staff, especially third-party contractors, to ensure you have obtained all necessary rights, including waivers of moral rights.
Third-party owned software that you license can be more finicky. Ideally, when you negotiated the license you put in a clause that contemplated eventual outsourcing, so that you now clearly have the ability to hand over the software to the outsourcing vendor, so long as it uses the software solely to provide you with services.
If you don’t have such a clause, things can get tricky, as you parse the assignment clause of the software agreement to see if something like the outsourcing is permitted. Thus, an initial step in the outsourcing process is a due diligence exercise to review what can be done with the software licenses, and whether any extra costs may arise from their transfer. Any such costs are then part of the overall financial negotiation with the outsourcing vendor.
Addressing HR issues
Transferring employees to the vendor also raises a set of delicate legal issues. For example, it is often the case that the user has a traditional defined benefit pension plan, whereas the outsourcing vendor has a defined contribution pension plan, or no pension plan at all. Thus, serious homework, thought and creativity need to go into an HR plan that allows the pension transition issue to be dealt with fairly and in compliance with regulatory requirements.
On the employment law side, special considerations may also arise. The user may want the outsourcing vendor to treat the transitioning employees in a certain manner, at least for a period of time. From the vendor’s point of view, this raises a host of issues, not the least of which is that it wants to treat all of its staff consistently. Creative, temporary deals can result, where the user’s and vendor’s reasonable interests are accommodated.
All of these transition issues then need to be slotted into a detailed transition plan that sets out expectations regarding timing and the respective roles and responsibilities of the parties in getting the new environment up and running. It’s important to do the transition right, so that the user can see it picked the right vendor among the different prospective bidders, and so the vendor can begin to earn the confidence of the user.
Can we do this?
One of the threshold questions that the user should research during the early, internal phase of deciding whether and what to outsource is whether the particular function being considered can in fact, from a regulatory perspective, be outsourced, and especially to a service provider in an offshore country.
The general response is usually “yes”, but there are numerous industries that generate more complex answers. Financial services companies, for example, must comply with guidelines on outsourcing from the Office of the Superintendent of Financial Institutions (OSFI). And sending data out of Canada, especially offshore, requires yet further approvals from OSFI. These hurdles tend not to be insurmountable, but they are more effectively managed when work on them starts early in the consideration process.
Data privacy is one regulatory issue that has gained prominence over the past few years, particularly in light of the relatively new federal data protection law in Canada. This law has broad rules governing the collection, use, storage and transfer of personal information. So if you collect customer data from individuals and want to have this data processed offshore, you have to carefully consider the relevant privacy law issues, and make sure they are adequately dealt with in the outsourcing agreement.
Moreover, when you (or your supplier) is offshoring, it’s not just Canadian privacy laws you have to contend with. Keep in mind that you are contemplating processing and possibly storing your company’s data in a foreign country. What is that country’s legal regime like in respect of privacy protection? How do those rules square with those in effect in the relevant Canadian province?
Other foreign laws can also come into play. For example, under the U.S. Patriot Act, American law enforcement entities can access computers resident in the U.S., looking for data regarding various persons and activities. What protection, if any, does a Canadian user have if the U.S. government wants to access data of a Canadian that happens to be resident in the U.S.?
If this sort of issue is of concern, one response is to require the service provider to store the data in Canada, but sometimes this may not be enough, particularly depending on the ultimate ownership of the service supplier. Each situation needs its own analysis, and levels of concern may vary depending on the foreign jurisdiction involved.
Vendor oversight
Plato asked “who shall govern the governors?” In outsourcing, the question is: “who shall govern the vendor?” The answer, ideally, is that some of the user’s senior IT managers (let’s call them the Project Management Office or PMO) are not transitioned to the vendor, but remain with the user in order, among other things, to oversee the relationship with the vendor and to implement and enforce the outsourcing agreement.
The roles of the people in the PMO change quite drastically from what they did before the outsourcing. Instead of focussing on the day-to-day activities of running a data centre, they now focus on meeting the IT needs of the user’s various business groups. And they translate these requirements to the outsourcing vendor in a manner that ensures that the user continues to have an important impact on the general direction of its IT strategy. Thus, ideally, the user delegates performance to the vendor, but does not abdicate overall IT vision and strategy.
One important mechanism utilized by the PMO to assert oversight is the outsourcing contract, the legal document that defines the formal commercial relationship between the user and the vendor. Such documents can easily exceed 100 pages, exclusive of another 200 to 500 pages of schedules. This is not a function of outsourcing counsel, conspiring to create complex contractual labyrinths only they can understand; rather, there are simply so many important issues that need to be addressed in an outsourcing relationship that the resulting document is invariably a weighty tome.
No part of this document is more important than the description of the services that the vendor will provide. You would think that this would be a fairly simple exercise. Well, you also thought at one time — particularly before you began playing it — that golf was a simple game. Of course now you know it isn’t, and similarly defining services in an outsourcing deal is not a trivial exercise.
Enumerating the list of services is relatively straight forward — like picking a good set of golf clubs. Describing in meaningful detail the quality levels at which those services will be performed, now that’s a much more challenging endeavour, like playing par or even bogey golf on a consistent basis.
The quality of a given outsourced service is usually defined by means of a Service Level Agreement (SLA), which is typically a fairly lengthy schedule (rather than separate agreement) to the main agreement. An SLA for a software application, for example, might include that under certain volume load conditions, the average response times of the user for certain functions and queries are as set out in the schedule. There would also be a remedial system in the agreement in the event the detailed performance standard is not met, in order to exert a discipline on the vendor.
The all important question is what should be the applicable SLA for this (and many other) portion of the outsourcing services. It goes without saying that it should be at least equal to the experience obtained by the user before the outsourcing — or why outsource in the first place? But what if the user didn’t track SLA statistics historically? You can start to see why outsourcing agreements can get complicated and contentious.
These are a few of the higher profile issues that come up in outsourcing/offshoring deals. It goes without saying that you should give yourself lots of time to prepare for, and to negotiate, a sensible, win-win deal.
QuickLink: 065909
–George Takach is a Partner with legal firm McCarthy T
