‘Tis the season! For the holidays, et cetera, but more particularly for CLEs which meet the Law Society for Upper Canada’s new requirements for professionalism and ethics. Every lawyer called to the bar in Ontario must complete three hours of continuing legal education approved by LSUC that is directed to instructing on professionalism and ethics. In the mad rush to meet the year-end deadline, CLEs are popping up all over the place directed to this topic.

IT Professionalism and Ethics CLEs: An Introduction

For outsourcing and information technology lawyers, it was a challenge earlier this year to find relevant seminars. There were many generic seminars on practice management and the like that could appeal to an information technology lawyer in a general sense, but very few seminars that addressed issues specific to the practice of information technology or outsourcing law.

I suspect that there are several good reasons for this. IT lawyers are rarely in court, so the ubiquitous litigation-related professionalism courses are only tangentially relevant. (IT companies rarely air their dirty laundry, preferring in the worst cases confidential arbitration instead.) IT lawyers spend most of their time either drafting contracts or negotiating them between reasonably well-funded and well-represented parties, which can make for boring ethical fodder.

Recently, however, there have been a number of seminars that were of particular relevance to IT lawyers in Ontario. The Ontario Bar Association and LSUC put on a couple of seminars in the fall, for example. Our colleagues across the country may find these seminars of interest even if they do not have these particular CLE requirements to contend with. A number of these seminars addressed ethical and professionalism issues arising in contract negotiation.

This topic is near and dear to my heart. I spoke on it at a recent session to the Licensing Executive Society. With that engaged audience, we ran over time by almost half an hour, and had to cut the session short, because there was such excellent discussion to be had. So much for it being boring ethical fodder, I discovered.

In this column, and in at least one more upcoming column, I will present one or a number of scenarios in which ethical or professionalism concerns arise in the context of IT transactions. Some of these scenarios could be generalized to any commercial transaction, and others have a particular IT twist.

Errors in IT Negotiations

The first scenario I would like to discuss is whether it is ethical or professional to take advantage of errors of opposing counsel or their client in the context of an otherwise balanced IT negotiation.

Most if not all professionalism codes will expressly forbid “sharp practice”, which, in the little case-law in Canada that describes it, includes taking advantage of a “clear oversight” by an opponent in a proceeding. (Construction Workers Local 53 v. Fahringer Mechanical Contractors Limited (2001), CanLII 3504 (ON L.R.B.)). LSUC’s Rules of Professional Conduct instruct a lawyer to “avoid” sharp practice, and particular forbid lawyers from taking advantage of mistakes of other legal practitioners where such errors do not go to the “merits”. In a negotiation, this is a thin line. There are few procedural errors a lawyer could make in a negotiation, and most errors would go to the merits or otherwise affect their client’s rights.

There are several general categories of obvious errors that occur in an IT negotiation.

Metadata

One of the most common obvious errors is a failure to cleanse a document of metadata. Metadata, such as the author of a document, when it was created and edited, and, in a document with tracked changes, who made which changes at what times, can provide a wealth of negotiating information to an opposing party. For example, it can help an opposing party identify who the decision-makers are and call out internal disagreements within an opposing party. For this reason, it is common practice to scrub documents intended for the other party of all metadata.

Once in receipt of a document containing metadata from the other party, is it unethical or unprofessional to take advantage of the error and review the metadata? I think so, but there were mixed opinions at some of the seminars I attended which addressed the topic. I believe that it falls within the LSUC prohibition, since metadata cannot be said to go to the “merits” of a point under negotiation. As a practical matter, I know it is possible to manipulate metadata, so would not be inclined to rely upon it anyway.

Internal Correspondence

Another common but obvious error is the inadvertent inclusion of internal emails in an email reply. In the heat of a busy negotiation, the parties will be exchanging many emails. These emails are often forwarded internally within each party, and may be commented on. Strategies and potential responses may be discussed before a response is formulated and returned. It is at best embarrassing and potentially quite damaging when this internal discussion is forwarded to the other party in a negotiation.

Once having received a document that contains such information, I feel that I am ethically obliged to limit its distribution. I may or may not have contractual obligations to keep the negotiations confidential. But, in any event, the error cannot be exploited, so limiting its dissemination will reduce the temptation to do so by my client.

Practical considerations may prevail anyway. It can be counterproductive to raise the error, or to use the information provided by it, in negotiation. Although it is nearly impossible to stuff the genie back in the bottle, if the party that made this error is reminded of it subsequently at the negotiation table, it is likely to embarrass or upset them further, and put distance between the parties. Conversely, an error professionally handled can engender respect between the parties, and, ultimately, a measure of trust that will be essential to close the transaction.

Technological Errors

