ezine

30 Aug 2010

In our first article, Estimations, Authority, Liability Caps and a Dog Called Lulu, we consider some further learnings that can be taken from the BSkyB v EDS case in the United Kingdom. We draw on the experience of that case to highlight how following some sound business practices can assist in minimising risk in pitching for business.

Putting together the technical schedules for an IT contract is a critical task for any IT contract but can often be a source of frustration for all involved. There are very few people who possess all of the required skills to fully develop the content, so the task is usually one which must be carried out by technical IT specialists and lawyers working together. Our second article, Contract schedules - where lawyers and technical specialists collide, seeks to provide some practical tips for technical IT specialists who take on the task of producing the first draft.

Controlling your brand's online social life has become increasingly difficult. Today you could find that your brand has web pages devoted to it on sites such as Facebook, MySpace, Twitter or Wikipedia, often without any input from you. Our final article, Managing Your Brand's Online Social Life, discusses what can you do to control your brand's online presence on social networking websites and wikis. What are these sites, how can you control them (if at all), and what can you do about inappropriate content and infringement of your rights?

---

Estimations, Authority, Liability Caps and a Dog Called Lulu

In June's x-tech article "Of Course We Can" we covered the BSkyB v EDS case in the United Kingdom. This month we draw on the experience of that case to highlight the importance of sound business practices and proper procedures during a tendering process. The case serves as a reminder that some of the most important ways to minimise risk in the tendering process may not necessarily be legal processes at all.

This article covers the following:

• a quick recap of the BSkyB case;
• the importance of proper estimates and calculations in tendering processes;
• why appropriate lines of authority in tender negotiations are important;
• some important considerations regarding liability caps; and
• some light humour from the judgment.

The BSkyB Case - Recap

The facts of the case were outlined in our previous article but there has been one subsequent development. When the judgment was released Ramsey J found in favour of BSkyB and granted £200 million in damages. However, on 7 June 2010, BSkyB and EDS agreed to a settlement sum of £318 million in full and final settlement of all claims in relation to this issue.

The legal community has now had several months to digest Ramsey J's judgment and, in addition to highlighting the legal issues covered in our previous article, we can take a number of practical, non-legal, learnings from the judgment.

Estimates and Calculations in a Tendering Process

One of the key issues in the case was that the estimate as to the time needed to complete the job given by EDS was woefully deficient. In fact, there was no proper time analysis conducted at all, and therefore, by stating that EDS could complete the job in time, EDS made a misrepresentation under UK law.

Tendering processes typically include representations as to the time and money needed to complete the work. The commercially appropriate position for both the issuer of and the respondent to a tender is to make sure that a proper analysis is made of each and every estimate as to time and cost in any pre-contractual negotiation. The first reason for this is that it limits potential legal exposure in terms of misrepresentation. The second reason is that if both parties investigate an estimate and find that it has been conducted to a reasonable standard, there will be less risk that this estimate will lead to cost or time "blow outs" down the line. This is obviously beneficial to both sides. Checking the estimates should include both "crunching the numbers" and reality checking the results.

Appropriate Line of Authority / Authority to Begin Work

Another key issue in the case was that authority to conduct negotiations was given to one particular employee of EDS, who was not suitable for the role (more on this later). While, to an extent, a business will occasionally need to rely entirely on an individual employee, it is important to establish a clear line of authority that places appropriate authority in trustworthy members of staff. In particular, parties should consider carefully who in their organisation has, or should be given, the authority to negotiate on behalf of, and legally bind, the company. For a contract valued at over £47 million, the expectation would be that there would be a number of "sign offs" from various levels before the contract was committed to. In the BSkyB v EDS case, the prime contract was signed by the CEO of BSkyB, but the negotiations were conducted (and the misrepresentations were made) by an employee at a lower level. This emphasises the prudence of ensuring that any significant representations made during major contractual negotiations have similar checks and balances to the signing of a contract.

