CIO

10 tips for protecting your legal rights when a project goes pear-shaped

Practical measures CIOs should take when an IT project first gets into trouble to preserve their organisations' rights when a project goes seriously wrong.

As reported in <I>CIO</I> online in June, the latest CHAOS Summary report from The Standish Group has shown an increase in IT project failure rates during the past two years. According to the report, less than a third of IT projects in that period were considered successful. The rest were either considered to be failures or “challenged” -- they finished late, over budget or with less than contracted specification. This reverses the previous trend of more projects being regarded as successful each year.

You want a working IT system, not a lawsuit, and your supplier wants a happy (and paying) customer, not its name splashed on the front page of the business papers

A number of reasons could be speculated for this, and the GFC could be playing a part. In particular, customers with very constrained IT budgets are now more likely to call a halt on a project which they perceive as unlikely to be successful, rather than persevering or resigning themselves to accepting a substandard result.

When a project does fail, the parties will usually consider what their legal options will be as a result of the failure. In our experience, customers often find that their rights at this stage are not as strong as they should be, due to mistakes they made in the course of the project. This often leads to the customer not getting the settlement they deserve.

There are some practical measures that can be taken when an IT project first gets into trouble, in order to preserve the customer's legal rights if the project does go seriously awry. Of course, it is always necessary to temper the measures taken to protect legal rights with the practical realities of trying to run an IT project through to successful completion. You want a working IT system, not a lawsuit, and your supplier wants a happy (and paying) customer, not its name splashed on the front page of the business papers as the guilty party behind another IT debacle. At times the desire to complete the project successfully may mean that it is not practical to take some of the steps below. However, the aim should be to ensure that the legal rights are identified and waived in full knowledge of the consequences, rather than simply being lost inadvertently.

1. Don't terminate the contract in haste

When a project is in trouble, a common reaction is simply to 'can the whole thing' and terminate the contract. To avoid a big problem getting even bigger, you need to pause before taking such a course. It is possible that the current problems with the project are just a hiccup and with a bit more time and possibly a change in a few key people, the project is able to get back on track. Even where this rose-coloured view is not justified, you still need to check that you do in fact have the right to terminate the contract at that time. If you terminate the contract without having the right to do so then you will be found to have breached the contract, and be liable to the supplier for the consequences. Suddenly you will find that you have shifted all the legal leverage from your side of the table across to the supplier.

Unfortunately, it is not always straightforward to determine whether you do have the right to terminate the contract. If you are terminating under a termination clause in the contract then you need to ensure that you fit within the literal terms of the clause and that you are exercising your rights under that clause for the purposes for which they were granted. If you are terminating outside the contract terms, at common law, then the task is even more difficult. Under current High Court authority, you need to analyse both the clause very carefully and also ensure that the breach is sufficiently serious to justify terminating under that clause. This can often be a very tricky exercise, and getting it wrong will be very expensive.

2. Exercise any termination rights that do arise promptly, or accept that they have been lost forever

Once a termination right has arisen under a contract, you need to exercise it quickly. At law, a termination right will be lost if the innocent party takes some action that is inconsistent with the exercise of that right. In consequence, if you let the contract stagger on for a while after a termination event has arisen then you are likely to have lost forever the right to terminate for that event.

It can often be tricky reconciling this tip with the previous tip. Ultimately it comes down to having good decision-making processes in place so that when a termination right does arise, the customer is able to decide quickly whether to exercise it or accept that it has been lost forever.

Page Break

3. Be careful about creating and destroying documents

One part of any IT court case is showing the other side all relevant documents in your possession, including any documents that harm your case. Knowing this, there is a natural human tendency to try to destroy harmful documents when a project does get into trouble. That temptation needs to be resisted at all costs. In these days of electronic documents and automatic back-ups, it will be nearly impossible to ensure that all copies of the document have been destroyed, and the attempt to destroy the documents will definitely be held against you in court. In some circumstances the destruction of documents which are relevant to court proceedings can even be a criminal offence. As much as you love your company, do you really want to go to jail for it?