A third kind of error is what I call a “technological error”. It is an error in the specification of the technology being contracted for under the agreement. This kind of error is often only obvious to one of the two parties. The party with the greater technological expertise may spot that the other party has made incorrect assumptions or selected technology that would not work as intended. If this error is made by the customer, the service provider has a strong business interest to stay silent. Once the error is discovered, often after the contract is signed, the service provider is in a much stronger negotiating position, and can use the error to force other changes in the agreement, including increased fees.

If I was acting for the service provider, and my client informed me that the customer had made such errors in their specifications, I could be in a difficult position. This is not an error of opposing counsel, but instead is an error of their client, so the professionalism rules do not apply. If there were a great inequality in bargaining power, case law relating to such negotiations in non-technical fields (such as employment or franchise law – see Shelanu Inc. v. Print Three Franchising Corp. 2003 CanLII 52151 (ON CA), (2003), 64 O.R. (3d) 533, and the cases cited therein) have imposed a duty to negotiate in good faith, which, if it applied in an IT transaction, could oblige a party to point out an error like this. However, in a negotiation involving sophisticated and well represented parties, I would not have trouble staying silent with respect to this error, since the parties are well equipped to spot their own errors.

Rule of Thumb

There are, of course, many other types of errors that can arise in an IT negotiation. To evaluate each, counsel should consider whether the professionalism rules of their jurisdiction apply, whether a duty to negotiate in good faith applies, and whether, as a practical matter, the damage to the relationship between the parties is worth the gain to be had by exploiting the error.

The IT bar in Canada is an intimate one, and word gets around. To keep your clients and preserve your reputation, ultimately, the soundest course is to follow the golden rule, and treat others as you hope to be treated (and make sure your insurance is up to date).

It is commonplace these days for parties to an IT contract to consider alternative dispute resolution (mediation or arbitration) as a means for resolving disputes. I have written on the topic of mediation in outsourcings, and concluded that it was useful in some outsourcings, but not all. At an engaging lunchtime seminar I attended the other day on ethics and professionalism issues arising in IT law, I had my thinking on this topic jolted by a turn in the discussion towards the use of subject matter experts by the court. One of the speakers, Don Johnston, pointed out that courts had long used independent experts in admiralty cases to understand the potentially complex fact scenarios arising at sea, and wondered what was so objectionable about courts using experts in IT cases, where the technology would be at least as murky. It got me thinking that the problem with cookie-cutter dispute resolution clauses that often appear in IT contracts is that they attempt to apply the same process to every dispute.

Disputes arising from IT contracts can be broken down in a number of different ways. One way to distinguish disputes is by the remedy sought by the parties. In my view, a dispute should be handled differently if the parties are looking for injunctive relief or specific performance than if the parties are merely seeking payment or some other remedy. A dispute resolution process should be flexible enough to allow the parties to select a method of dispute resolution that will provide them with the remedy they seek. To avoid additional friction when a dispute arises, I would suggest that the parties turn their minds to this issue when preparing the agreement, and carve out from a general dispute resolution clause and the convention escalation procedures any disputes that require a special remedy. Some agreements will carve out intellectual property related disputes from a mandatory ADR clause, allowing the parties to seek emergency injunctive relief. It would also be appropriate to provide such a carve-out for disputes involving a breach of confidence for the same reason. Another dispute that is often treated differently is a dispute regarding whether a payment is owed. Since the only issue is such a dispute is whether and how much money is owed from one party to the other, a payment dispute may be resolved while the relationship continues and work proceeds. This works best when the payment dispute resolution process is quick and binding, to avoid the possibility of abuse by the contract payor.

Another way to divide up disputes arising from IT contracts is by the nature of the dispute itself. Some disputes are at their core about contractual interpretation, some are about determining standards of care, and some are about interpreting technical specifications. Different expertise is required of an adjudicator to address the concerns of each type of dispute. Many of these disputes center around a critical finding of fact or law, and not with an assessment of damages or any requirement for a court order. Once this critical finding is made, the parties can sort out the rest by themselves.

Here is a crude breakdown of dispute type correlated with expertise required of a neutral or adjudicator. I have also proposed some alternative dispute mechanisms designed to bring objectivity to the process without limiting the parties’ ultimate rights and remedies at law.

The ultimate goal is to introduce objectivity into the discussion between parties early in a dispute, before the parties’ positions are hardened. The parties can learn from the neutrals and inform their positions leading into a formal dispute process, and may discover that the positions taken are unreasonable or unsustainable, thereby diffusing the conflict. Rather than trying to make this process mandatory in contract, I feel that it would be most persuasive and effective if it was purely voluntary. In my examples above, by ensuring that the decision of the neutral is not binding, the parties can invoke the process without damaging the relationship by pushing it to a formal dispute process. This is of particular importance in IT contracts that create an ongoing relationship, where dispute is inevitable, and preserving the relationship is of paramount concern to both parties.