This links to a second key issue in the case, which was that the work began some time before an agreement was put in place. This approach carries significant risk. While in some cases it may be impractical to wait until an agreement is finalised before work begins, it will always be a good idea to at least be in the final stages of negotiation before beginning work on a project, or to have an agreement dealing with the preliminary work that needs to be undertaken.

Liability Caps

An issue that has not gained significant attention is discussion of the liability cap in the agreement. The liability caps in any agreement will only be as effective as their terms allow. For example, a liability cap will often only cover certain types of damage, and will not cover others (eg an intellectual property indemnity is not typically limited by a liability cap).

One particular consideration in New Zealand is that the Fair Trading Act 1986 (Act) may allow parties to circumvent the liability cap under an agreement. The Act cannot be contracted out of. Therefore, even if a liability cap is stated to apply to misrepresentations that would otherwise be covered by the Act, the liability cap may not be fully effective. This reinforces the importance of complying with the obligations of the Act, notwithstanding a liability cap in an agreement.

A further consideration is that liability caps will not necessarily apply to all of the parties to a transaction. For example, occasionally the parent company of the service provider will be required to guarantee that the service provider will perform its obligations under the agreement. The wording of a liability cap and guarantee will need to be carefully drafted to either include or exclude the parent company from the liability cap, depending on the parties' (and the guarantor's) intention.

A Little Legal Humour

In our previous article, we did not mention one of the more entertaining aspects of Ramsey J's judgment. The high level EDS employee that made the misrepresentation as to time was a man named Joe Galloway. Galloway made several estimates as to time and cost, resulting eventually in BSkyB accepting EDS' tender. However, unfortunately, EDS did not pay particularly close attention to Galloway's qualifications.

During the trial, the lawyers for BSkyB cross-examined Galloway, questioning him on his MBA. He stated that he received his MBA from Concordia College and University in the US Virgin Islands after attending classes for approximately a year. However, the website for Concordia College states:

"You may have done past courses and other learning which equals an Associate Bachelor or Master degree but you accumulated that learning in a variety of contexts with no resulting degree outcome. Meeting your needs, Concordia College's on-line prior learning assessment process may conclude with an accredited degree in 24 hours, in the subject of your prior studies. Your transcripts then credibly document all of your learning."

So, as it turns out, Concordia College is a website that provides on-line degrees. The website does not require any verified academic information, and awards degrees based simply on paying a fee. To demonstrate this, Mark Howard QC, one of BSkyB's lawyers, managed to obtain an MBA degree for his dog Lulu. In fact, Lulu gained significantly better grades than Galloway did. As Galloway had spent a considerable amount of time on the stand misrepresenting his qualifications, and there was clear evidence that he had tried to cover up events that had occurred in 2000 and 2001, the Court effectively ruled out Galloway's evidence. EDS had dismissed Galloway from its employment in 2006, before the trial, but it appears that the revelations about EDS' star witness came as quite a surprise during the trial.

While this is an extremely unusual example of academic fraud, it does show why it is important to check employees' backgrounds. Needless to say, the EDS case may have turned out significantly differently if the negotiations had been conducted by a more experienced employee.

Key Contacts

Karen Ngan
Sam Abbott

Back to top

---

Contract Schedules - Where Lawyers and Technical Specialists Collide

Putting together the technical schedules for an IT contract requires both technical IT skills (to define what is actually required) and legal skills (to make sure the contract is enforceable). There are very few people who possess all of the required skills to fully develop the content, so the task is usually one which must be carried out by technical IT specialists (IT Specialists) and lawyers working together.

IT Specialists live in the world of emerging technology and new and complex concepts, while lawyers live in the world of dry contracts and fears about enforceability, so each bring a different perspective.

In a perfect world, the IT Specialist would simply brief a lawyer, who would then carry out the task of drafting the schedules. Thus the IT Specialist would be introducing their skills into the equation by briefing on the technical aspects of the desired product, while the lawyer would be doing what lawyers do best, and drafting a contractually enforceable document. However, the volume of technical detail usually makes it more practical for the IT Specialist to take the time to write out what is required, than to try to explain it in detail to a lawyer in a meeting.