The question of destroying an embarrassing document will not arise if that document had not been created in the first place. Once a project seems to be on the skids, everyone involved with the project should be warned about the absolute imperative of not putting in writing (including email) anything that could prove embarrassing to the customer if disclosed to the supplier in subsequent court proceedings.

4. Obtain privilege and be aware of its limitations

Documents that are 'privileged' do not need to be disclosed in court. In IT disputes, the two types of privilege which are most likely to be relevant are 'without prejudice' privilege and the 'client legal' privilege. The 'without prejudice' privilege prevents offers of settlement being used to prove liability. It is a very powerful tool when used properly. However, it is not an unlimited privilege and there are a number of important exceptions. The most important exception is that factual concessions made without prejudice (eg that particular service levels were being met) can later be used against the party making them.

Client legal privilege prevents communications between a client and its lawyers being disclosed. It also prevents disclosure of any communications with third parties (such as witnesses) which are made for the purposes of litigation. Although the tests for obtaining this privilege vary, it is better to assume that the privilege will only be available for material which has been prepared for the 'sole purpose' of obtaining or giving legal advice. The privilege is available to advice given by a company's internal lawyers; however, care needs to be taken to ensure that the internal lawyer is acting in their capacity as a lawyer when giving the advice, rather than crossing over into a business capacity. To assist in proving this, it can be useful for the lawyer to mark relevant emails and other correspondence as being 'subject to legal privilege'.

5. Maintain client legal privilege once obtained

Client legal privilege can be lost if the relevant material is treated improperly. Since the purpose of legal privilege is to protect confidential legal communications, it is important that copies of the advice are not circulated more broadly within a company than necessary.

There is a particularly nasty trap for anyone who refers to their legal advice in discussions with the other side. Under the doctrine of 'implied waiver of privilege', a party who voluntarily waives privilege in certain legal advice is deemed to have also waived privilege in any other advice that is reasonably necessary to enable a proper understanding of the advice which was referred to. A party that is proposing to tell the other side anything about the legal advice they have received needs to consider what they say very carefully and ensure that they are not waiving privilege in more than they intended. Something as simple as 'we have received legal advice that we have a strong case against you' could mean that all existing legal advice received will be liable to disclosure to the other party in court.

Page Break

6. Create the right documents

It is important to keep detailed notes of key meetings, concentrating particular on any representations made in the course of the meeting, action points agreed and, most importantly, who has responsibility for those actions. All too often the minutes of a meeting record nothing more than the subject headings of what was discussed without going into the detail of who precisely agreed to do what. Such records will be of much less use when you are later trying to establish non-compliance with them.

There are a number of fairly standard types of damages in IT litigation. These include the costs of fixing a defective system/arranging for someone else to provide the relevant services, the sums that have been paid to the supplier, the time that was spent by the customer as a result of the supplier's failure to perform, and loss of profits and savings. Some of the records needed to substantiate the damages claim will not be able to be created until after the contract has been breached and litigation is in prospect. However, others need to be created on an ongoing basis if the relevant charges are to be recovered subsequently. In many of the reported cases on IT litigation, the court decided against awarding a particular head of damages on the basis that there was simply no evidence before the court to support the award.

Particular care should be taken to record the time taken by internal staff in dealing with the dispute. If the internal time can be shown to have caused a loss to the innocent party then it is likely to be recoverable. However, it can only be recovered if there are adequate records of what time was in fact spent and how. Timesheets and other records accordingly need to be created as the project is performed. Similarly, a typical head of damage sought by customers is that, due to the supplier's breach, the customer was not able to take advantage of other profit-making opportunities that were available to it. Again, damages will be awarded under this head, provided that there is evidence of these lost opportunities. All too often, however, the court is faced with no more than a vague assertion that because time was spent on the project or on managing the dispute, there must have been opportunities which were lost. If the evidence gets no higher than this then a court will not award this type of damage.

7. Manage the project in accordance with the contract

Everyone knows that good management is key to a project's success. Part of good management is to follow the processes and methodology prescribed by the supply contract. This is particularly important for matters such as documenting changes in scope (and price), changes to the project plan and changes in project structure (number of drops and phases etc). If the project has not been managed consistently with the contract then it will be much more difficult to complain about the supplier breaching the contract when the project is off the rails.