There is room within IT contracts for a flexible and voluntary dispute resolution process that separates out disputes that are amenable to early resolution, and which introduces a neutral having appropriate credentials to the process to provide objectivity to those disputes before they spin out of control.

Gain-sharing, as a concept, appears to be falling out of favour in recent outsourcing transactions. Once considered an innovative concept for sharing saving made by the supplier of outsourcing services, it has proved unworkable, or forgettable, over the years. Gain-sharing clauses started appearing in outsourcing contracts at least as early as a decade ago. The principle is simple: if the supplier finds a way to save costs while providing the same service, it will share those savings with the customer.

Gain-sharing has a fundamental problem: the interests of the supplier and customer are not aligned. The customer is trying to save costs while the supplier is trying to make money. This tension between opposing interests naturally leads to an equilibrium – that point at which both parties feel that they are getting value from the relationship. Once this equilibrium is established, the commercial interests of each party favour maintaining that equilibrium. Gain-sharing can threaten that equilibrium by pressuring the supplier to reduce its costs while undercutting the supplier’s incentive to do so. The supplier will have difficulty stirring up much enthusiasm for gain-sharing when it could threaten its business case for the outsourcing in the first place.

Another issue with gain-sharing is that it may not actually lead to any savings. While a change in a solution, such as a design change or a change in subcontractor, could theoretically save ongoing costs, when that solution is formally brought into the outsourcing agreement between the parties, the implementation costs, including legal costs and other business process costs, may outweigh the savings that the customer would realise. For this reason, the supplier may choose not to perturb an established and working solution for the opportunity of cost savings, reasoning that the long term gain is not worth the short term pain.

Gain-sharing is also easily forgettable. In a longer term outsourcing, with the myriad of day-to-day issues that face both the customer and supplier, someone has to remember to enforce a gain-sharing provision. Typically that burden falls on the customer, it being in its interest to do so. If the customer does ask for an accounting of gain-sharing savings that the supplier has realised, the answer from the supplier may be that there are no such savings. It would be nearly impossible for the customer to prove otherwise.

A gain-sharing provision may make good sense when the incentives of each party can be driven together. One example is where the customer and the supplier have agreed to share certain third party costs. If the supplier is able to realise a savings on those costs, some of those costs could be shared. The supplier and customer together may be able to work together to leverage their combined position in negotiating lower costs with the third party. This can work well when purchasing equipment or licensing off-the-shelf software from third parties.

Gain-sharing is an example of a concept that was good in theory, but rarely worked in practice. It may be time to move this concept out of our outsourcing templates permanently.

In my last column, I discussed the convergence between the SaaS contracting model and the outsourcing contracting model. In this column, I wish to explore a strongly related topic: the increasing trend of using cloud elements in outsourcings.

There is some overlap between software-as-a-service (SaaS) services and cloud services. Before the cloud became the marketing buzzword we know and love today, a SaaS service referred to a contracting model where software features were provided over the Internet. From a legal perspective, there was not much of a difference between SaaS and the application service provider (ASP) model that preceded it. SaaS came in as the mot de jour, and ASP went the way of the service bureau and mainframe computing, borne back ceaselessly into the past.

Now, SaaS has a slightly different meaning in a cloud context. SaaS is used alongside infrastructure as a service (IaaS) and platform as a service (PaaS) to refer to different types of cloud services. I use the term “cloud” to refer to a technological model of enabling network access to a pool of configurable computing resources, where: i) the hardware is abstracted from the end user, and ii) capacity is scaled in response to increased demand.

Some folks will also want to add that cloud services are only offered on a subscription basis, but I can think of several examples where it is not. However, I agree that if a software service is offered on a subscription basis over the Internet, then it is definitely a traditional SaaS service. If that same service is readily scalable to meet increased demand, then it should be called a cloud SaaS service.

A cloud SaaS Service, when enhanced with some of the customized and service-based features (discussed in more detail in my last column), becomes an attractive alternative to a services outsourcing. But it does not have to be either a cloud SaaS service or an outsourcing. The solution can incorporate elements of both models.

For example, in a larger outsourcing, it may be desirable to host at least some of the outsourced services on a cloud infrastructure. If the infrastructure is provided by a third party, then this is an IaaS model incorporated into an outsourcing. The outsourcing provider is providing highly customized services for the customer on a cloud provided by a third party. In this hypothetical example, the outsourcing provider creates the software applications, maintains the databases, and provides the troubleshooting and support for the outsourcing to the customer, while the IaaS provider contracts with the outsourcing provider to provide the infrastructure upon which these services sit. There would still be considerable capital costs for the customer, since the customized applications would need to be developed on their dime, but at least the customer is not paying for the capital costs to provide a scalable private data center as well. Instead, the infrastructure costs can be passed through to the customer as an ongoing expense, lowering the capital costs significantly while allowing the customer to scale the services predictably to manage increased demand later on.