The result is that technical schedules are usually drafted, in the first instance, by people who are not expert in drafting a legally binding document, and a lawyer is then engaged to provide a legal sign-off.

This article seeks to bridge the gap between IT Specialists who hold the pen on technical schedules and their legal advisers. It aims to explain in simple terms what lawyers are looking for, and why.

The characteristics of a good technical schedule

For a technical schedule to fully serve its purpose it must:

1. be sufficiently wide in scope to capture everything that must be delivered; and
2. contain obligations that are easily enforceable.

Lawyers will, by necessity, rely heavily on the IT Specialist in relation to scope. They will often seek assurances from the IT Specialist that everything that needs to be delivered is described, but will be unable to independently assess whether that is the case.

Consequently, a legal review will focus heavily on the issue of enforceability.

What makes enforcement difficult?

In assessing whether or not obligations are easily enforceable, a lawyer will usually be concerned about two key things:

1. Are the obligations ambiguous?
2. Are there any agreements to agree?

This article considers each of these concerns in turn, including providing some guidance for drafting.

Ambiguous obligations

Why ambiguity is a problem

Obligations that are ambiguous are difficult and sometimes impossible to enforce. If an obligation does not have a clear meaning, it is much harder to convince a reluctant party to perform it. That reluctant party will be able to argue that they had always intended and believed that the obligation was something different.

The fact that an obligation is ambiguous on its face does not necessarily mean it is unenforceable. A court may determine its meaning by looking at surrounding context. However, it does introduce an element of uncertainty. A party seeking to enforce faces the risk that a court will hold that there was no meeting of minds between the parties, and that the obligation is therefore not contractually binding. The court may even hold an alternative interpretation being advanced by the other party to be the correct one. This uncertainty may lead the party seeking to enforce to instead accept a settlement far less favourable to it than it would have been able to negotiate if the obligation had been more precisely drafted.

How to avoid ambiguous drafting

As a matter of logic, everybody knows that ambiguity is a bad thing in a contract, but avoiding it, or even becoming aware of it, is not so easy. To do so, we suggest the following approach is adopted:

1. Make sure that avoiding ambiguity is one of your principal objectives when you start drafting.
2. As you draft, only use active language.
3. As you draft, only use capitalised terms for proper nouns.
4. When you have finished drafting, review each obligation by asking yourself whether, if told to perform the obligation, you would have any questions to ask before knowing what was required.

The first of these needs no further explanation, but we have expanded on the others below.

Using active language

Passive language is a common feature of draft technical schedules, and a common source of ambiguity. The problem with passive language is that it creates ambiguity about who must perform the obligation.

For example, a schedule may say that:

"The System will be tested before it is used in the production environment to ensure that it is working in accordance with the Specifications."

A person drafting such a statement may simply assume that it is obvious that the service provider will carry out the testing. However, the words do not say that, and it is quite possible that a service provider may subsequently argue that they thought it was the customer's responsibility, or something that both parties would devote resources to.

This argument would not be had if the obligation was instead drafted as:

"The Service Provider must test the System before it is used in the production environment to ensure that it is working in accordance with the Specifications."

Obviously examples like this vary in their seriousness, depending on how clear it is from the surrounding context who is responsible, and in some situations the risk of an argument may be very low. However, by using active language, the person drafting can avoid having any argument at all.

Only use capitalised terms for proper nouns

The misuse of capitalised terms in technical schedules is another common and avoidable source of ambiguity.

The rule which should always be applied is that only proper nouns should be capitalised. “Wellington”, for example, can legitimately be capitalised, as can “Windows 7”. Terms which are defined in the document can also be legitimately capitalised, as the document has effectively made them proper nouns for the purposes of the document.