If you are halfway through a project and then find that the factual situation bears no resemblance to what had been contemplated in the contract, or the scope change process mandated by the contract is hopelessly complicated and therefore never used, then that is the time to work out why the reality has departed from what the parties had agreed when the contract was signed and decide whether the contract should be amended to align with the reality (or vice versa). It almost goes without saying that it will be much easier to obtain agreement on any necessary changes if these are being sought when there is still goodwill between the parties, rather than after hostile letters start being exchanged.

8. Enforce protective rights under the contract as the project proceeds

Most contracts contain provisions that are intended to provide practical protection for the customer against a project being cancelled. These provisions include clauses requiring the source code for the relevant software to be put into escrow as a project is conducted, provisions allowing the customer to check what has gone into escrow is in fact the developed code (as opposed to being a blank DVD!), requirements on the supplier to take out relevant insurances and to provide evidence that it has done so, and rights for the customer to inspect the supplier's conduct of the project and ensure that it is complying with the contractual provisions.

It will generally be futile to try to exercise such rights at a time when the project is in trouble. By that time the supplier may well have taken the view that it is likely to end up in court over the project in any event, and so it has little incentive to comply with requests that are just going to make its own position worse. In these GFC days, there is also always a risk that a supplier who is having trouble completing a project might also be about to become insolvent. There will be no point in suing an insolvent supplier for breach of contract and it will be very difficult as a practical matter at that time to compel the supplier to comply with obligations, such as the requirement to take out insurance. If these types of provisions are important to you – and they should not be included in the contract unless they are – then you should monitor the supplier's compliance with them as the project proceeds so that you will have practical recourse in the event that the contract does ultimately have to be cancelled and legal proceedings commenced.

Page Break

9. Mitigate your loss

A fundamental principle of contract law is that an innocent party must minimise the loss which it suffers as a result of the guilty party's breach of contract. The duty arises from the time that the breach occurs. From that time, the innocent party needs to be alert to opportunities to minimise its loss. The duty is not an absolute one – the law only requires that the innocent party take 'reasonable steps' to minimise its losses. However, if there were reasonable steps open to the innocent party and those steps were not taken then there will be a reduction in its award of damages.

This principle can even require a customer to accept a less satisfactory system than the one specified in the contract. For example, if the original supplier announces that it is unable to provide the original system but it is able to supply a substitute system, with marginally less functionality, then the customer may be required to accept the other system. The customer will, of course, be entitled to be compensated for the difference in value between the two systems.

10. Use litigation strategically

All litigation is expensive and risky. However, IT disputes are notoriously difficult and expensive to litigate. The IT court cases often show that the judge clearly felt that the expense of litigating the dispute bore no proportion to the inherent value of the litigation.

Just as with any other significant business activity, litigation should not be commenced without determining that there is a business case for doing so. At a time when emotions are running high as a result of an important IT project going awry, it is very easy for a customer to focus on making the supplier suffer, rather than calmly assessing just what its prospects are and the amount of damages that are likely to be recovered.

The evaluation of the likely outcome needs to take account of the different bases on which damages will be awarded for the different causes of action. In general, IT litigation will involve three distinct causes of action:

  • breach of contract (typically for failure to comply with performance warranties and the project plan);

  • contravention of the Trade Practices Act (typically for misrepresentations of performance or functionality contrary to section 52); and

  • negligence (for deficient performance of services).

If the customer is successful in the action for breach of contract then it is entitled to be awarded whatever compensation is necessary to put it in the position that it would have been in had the contract been performed correctly. By contrast, the actions for contravention of the TPA and negligence are designed to put the plaintiff in the position that they would have been in had the relevant misrepresentation/negligent conduct never occurred. This might result in a significantly smaller award than would the action for breach of contract.

Having evaluated the strength of the case for each of the available causes of action, and the damages that are likely to be able to be proven with respect to each cause of action, the customer will be in a better position to assess the likely benefit to be obtained from embarking on the litigation. There may well be times where, no matter how hard it is to stomach, it is in the customer's best interest simply to walk away from the failed project rather than devote time and money to suing the supplier.


Michael Pattison is a partner in the Communications, Media and Technology Group at Australian law firm Allens Arthur Robinson.