No doubt large outsourcing providers already manage private infrastructure clouds of their own upon which they provide their outsourced services. Vast numbers of virtualized cloud instances can be managed on an infrastructure like this, where the needs of different customers are balanced within one large cloud without disclosing any hardware details to each customer. The use of these private clouds may be disclosed to the customer, and the customer may be billed for usage accordingly. Alternatively, the use of a private cloud could be entirely hidden from the customer, and instead be a matter of network architecture and management for the vendor alone.

If cloud services are incorporated into an outsourcing arrangement, in addition to the considerations raised in my last column, counsel for the customer should consider some cloud specific concerns:

• Security and Privacy of Data: It is still up for some debate whether the cloud model is any less secure than more traditional models. Some recent articles on Slaw and Lawyers Weekly highlight the debate. In my view, it depends on the technology actually being implemented. One needs to pierce the cloud and understand what is behind it to properly answer questions relating to privacy and security. Without taking the time to understand the technology, one cannot reasonably appreciate whether the steps being taken to secure it are reasonable and will actually work. In an outsourcing context, counsel will almost certainly require technically assistance.
• SLAs: The service levels provided by IaaS providers are typically fixed and non-negotiable. Take, for example, Amazon’s EC2 cloud SLAs: 
1. Amazon will use reasonable commercial efforts be up only 99.95% in a year (which is 4.3 hours of downtime a year). Downtime is defined as the percentage of time that the entire region is unavailable (i.e. the entire US East (Northern Virginia), US West (Northern California), EU (Ireland), Asia Pacific (Singapore), or Asia Pacific (Tokyo) zone is down).
2. Downtime excludes Force Majeure events, and downtime that result from failures of individual instances, other than the entire region being down. This essentially means all of your instances in a region are down, and you cannot start new ones.
3. A 10% credit on your bill is your sole and exclusive remedy, assuming you ask for it.

These standard EC2 terms would not be acceptable for any sensitive or mission critical applications. Other IaaS providers offer similar fixed service levels. For larger usages, there may be room to negotiate with the cloud provider. However, since the underlying architecture will likely not change based on these negotiation, it would simply be an exercise in moving financial penalties around, not improving uptime or incenting improved performance by the cloud provider.

• Potential for Third Party Impact: In a shared IaaS environment, as in any shared environment, there is the potential for third party users of the shared environment to have an impact on the customer’s experience. There are two considerations which flow from this.
1. The first consideration is whether a financial penalty, such as an SLA credit, would be sufficient if there is chronically poor performance of the cloud services. It may not be if, for example, the application is so important to the customer’s business that it cannot tolerate any sustained period of poor performance. If the customer cannot tolerate poor performance then a shared cloud may be too risky, and therefore not a suitable model for that customer. Some cloud providers manage this risk for customers on shared clouds by capping each user’s usage of the cloud, but this also limits the inherent flexibility and scalability of the cloud, and so is not a perfect solution.
2. The second consideration is whether the customer wants to be down at the same time as everyone else on the cloud. From a business perspective, if you and your competitors share a same common point of failure, then when that failure happens, there is no advantage to either of you. However, if you are tolerant of that failure, and your competitor is not, then you are able to capitalize on the failure and grow your business. A shared cloud represents a single point of failure for competitors that all use it.
• Latency: Latency can be an issue for cloud based services, simply because the services are all limited by the speed of the network they are on, and the speed of the connections used to interface with that network. When the Internet is used to interface with the cloud, latency can be a serious issue for time sensitive applications. Packets sent over the Internet can arrive out of order or not at all, requiring retransmission and delay. If the cloud instances carrying out aspects of the cloud services are disparate, the potential for significant network latency can be even greater. So, in larger clouds, increased latency can be a price paid for better reliability and uptime. This may not be suitable for all applications.

The cloud offers vast potential for lowers capital costs and improving the financial attractiveness of outsourcings, but a customer should be certain that the resulting solution is right for them, both from a legal and a technical perspective.

Services outsourcings and software-as-a-service (SaaS) offerings lie on nearly opposite ends of a spectrum of managed services that a service provider can provide a customer. Traditionally, they serve the customer in quite different ways and are considered to be separate services, but some service providers are offering “customized” SaaS services, which in essence lie in the middle of this spectrum of managed services. Only certain services can be offered both as a SaaS Service and through an outsourcing, but the breadth and complexity of SaaS Services, particular cloud-based SaaS Services, grows constantly.

Outsourcings are generally used to transfer responsibility for a large and complex piece of a customer’s business to a third party. The primary driver behind an outsourcing is typically cost, since the service provider generally promises to perform the outsourced services at a lower cost than what a customer can achieve internally. The cost savings comes from leveraging the infrastructure, resources and expertise of the service provider. However, outsourcings can become unexpectedly expensive for a customer when the provided solution does not neatly mesh with the customer’s remaining business functions. Change orders and scope creep drive up implementation costs.