The reason that this is important is that, if a term is capitalised, but is not a proper noun, it makes its meaning ambiguous. On the one hand it could be read as if it had not been capitalised and just bore its ordinary meaning, but on the other hand, the person drafting has communicated by capitalising that they perhaps have a different meaning in mind.

Take the following example clause:

[Party X] must ensure that all Software supplied by it is free of any viruses.

If the term "Software" was not capitalised, the meaning would be clear. It would be that if any software comes from Party X, it must contain no viruses. However, the capitalisation of the term raises the question of whether “Software” is perhaps intended to be narrower than “software”. Is it limited, for example, to software developed by Party X, excluding any software developed by a third party and sourced by Party X? Is it limited to some specific software referred to in the previous paragraph?

This sort of capitalisation is all too common, and raises a question when none needs to be raised. If the drafter does not intend any special meaning, the term should not be capitalised. Conversely, if the drafter does intend a special meaning, the lack of definition means that special meaning is potentially lost, and there is a high risk that the clause will simply be read as if there was no capitalisation.

The key message is, if you feel the urge to capitalise a word which is not a proper noun, you should always consider why you have that urge. Could you, in fact, leave it in lower case and achieve the desired effect, or have you identified the need for a definition?

Reviewing by asking questions

Having finished the drafting, it is important to review the obligations in the document to check that they leave no questions unanswered. If there are outstanding questions, then the obligation is ambiguous. For example:

Is it clear who must perform the obligation?
When must they perform it?
How often must they perform it?
To what standard?
And so on…

If these steps are followed, the product is likely to be a far less ambiguous document, and the disconnect between IT Specialists and lawyers substantially reduced.

Agreements to agree

An "agreement to agree" is any express or implicit requirement that the parties agree something. An example of an express requirement would be a clause like the following:

The parties must agree the acceptance tests by 1 December 2010.

This expressly places an obligation on each party to agree something.

In contrast, an example of an implicit requirement would be:

The parties will assess the particular defect and the Service Provider will rectify it within a time frame that the parties agree is reasonable having regard to its seriousness.

This obligation contains an implicit requirement that the parties agree a time frame for rectification.

In both cases, the agreement to agree presents a potential problem. This is that, if they do not agree, there is nothing either party can do. A party cannot be contractually forced to agree something.

Consequently, in the examples, acceptance testing may never happen, and the obligation on the Service Provider to rectify may never arise.

Drafting to avoid problems caused by agreements to agree

Drafting to avoid problems from agreements to agree is a two stage process. First the drafter must identify each agreement to agree, and then they must decide whether that agreement to agree is a problem which requires further drafting to resolve.

Once a drafter is aware that agreements to agree are a problem, the first stage is relatively easy. The steps we suggest for identifying agreements to agree are as follows:

1. Look for any use of the word "agree". In many cases, the use of this word will mean that there is an agreement to agree.
2. Look for any reference to an obligation being contained in a document which is not yet agreed. This implicitly makes the obligation contingent on that second document being agreed.
3. Look for any obligation which the parties are to perform together. This will often unavoidably involve a requirement that they agree something. For example, if "the parties must develop a transition plan together", there is an agreement to agree that transition plan.

The second stage (deciding whether the agreement to agree is a problem) involves a little more judgement. We suggest that an agreement to agree will usually be a problem unless it falls into one of two exceptions:

Exception 1 - there is some objective way of resolving the failure to agree if it occurs. For example, a schedule might provide that if a change to the services is agreed the price will be adjusted by an amount agreed between the parties, or failing any agreement being reached, by an amount specified by a pre-agreed benchmarker.

Exception 2 - both parties have sufficient incentive to agree to mean that agreement will not be withheld to defeat the contract.

Exception 2 is not as free from issues as exception 1, because there is still a risk that circumstances may change, or that a party may "game" the requirement that they agree because the other party needs the agreement more than they do. However, the stronger the incentives each party has to agree, the less an agreement to agree which falls within exception 2 will be a problem. Two situations in particular in which agreements to agree within exception 2 are accepted for practical reasons are the following:

