Since the very first IT project went wrong, reams of paper and acres of electronic ink have been devoted to coming up with ways of setting up the perfect contract and initiating and running a trouble free project. Fashions for different contracting models and methodologies come and go but the one constant is that a proportion of projects still end up in difficulties.
Given that it is inherently difficult to specify an IT system to a level of detail that would prevent arguments over requirements and specifications, it is perhaps surprising that so many projects make it to completion. IT suppliers are often criticised for not accurately estimating the cost of projects so it is worth noting that the construction industry, often held up as an industry that IT should emulate, has its own share of project failures. In fact, one study of infrastructure projects suggested that 9 out of 10 projects were underestimated and actual costs run on average 28% higher than estimated.[1]
While a good contract and proper programme management are clearly essential, what really makes the difference in ensuring that a project is successful is what the parties do when the inevitable problems or unknowns arise: do they sort them out in a sensible fashion that works for both sides or throw in the towel?
Common problems in IT projects
Typically, a customer will start to think seriously about the future of a project when problems arise, for example, when a key deliverable is late by a significant margin or the deliverable is of poor quality. From a supplier’s point of view, alarm bells will start to ring if what they see as acceptable deliverables are rejected or the customer’s team request significant changes to an agreed plan or deliverable. It is also quite common for there to be underlying issues or changes that have little to do with the actual delivery of the project but nevertheless have a significant impact on the commercial landscape and the relationships between the parties. These can include:
· change of strategy by customer – outsourcing or insourcing
· customer or supplier acquisition/merger
· changes to supplier strategy, such as a decision to stop doing some kinds of project
· third-party failure or acquisition/merger
· major market or regulation changes which require a change of approach.
What to do when a problem arises
Whatever the back story is, once a major contract reset is on the horizon one of the biggest challenges facing a Business Sponsor is understanding exactly what the state of play is and the options for moving forward. This task is often made more difficult by the myths that have grown up around the project. Often both customer and supplier staff will have their own views about what has gone wrong and why. While they may be right in a broad sense, it is not unusual for their views to be based on ignorance of the contract that has been signed. Examples of real life misconceptions include “It is a time and materials contract so the deadlines do not matter” when the contract includes a cap and formal milestones, or “the 50 reports we want are included in the contract because it says there must be a reporting facility”.
The project team’s reading of the situation may also be coloured by their own world view. Supplier staff often believe that the customer’s business staff are resisting the implementation of a new system and view this as a symptom of either ignorance or intransigence. From the other side of the fence, customer staff often see the supplier’s team as lacking in detailed business knowledge and accuse them of trying to force through decisions that will result in an unworkable system. Both customer and supplier may find it convenient to blame third parties for the difficulties they are having, particularly if those parties are off-shore or otherwise removed from day-to-day project activities.
The Business Sponsor needs to cut through these myths and get a clear understanding of the status of the project from a legal and technical position, before deciding on their next steps.
Technical Issues
The technical issues are easily summed up. Typically the Business Sponsor will want to know:
· how far has the project got?
· can this supplier complete/finish it and how long will it take?
· what needs to change in customer/supplier to allow the project to complete?
· will scope have to be reduced to fit the timescales?
· is the system/design capable of being taken forward by anyone?
· what is the financial impact of each of the options available?
Clearly these are questions that can sometimes be answered by the customer’s existing project team, but it is important to be aware of internal agendas. For example, the project may be replacing an incumbent in-house developed system, whose developers feel threatened by the new system. Bringing in a third-party consultancy can be helpful, as long as the Business Sponsor is clear about the remit and the third party is preferably not going to be asked to complete the project, since this clearly gives them an interest in being critical of the supplier.
The most important outcome of any technical review is to understand what needs to change for the project to become successful. Typically this will mean that either the scope must be reduced or the deadlines extended and both parties will need to change the way they have been running the project.
Legal Issues
The answers to the technical questions posed above need to be viewed in the light of the contractual framework. For example, it may be clear that the project is six months late but much less clear whose fault that is and whether the supplier can be forced to complete the project for no additional cost or the customer should pay for changes that have caused delay. It is therefore vital that the parties understand their rights and obligations under the contract and that any technical review is undertaken with the contractual framework in mind. The key legal questions that need to be answered are:
· what exactly are the parties’ contractual obligations?
· how should change and delay have been dealt with and what has in fact happened?
· who owns the work product so far and can the client use it with an alternative supplier?
· what are the options for termination if it proves impossible to reset the contract?
Contractual framework
IT projects are often extremely complex, and the full contractual framework typically includes proposals, requirements, specifications, software licences, subcontracts, service level agreements and other technical documents. It is common to have inconsistencies between documents or to have gaps in the documentation.
While a well written contract will typically include an order of precedence and an entire agreements clause preventing the parties from relying on anything that falls outside the contract, the development of technical documents over time, and the application of change notes, often means that the first job for a lawyer is to establish exactly what the contract consists of.
Change and Delay
IT projects almost invariably involve some element of change, both to the technical solution and the contractual arrangements. Most contracts include a Change Control Procedure setting out the process by which a change can be implemented so that the parameters of any change are clearly set out against the baseline and agreed between the parties to amount to a variation of the contract.
However, the parties may not have used the formal procedure or may have adopted different mechanisms for change. Since it is still possible for a contract to be varied in writing, orally or by conduct,[2] the question of whether a variation is valid can be far more complicated than anticipated, even where the contract is clear. It is therefore necessary to look not only at any formal variations or Change Control Notices that have been implemented, but also the parties’ conduct throughout the project to determine whether there has been an effective variation that may affect the legal position.
A lack of formality over change is often seen in the parties’ approach to delay. If the contract does not state that time is of the essence then delay will not amount to a condition of the contract, and a mere obligation on the supplier to complete something by a particular time does not necessarily make time of the essence. Where the contract does provide deadlines, the parties may have agreed to postpone these deadlines as a variation of the contract through their conduct, even if there is no reference to milestone changes in the Change Control Notices.
If there is any delay which is causing problems for the Business Sponsor, it is important to consider whether the contract provides for any remedies in the case of delay or if it sets out a process to be followed in the event of delay. If the contract is silent on the issue of delay and time is not of the essence, the general rule will apply whereby the obligation is to perform the task within a reasonable time.
A Business Sponsor should carefully consider the causes of the delay and whether responsibility can be placed on one party only or whether both parties are responsible. If both parties are responsible, it is less likely that the Business Sponsor will have the option to terminate the contract or seek damages caused as a result of the delay.
Ownership
One vital consideration when assessing the options available to a Business Sponsor when problems arise in a contract is who owns the intellectual property rights (IPRs), such as the copyright in the underlying code of any software, documents or databases that are created during the project. If the customer does not own the IPR created under the contracts, this could prevent another supplier from being able to access or use the code to continue working on the deliverable. The questions that a Business Sponsor should ask are:
· how is IPR classified in the contract?
· what does the contract say about who owns different types of IPR?
· what does the contract say about restrictions on third parties accessing IPR?
· what third-party IPR is being provided as part of the project and on what terms?
· what does this mean on early exit?
· what strategic implications does the IPR position cause?
· what other issues might there be?
Under English law, the general rule in the absence of any contractual provision to the contrary is that the supplier, as author of the code, owns the copyright in any materials, such as software, documents or websites it has created for the customer, regardless of the fact that the Business Sponsor is paying for it.
If the contract provides for the IPR to vest in the customer upon creation, or for an irrevocable and perpetual licence to be granted upon creation, then this gives the customer the right to use the IPR on termination of the contract. However, there may be conditions on any licence granted. For example, the clause may allow the supplier to revoke the licence up until (a) payment of the milestone under which the work was done, or (b) payment of all fees due under the contract. Similar restrictions where the customer is to own the IPR, so that the transfer of ownership only takes place on payment, are also common. The supplier will have additional leverage in any exit negotiations if the customer does not at least have the right to freely use and allow other suppliers to use such IPR on early exit.
One final point on IPR is that developers are often blissfully unaware of the significance of IPR and the technical reality may be much more complex than envisaged in the contract, leading to significant difficulties for both parties.
Termination Options
If the Business Sponsor is ready to throw in the towel then it is critical that the options for termination are explored and understood before any precipitate action is taken. As part of the legal analysis, the contractual Dispute Resolution Process, if one exists, should be considered and followed if at all possible. Such provisions can be extremely helpful as they provide transparency in relation to the process if a dispute does arise, including a clear timeline, to help encourage the parties to resolve the dispute quickly and cheaply. They also help address the issue of who makes the first move.
Termination for convenience
If there has been no material breach by the supplier but the Business Sponsor is nonetheless keen to exit the contract, it should consider whether the contract allows for termination without cause, or termination for convenience.
Such a clause essentially gives the customer the right to terminate in the absence of any breach by the supplier on notice. The customer may be required to pay for such a right by way of a ‘termination payment’ to the supplier that enables the supplier to make up the costs of any up-front investment or loss of profit. This may be stated as a fixed sum or a calculation as to how the amount is calculated may be set out; there are often ambiguities in the potential cost of termination that need to be understood.
The contract will also usually provide for any outstanding invoices to become payable immediately. In a long-term contract, this is often an expensive route which can be unpalatable in circumstances where the supplier is underperforming, although not clearly in repudiatory or material breach.
Termination for breach
Contracts will usually make provision for a party to terminate the contract in response to a material breach. Unless expressly excluded in the contract, the parties will also have a right to terminate a contract for breach under common law.
The contract should ideally set out what amounts to a material breach but, if it does not, this will be open to interpretation and dependent on the facts, including:
· the terms and duration of the agreement
· the nature of the breach
· the consequences of the breach.[3]
The courts have interpreted a ‘material’ breach as “a breach of contract which is more than trivial, but need not be repudiatory”.[4] A repudiatory breach is a breach that is central to the performance of the contract which, if not performed, would deprive the other party of the whole or substantially the whole of the benefit of the contract. As the bar is set higher for repudiatory breach, it is usually easier for a party to rely on a contractual termination for breach clause than the common law.
Most contracts would require the innocent party to serve a notice setting out the breach, and giving a period of time for it to be remedied. Such notices must be strictly complied with.
Partial termination
If the Business Sponsor is dissatisfied with part of the contract only then it may be worth considering whether the services being provided are capable of separation. The contract may allow for partial termination of the contract or the parties may be able to vary the contract by agreement.
A notice of partial termination needs to set out exactly what services have been terminated and deal with any consequential changes, such as payment provisions, changes to the supplier’s team and cooperation between the supplier and any third party.
What Happens Next?
Regardless of the method of ending the contract, the Business Sponsor needs to consider what will happen after termination. For example, what will happen to any equipment or other physical assets on termination and will the assistance of the original supplier be needed to allow a smooth transition to a new supplier.
Any transition mechanisms set out in the contract should be considered and the Business Sponsor needs to assess the usefulness and possible cost of invoking these. These mechanisms might include the transfer of personnel or cooperation from the original supplier to the new supplier, with set time-frames. Depending on the ownership provisions (as discussed above), the Business Sponsor should also consider whether it would be necessary to assign any of the IP rights to it from the supplier.
If such provisions are not included, or are not clear, this could severely delay the project and cause the Business Sponsor to incur significant expense through duplication of work – something that should be taken into account in the commercial decision on the approach to adopt.
Commercial considerations
Once the technical and legal positions are understood the Business Sponsor can make the most important decision: which is whether the project should go ahead at all. If the answer is ‘Yes’, then a contract reset with a real change in approach and behaviour from both parties is most likely to be the right option.
If the answer is ‘No’ then the legal review should by now be pointing the way forward to some form of termination. Even if the eventual outcome is likely to be a dispute, it is important to bear in mind that a clean exit is always preferable to one that leaves all parties angry and frustrated. While the customer may be contractually entitled to take very abrupt action and demand support for the transition process, a willingness to plan for, and if necessary pay for, such support is likely to result in a much swifter and smoother exit.
Gill Hunt is a consultant with Hunt Lancaster (http://www.huntlancaster.co.uk). Gill has practised as an IT expert since 1998, mainly on disputes involving IT project failures.
Vicky Cooper is a Technology Disputes Partner at Kemp Little: www. kemplittle.com
The authors also wish to acknowledge the involvement of Charlotte Tanner from Kemp Little in the preparation of this article.
[1] Flyvbjerg, B., Holm, M.S. and Buhl, S., 2002. Underestimating costs in public works projects: Error or lie? Journal of the American planning association, 68(3), pp.279-295
[2] Obiter in Globe Motors Inc v TRW Lucas Variety Electric Steering Ltd [2016] EWCA Civ 396 and endorsed by the Court of Appeal in MWB Business Exchange Centres Ltd v Rock Advertising Ltd [2016] EWCA Civ 553.
[3] Glolite Limited v Jasper Conran (1998) The Times, 28 January.
[4] Compass Group UK and Ireland Ltd (trading as Medirest) v Mid Essex Hospital Services NHS Trust [2013] EWCA Civ 200.