In contrast, software-as-a-service (SaaS) offerings are typically offered as a commodity service, having set parameters and set pricing, and being available on the same terms to everybody. The advantage of a traditional SaaS service is cost, especially low upfront costs. Typically very little capital is required to sign up for a SaaS service, and only an ongoing subscription fee applies. There are fewer unexpected costs arising from the SaaS service, since it is not subject to change orders or scope creep. SaaS services are typically provided on a “take it or leave it” basis. 

Increasingly, there is a trend among SaaS providers to offer “customized” SaaS services, which are tailored in some way to meet the specific needs of a particular customer. Some SaaS providers have developed their service offerings such that they have embedded into them a large number of variable service parameters, allowing for customized end user interfaces, database and dataset compatibility, and customized monitoring and reporting tools. Certain SaaS providers have created software development kits which can be exploited by customers or third parties to develop customized applications that work with their SaaS offerings, which can provide for even greater flexibility.

I see this as a natural convergence between the two contracting models that could be of benefit to both the customer and the service provider. From a customer’s perspective, by moving to a customized SaaS service, the customer can realize greater cost savings over a stand-alone, full blown outsourcing arrangement. From a service provider’s perspective, it is able to build a platform once and sell it many times over, a potentially more profitable business proposition.

On the downside, the customer would have to be more flexible with respect to its requirements if there is not a customized SaaS solution that fits the bill. Customized SaaS solutions will only go so far, and invariably there will be requirements that they cannot meet in particular circumstances. A customer may also have to settle for service levels and technical support that is inferior to a fully outsourced solution. Some service providers may be willing to negotiate special terms for larger providers, to afford a customer dedicated support, dedicated hardware, or other particulars. However, the resulting services may rise in complexity and expense to a level equivalent to an outsourcing arrangement. 

A customized SaaS solution can be an excellent vehicle for a customer to realize cost savings, so long as it can handle not getting everything it wants from its solution. Counsel for a customer considering such a solution should address at least the following potential legal concerns that may be particularly affected in a customized SaaS service.

1. IP Ownership: In a customized SaaS solution, without any third party customization, the service provider will likely insist on ownership of the customizations. The customizations in many cases will simply amount to configuration details, which are intrinsic to the platform, and would be of little value when separated from it in any case. In other instances, the customer may be asked to pay for custom code. Some of that custom code may be for completely new features for the SaaS solution, which the service provider can resell to other customers at little incremental cost. In such cases, the customer would be wise to refuse.
2. Transition Assistance: SaaS Services typically do not allow for significant transition assistance upon termination, whereas outsourcings almost invariably do. The customer should carefully consider what type of termination assistance it might need in a customized SaaS solution, taking into account the portability of the data in the existing solution, the amount of time needed to move to an alternative solution, and the requirements for services and support during that time.
3. Key Personnel: SaaS Services typically do not identify any key personnel requirements, but outsourcings often do. The rationale in an outsourcing is that key personnel can be crucial to the success of the outsourcing, and so some restrictions are placed on their allocation and utilization. The customer should carefully consider whether similar restrictions are necessary for key personnel spearheading the customization portions of any customized SaaS Service.
4. Change Orders: SaaS Services typically do not identify a process for managing change, whereas outsourcing often do. Managing change is a crucial aspect of any large outsourcing, as other commentators on this blog have discussed at length. For the same reasons, a customized SaaS solution should contemplate some process for managing change.
5. Governance and Escalation: SaaS Services do not generally provide for a governance process involving executives of both parties to the contract, but will often offer some kind of escalation process. A customer to a customized SaaS solution may require more rapid escalation of issues that a standard SaaS Service would provide, and will likely require an escalation process that escalates to a key decision-maker of each party. Otherwise, issues, and in particular implementation and development issues, can become stalled in a customer service nightmare, without appropriate and timely recourse.

Sophisticated service providers will pre-empt customers by addressing these issues in their standard “customized” SaaS Services agreements, making it easier for customers to sign on and start enjoying their cost savings.

The typical outsourcing involves the outsourcing of not only a business function, but also the technological infrastructure to support it. When preparing an outsourcing agreement, the hardware, software and systems of each party to the outsourcing need to be carefully considered and well understood. It should be part of the due diligence of embarking on the outsourcing process.

Most companies that are looking to outsource will already have in-house technical expertise. This in-house expertise should be relied upon to map out a company’s technical capabilities and limitations. This will set the stage for properly mapping the technical requirements for the outsourcing, including what resources are necessary from the company to be successful. Failing to properly identify these technical requirements will inevitably lead to higher transition and implementation costs, and may lead the parties to the outsourcing to dispute.