1. The obligation which requires the agreement to agree is of relatively low importance. For example, an agreement to meet once a month on a day to be agreed between the parties is not generally viewed as a problem. Both parties will have an incentive to find a mutually acceptable date simply because they have little to gain from not doing so, and it improves the relationship if they do do so.
2. The obligation which requires the agreement to agree is one which both parties want performed. For example, an agreement to build a system based on an agreed design is not usually a problem. The service provider will want to be able to build the system (to be remunerated for doing so) and the customer will want to have the system built (so that it can use it). Both are, therefore, incentivised to agree a design.

If an IT Specialist goes through this two stage process, the draft which will be produced will only include agreements to agree for which there is a sound justification. Once again, this is likely to significantly reduce the disconnect between lawyers and IT Specialists.

Key Contacts

Don Holborow
Adam Jackson

Back to top

---

Managing Your Brand's Online Social Life

Controlling your brand's online social life has become increasingly difficult. Today you could find that your brand has web pages devoted to it on sites such as Facebook, MySpace, Twitter or Wikipedia, often without any input from you. What are these sites, how can you control them (if at all), and what can you do about inappropriate content and infringement of your rights?

Wikis and Wikipedia

A wiki is a website which allows contributors to create and modify a network of linked webpages. The most well known wiki is Wikipedia, an online encyclopaedia-style website to which anyone can anonymously contribute and edit content. While this results in a massive amount of publically available information, it is not always correct or sufficiently verified. Some businesses have found that contributors have posted false or misleading information about their brands.

Twitter

Twitter is a social networking site where users post 140 character messages or "micro-blogs". If you opt to "follow" another user, you are alerted to new messages posted by that user. Many brand owners use Twitter to engage with their customers, posting information about special offers and business developments, and seeking feedback.

There have been instances of brand squatting on Twitter, where an unrelated entity uses your brand in a way which misleads or confuses other users. For example, you may find that someone else has been holding itself out as the owner of your brand.

MySpace and Facebook Pages ("official" pages)

You can create "official" MySpace and Facebook Pages for your business or brands which are visible to everyone on the internet by default. You control the content as only you (being the authorised representative for your business) can administer the pages.

MySpace and Facebook users connect with these official pages by becoming fans and receiving updates. They can contribute content in a sense, by posting comments.

Facebook Groups

While Facebook Pages are official pages for brands or businesses, Facebook Groups are for users to share common interests and communicate as a group. Facebook Groups now include many "unofficial" fan sites for brands which have been set up by Facebook users, and over which the brand owners have no control.

Facebook Community Pages

A Community Page is a kind of wiki-style page created by Facebook about a topic, issue or brand. You may find that your brand suddenly has a Community Page without any input from you. Facebook automatically generates content for the page based on information retrieved from Wikipedia and Facebook users' profiles and public wall posts. At present it is not possible to comment on, or contribute to, Community Pages. Apparently Facebook intends to allow certain users to add content in the future.

What should I be doing?

The most frustrating thing for brand owners about social networking sites and wikis is the lack of control they have over content relating to their own brands. The key to managing this is to regularly monitor your brand's online business presence and act accordingly.

Wiki content can often be edited in a matter of seconds, so it's a good idea to know how to do this, and to visit Wikipedia and other wikis relevant to your business or brands often.

Monitoring any "official" pages your business has (such as Facebook Pages) should also be a regular event. Think carefully before responding to, or removing, any user comments (particularly complaints) and consider having an internal policy around this. Bear in mind that some pages such as Facebook Community Pages do not allow commenting.

For instances of intellectual property infringement or genuine abuse, social networking sites have policies you can turn to. For example, both Twitter and Facebook have useful intellectual property infringement reporting systems. You simply provide the required information electronically, and should find that your complaint is dealt with quickly and in a solution-focused way. As part of their terms and conditions of use, social networking sites can remove content, take down pages, and will in some cases terminate user accounts.

Key Contacts

Earl Gray
Richard Watts
Claire Foggo

Back to top