The analysis may not be adequately performed by in-house resources. In-house resources may speak their own jargon and not the language of the industry at large, leading to interpretation issues that can rise later on. Some “three letter” companies particularly are known for their use of jargon, but it is a tendency that persists in every organization to some degree. Similarly, in-house resources may not be aware of the most recent or most prevalent standards in the IT industry at large because they have been working within their own particular niche and the particular needs of their business. Serious misunderstandings in the scope of services to be provided can arise from these subtle but important differences in meaning.

In more complex or sensitive outsourcings, companies should consider bringing in additional technical resources on contract. In-house folks are invaluable in understanding the needs of the business itself, but they should be paired with outside technical expertise who can translate the needs of the business into technical specifications that are clear and written in the industry standard language.

Having adequate technical expertise assists in preparing the outsourcing agreement as well. Technical resources that have prepared the technical specifications can be a resource to lawyers preparing the contract by ensuring that the language used in the contract is consistent with that in the specifications and the industry at large.

Technical resources should be also be consulted to assess whether contractual mechanisms that are in place are appropriate for the technology being employed. For example, consider an outsourcing which calls for an interface between the in-house systems and the systems of the party performing the outsourcing services. The interface should be very carefully understood to identify any dependencies between the two parties to it. These dependencies need to be understood at the contracting phase to avoid differing expectations, scope creep, and disputes. If the dependencies or requirements of each party are not understood after the contracting phase it may be too late to provide for adequate remedies in the contract, or adequate flexibility within the contract, to address unforeseen circumstances caused by them.

Technical resources can also be invaluable in determining appropriate remedies for contractual failures. For example, in typical North American outsourcing, there will be service levels which may have service level credits or penalties applied for failures. The service levels, and how failures of service levels may arise, should be understood from a technical perspective so that the parties are not creating service levels that are immeasurable, unmanageable or unrealistic. Such flawed service levels distort the business relationship between the parties and drive undesirable behavior, undermining their value entirely.

Any outsourcing team should be staffed with skilled technical resources – individuals that can speak to both the in-house technologies being used, and to the outsourced technologies being employed, and understand any dependencies and interrelationships between them. If you are considering outsourcing, consider not only having appropriate legal counsel but also appropriately skilled and knowledgeable technical counsel. 

The nomenclature of a contract can subtly alter the relationship between the parties. The choice of particular words can create tension when exercising the provisions containing them simply because of how they sound, and what impression those words make in the mind of the reader. The legal effect can be identical, but a subtle psychological bias can be introduced by selecting loaded words as definitions or terms. This bias can be reinforced by using the notice provisions of the agreement to influence whether a notice is communicated, and how it is communicated.

Consider a scenario where a first party is required to perform, and a second party is to notify the first when its performance is not to the standards in the contract. In this scenario, the contract calls for a "deficiency notice" to be sent, and permits such notices to be sent by email. The connotations of the word "deficiency" are relatively innocuous. The word suggests that only a minor breach has occurred. It could be easily inferred that deficiencies will occur regularly, and the parties are encouraged to discuss them. The term does not, in and of itself, say anything about the parties themselves, only that one party’s performance is below standard in some respect. The word “deficiency” as a noun is not generally used to describe a person, so does not tend to invoke an emotional response in those that hear it. (In my mind, it is comical to describe someone as a “deficiency”, since it is so incongruous.)

Consider a second scenario, nearly identical to the first, except that instead of sending a "deficiency notice", the contract describes a "failure notice" for exactly the same circumstances. This “failure notice” has a prescribed form having particularly legalistic language. The “failure notice” must be sent according to a specific procedure for providing notice that is onerous. Perhaps the “failure notice” is addressed to a senior executive instead of a manager or project manager, and must be hand delivered. The connotations of a "failure notice" are harsh. The word “failure” can be used to describe both an event and a person, and therefore tends to invoke an emotional response in those that hear it. By providing a "failure notice", the second party is by implication branding the first a "failure", describing not only the first's performance, but implying something about the first party itself.

If the likelihood of a party not performing to contract is the same in both scenarios, the choice of language will have a meaningful impact on the relationship between the parties. In the first scenario, by choosing words that are benign and selected carefully to facilitate communication, the parties will enjoy a better relationship. Relationship managers and project managers living the contract day to day will feel comfortable sending deficiency notices by email, since doing so will be less likely to be perceived as an insult to the other party. In contrast to the first scenario, in second scenario, the contract creates an atmosphere of hostility and sets up the parties as adversaries. Those that are implementing the contract are required to send notices framed in aggressive language that sets the stage for dispute.

One approach is not necessarily better than the other. Since the choice of language will have a subtle but serious impact on the relationship, it should be chosen with the relationship of the parties in mind. There are some business arrangements that will lend themselves to a more intimate partnership, and some where a more distant relationship is appropriate.

Lawyers should carefully consider nomenclature when drafting a contract intended to govern a long term relationship. Long after the lawyers have left the scene, relationship managers and project managers from both parties have to live with the fallout of those word choices.

I was speaking with a colleague recently regarding whether mediation was a valuable tool in outsourcings, and if so, under what circumstances. We came to the conclusion that it is an appropriate tool for some outsourcings, but not all. 

It is inevitable in any outsourcing or large managed services arrangement that disputes will arise. Disputes arise for a myriad of reasons, ranging from a failure of the parties to appreciate and agree on fundamental business terms, such as differences of opinion on specifications or deliverables, to perhaps the more mundane question of whether a notice required by the agreement was given properly. Since these arrangements last for relatively long periods of time, preserving the relationship between the parties is very important for the outsourcing to be a success. 

In outsourcing agreements, the parties typically spend a fair amount of effort drawing up complex governance procedures, which include various committees, meeting schedules, roles and responsibilities, and, most germane to this discussion, a method for addressing disputes. The point of the committees, meetings, etc. is to ensure that there are plenty of opportunities for the parties to communicate. Good communication reduces the chances that small problems become big problems. (How to get the parties to actually follow the governance procedures is an entirely separate problem for another article.) 

In my experience, the dispute resolution procedures in these large contracts boil down to two basic steps: escalation and litigation.

Escalation generally involves referring the unresolved problem to successively higher levels of governance after set periods of time have elapsed. In theory, by escalating the problem to more senior levels of each party’s organization, the more senior members, being relatively more empowered within their respective organizations, are able to overcome the problem through the use of their power. In practice, the escalation process may simply entrench the parties in their respective positions. 

In the litigation step, in which I would include any binding adversarial process like arbitration, the parties are faced with an expensive and time consuming process that distracts the parties from the core business of the outsourcing. 

In my view, the fundamental problem with this process is that it takes the two parties and gradually forces them apart. At each step in the escalation process, and certainly by the time the parties reach litigation, the process naturally reinforces each party’s respective positions. The relationship between the parties can become strained, which further exacerbates this problem. This appears to become especially the case when the escalation is rapid or the stakes are particularly high, as the parties have not had an opportunity to cool off and gain some perspective on the dispute. 

My colleague and I concluded that under these particular circumstances, it would be helpful to insert a mediation or facilitated negotiation process between the escalation step and the litigation step. The principal benefit of mediation would be the introduction of a true neutral participant. A neutral having independence from either party and perspective on the dispute could shake the parties loose from their entrenchment and get them thinking creatively. Another benefit is that the mediation process is designed to bring the parties closer together, not to drive them apart, and therefore is more likely to preserve the relationship between the parties. 

For example, in the “build” or implementation phase of an outsourcing, timelines are short and there is a great deal of pressure on the parties to perform. A mediation step can inject some breathing room and fresh thinking, and resolve the dispute much more quickly than litigation ever could. Since the quick resolution of disputes are essential to a project’s success, mediation would be a valuable step in the process to save time and keep a project on track. 

In an ongoing services outsourcing, which has relatively long escalation timelines and a well established relationship, the benefits of mediation are not as clear. In this type of outsourcing, by the time a dispute has been completely escalated through the governance process, the parties have had plenty of opportunities to negotiate a solution, and are now looking for someone to render a decision so that they can move on. A mediation step introduced at that stage may only delay that decision and frustrate the process. 

I invite readers to share any experiences that they have had with mediation in the context of outsourcings, and particularly to comment on those factors that led to its success or failure. 

In any outsourcing or other large contracting arrangements, one of the principal challenges is developing good lines of communication with the client. Whether one is acting as corporate counsel, or outside counsel, it can be a challenge sometimes to explain legal problems and manage expectations to deliver the best advice possible to the client. To manage this concern, I have adopted some strategies which have proven helpful. 

Develop a process. Having a clear process in place for communicating and decision making on a deal is crucial. I have always been fortunate in that regard, as my clients are often very well organised and have a clear decision-making structure and protocol for escalating and resolving concerns that arise in the course of contracting. This may not always be the case though and could cause considerable confusion and “recycling” of issues internally.

Apart from the decision-making process, just having clear expectations about the basics, like who is going to document the issues and how they will be presented, can have an impact on how the team functions. In some cases, members of the team may be more readily accessible by Blackberry than otherwise, so distributing issues lists in a spreadsheet format may prove a barrier to those individuals who are forced to open them on a mobile device. A simpler format may serve better. On the other hand, tracking and documenting the evolution of certain issues from the beginning to the end of a lengthy negotiation is important, so choosing a form of issue log that is clear and rigorous at the beginning of the process can pay dividends later 

Define your role. When there are a number of people on the team, it is helpful to make sure everyone understands their role.. Often the lawyer’s role can include being the advocate for the most risk-adverse position, but it is just as important to have other individuals on the team who are willing to challenge that position to find a balance that is most commercially reasonable. It is also important to have at someone on the team who is prepared to advocate for the other party when preparing for negotiations, so that the other party’s positions can be anticipated and evaluated in advance of negotiations. 

Become accessible. You will probably need to be able to communicate in multiple media to convey your advice effectively. Instead of providing a standard memo, you might resort to spreadsheets, slide decks, charts, process diagrams, and white-boarding to get the point across. This may be simply because the client’s time is severely compressed, and so only an extremely concise email will do. Other clients revel in the detail, and will only be able to properly assess an issue once the full impact to the contract and the corresponding business case is made out. To make your message clear, you should be prepared to use whatever media will deliver what the client needs effectively. 

Solicit feedback. A contractual negotiation is a highly dynamic process, which requires constant feedback to control properly. It the midst of a complex negotiation, it can be difficult to take the time and evaluate what is working for you and your client, and what is not. However, this can be an important process, because it can make your communications with your client more efficient, and ultimately improve the experience for all involved. Feedback could be solicited informally or through a formal process – whatever is most suitable to the situation and the client. It is most important, in my experience, that it be done regularly and starting early in the process, so that adjustments can be made quickly before issues are amplified by the passage of time to unmanageable magnitudes. 

These strategies have helped me greatly in delivering client advice effectively, but I know that I will be constantly working on them. If you have any other strategies, please share them below, or contact me if you would like to discuss them. 

Cloud computing is a new and fascinating set of technologies that is changing the way the world does business. Is the legal profession ready for it?

Cloud computing is the generic term used to describe a variety of technologies that transfers the responsibility for a computing activity (storage or processing) from a local computer to a network of remote computers. The remote computers are generally operated by one or more third parties. The principal benefit of cloud computing is cost. By using the cloud, a business can reduce the amount of money it spends on procuring and maintaining its own IT infrastructure, and instead pay usage fees to the cloud provider based on the business's usage of computing resources. 

Cloud computing is an increasingly successful technology model, and will become quite prevalent in the coming years. Merrill Lynch sees the cloud business reaching $160 billion by 2011 (which is perhaps a bit optimistic, given the recent market troubles caused by the European credit crisis), and Gartner predicts $150 billion by 2013. Given that the cloud business was worth $50 billion in 2009, these numbers represent significant growth worldwide. Whether we are aware of it or not, much of our daily computing (email, banking, etc.) may move from dedicated servers to a cloud environment over the next few years. Google Docs, including Gmail email accounts, which are used by millions of businesses and people worldwide, are already hosted in Google's cloud. 

Lawyers could use cloud computing in a number of different ways, the simplest example being for document storage. Documents stored in the cloud could be accessible by lawyers and clients from anywhere, and could be selectively shared with other parties to facilitate negotiations or litigation. 

However, cloud computing has its drawbacks. The two biggest concerns are privacy and security, both of which warrant particular attention of lawyers. Using a cloud computing service entails in almost every instance a disclosure of personal or confidential information to a third party. The disclosure itself may be prohibited by privacy laws and the rules of professional conduct applicable in a lawyer's jurisdiction. 

A lawyer may only disclose a client's information to a third party under very limited circumstances. The standards for privacy and client confidentiality are different. Under federal privacy laws, a lawyer may disclose personal information of an individual to a third party so long as the lawyer obtains the individual's consent, and the third party is contractually bound to at least the minimum privacy standards as those promised by the lawyer to the individual, which are strict in the first place. 

The standard governing client confidentiality is similarly strict under the Rules of Professional Conduct that govern Ontario lawyers. The lawyer must keep information in strict confidence and not disclose it without the express or implied consent of the client. Implied consent may be presumed in some limited circumstances. For example, if a client communicates confidential information with a lawyer by email, the lawyer can reasonably infer that the client has consented to the lawyer responding in the same manner, even though the transmission of an email is demonstrably not secure. 

A lawyer cannot presume consent with cloud computing. Cloud computing is a new technology, the uses and vulnerabilities of which are still being explored. It would be completely unreasonable for a lawyer to infer consent for the use of document storage in a cloud, for example, unless the client had an extraordinary background in cloud computing. Even then, a lawyer may still be in breach of his or her obligation to keep a client's information in strict confidence because most cloud computing technologies cannot yet be considered secure. A lawyer should tread carefully here. 

The cloud computing community is well aware of the drawbacks of this emerging technology, and is working hard to address them. Before long, there will be ways to make the cloud secure enough for our client's confidential information. When that time is upon us, the cloud will be ready for the legal profession. 

Some resources on the topic:

Gellman, Robert. "Privacy in the Clouds: Risks to Privacy and Confidentiality from Cloud Computing" World Privacy Forum

Cohen, Reuven. "The Cloud Computing Opportunity by the Numbers" from the blog ElasticVapor