The Successful Management of Delay in IT Outsourcing Contracts

Clive Davies is concerned that relief event regimes in outsourcing contracts are not having the desired effect and that they may sometimes turn projects that are delayed into projects that are destroyed

Introduction – the Phases of an Outsourcing Contract

The delivery of services under information technology (IT) outsourcing contracts typically divides into three essential phases:

1 transition from an incumbent supplier or from the customer to a new supplier;

2 the subsequent transformation to the service platform proposed by the new supplier;

3 steady state delivery of the services.

There is perhaps a fourth phase which is the exit period, but this article concentrates on the activities which occur in the first two phases. These are much more project driven, where the supplier is required by the contract it has entered into with the customer to deliver certain tasks like taking over the operation of the service from an incumbent supplier by a specific milestone. They are more akin to a construction project where a building, bridge or airport is designed and built. In the information technology world this 'construction' or 'development' or 'build' phase is really just a precursor to the delivery of services over the term of the contract where the customer receives an improved IT service and the supplier makes a reasonable return. There can be challenges in this steady state period especially around significant changes, but for most IT outsourcing projects the greater risk to the supplier, and indeed to the customer, of project failure resides in these transition and transformation phases.

Transition/ Transformation Phase Complexity

It is during these phases that the no doubt lengthy and complex contract that the parties have negotiated comes up against its first test. Particularly during a competitive process, the intimate details of the current IT service (ie that which exists prior to the transition to the new supplier) may not have been fully revealed despite the best efforts of all the parties.  In a 'virgin' outsourcing, where the customer is engaging a supplier to provide vital IT services for the first time, the inhouse processes that applied previously within the customer may well not have been categorised or documented with the rigour that an external supplier must of necessity apply. For example, help desk services will typically have been provided on a basis that is perhaps less formal and certainly less measurable than will be the case with a professional supplier of such services. The relationships with third-party contractors that a managed service supplier will take over will almost inevitably prove to be more complex than anticipated or provided for. On top of this type of issue, what might be described as a subjective customer issue, the supplier will also be seeking to move to its way of operating (its service delivery model) in order to deliver the best service it can in its environment. All of this will have been articulated and provided for at great length in the service description and the supplier's solution which form critical parts of the contract, but these are words on paper and have to be made to reflect reality.

Customer Responsibilities and Relief Events

An understated but critical aspect of IT outsourcing agreements is the articulation of those activities that need to be undertaken by the customer as a part of transition and transformation. This is often a very contentious area, with the customer's lawyers seeking to limit these to the bare minimum and the supplier seeking to address all possible customer responsibilities. A happy medium needs to be found that will reflect an appropriate transfer of risk to an outsourcing supplier whilst also ensuring that those tasks the customer can and should still carry out are identified and set out in the contract. This will allow the customer to identify the resources it needs to do this. One of the challenges is that often a large part of the customer's IT team will by then have transferred over to the supplier, leaving few behind to carry out the agreed work.

By what I think can only be said to be custom and practice, most outsourcing contracts then specify that failure by the customer to carry out such an obligation will result, instead of a claim for damages, in the supplier having a right to claim relief from the performance of its obligations and compensation for the additional losses it may incur and risks it will take on as a result.

Contract Relief Provisions

The current trend seems to be for lawyers to draft ever more complex relief event provisions which provide a number of hurdles that a supplier must clear before it can claim relief, such as notifying the customer of any instance of delay or likely delay within a specified period of time from its occurrence, setting out setting out details of the problem and the steps taken to remedy it, and detailing how compensation should be calculated and what is and is not included. If the customer has allegedly failed to meet any of its customer responsibilities, these must also be specified. We are talking here in some contracts about detailed provisions running over several pages. And 'notifying' in this context means, in most outsourcing contracts, submitting a notice 'formally' in accordance with the provisions of the notice or communication clause in the contract. This will specify the form of notice and to whom it must be delivered - typically a senior executive, the company secretary or general counsel. Whilst understandable from a purely legal perspective, this formulaic approach, even if correctly followed, drives a certain form of undesirable behaviour by suppliers and customers. Instead of concentrating on a 'fix it first and then sort the claims out later' approach, the need to adhere to this sort of rigid contract process tends to make both parties more defensive early on in the development of problem issues.

The Soft Touch

In practice, during the inevitable hurly burly and challenge of delivering these complex projects, where there are almost always unanticipated difficulties, the last thing the supplier executive tasked with delivery wants to do is unnecessarily upset the supplier's customer. Yet that is precisely what he or she is required to do under the contract. It is also what his or her professional adviser will be telling him or her to do. He or she must deliver a letter to the chief executive/managing director/company secretary of the customer in which the failure by the supplier is detailed plus the failures by the customer to comply with its specified responsibilities. This will in all probability go down like a lead balloon and will potentially damage the relationship between supplier and customer which is so essential to the effectiveness of the partnership that underpins successful outsourcing agreements. But the supplier must act like that if it is to claim relief from meeting its own obligations and seek compensation – remember it has no right to sue for damages. If the supplier does not advise about the delay (whoever caused it) then it is in breach of contract.

The Hysterical Reaction

If the delivery executive or programme director in the supplier keeps his or her nerve and correctly follows the contract then, in my experience, all hell breaks loose. The customer having been 'notified' at the highest level of its organisation of the situation almost always immediately overreacts and starts a chief executive level conversation. This may be wise at some stage but is often completely unnecessary over a notice required to be given under the contract of a delay that is perfectly manageable. And any suggestion of 'fault' on the part of the customer in the sense of failure to comply with its specified responsibilities creates even more overreaction and collateral damage to the relationship. On one contract many years ago I recall a supplier being required to serve notice of a force majeure event because of severe snow which led to potential delay because travel to the customer's site was impossible. The customer treated this as an example of very poor behaviour by its supplier – and told it so in no uncertain terms.

Cases

The reported cases (which are largely from the construction industry) indicate strict compliance with a notice clause is generally necessary.

Thus in Mannai Investment Co Ltd v Eagle Star Life Assurance Co Ltd [1997] AC 749, which concerned a property lease, the House of Lords held that 'a notice under such a clause will only be effective if it conforms to the specification in the clause' and more graphically 'If the clause had said that the notice had to be on blue paper, it would have been no good servicing a notice on pink paper'.

In Steria Limited v Sigma Wireless Communications Limited [2008] EWHC 3454 (TCC) the judge said that the notice did not have to specify the clause number nor include an assessment of the delay, but must emanate from the contractor (Steria). Therefore meeting minutes prepared by other project team members would not be sufficient. It is unclear if the position would have been different had Steria commented on the minutes or if Steria had prepared the minutes. However the judge observed that service of a statement of case would be sufficient to comply with the notification requirement, although he queried whether this could be said to be could be given 'in a reasonable period'.

In the Scottish case of Education 4 Ayrshire Limited v South Ayrshire Council [2009] CSOH 146, a contractor seeking to claim an extension of time due to the discovery of asbestos gave notice under clause 17.1 of the relevant contract, when it should have given notice under clause 17.6.1 as well. The contractor also said 'we will submit our full claim in accordance with clause 17.6 of the project agreement', instead of 'we hereby give notice of our claim'. It was accepted by both parties that compliance with the notice requirements was a condition precedent to the right to bring a claim. The judge held that this condition precedent had not been complied with, despite the clear intention of the contractor's letter.

So it has to be safer to follow the notice period provisions in the contract, though I do think this does not take proper account of the quite complex contractual processes that are typically applied whereby the status of a contract deliverable is tracked in status reports and reported in minuted project management meetings. How can both parties in these circumstances not be aware of the status of the project?

So Who is at Fault?

I am not taking sides here. I assign equal 'blame' to the soft hearted programme director who won't do what the contract says and to the supplier representative who overreacts when he or she receives a delay or relief event notice. Let us put aside for the moment the potentially deeper question as to whether or not relief event regimes and delay notices are the right approach to encourage successful outsourcing delivery - because they are what the contract often sets out. The customer has in effect through these processes articulated how it expects and indeed requires its supplier to behave. So it should not be surprised or upset and throw its toys out of the pram if the supplier overcomes its nerves and does what it is supposed to do and submits a contractual notice.

Industry Maturity

If we step away from the IT industry for a moment and look at projects in the context of a different sector, construction, it holds up an interesting lens through which to consider and understand the behaviour we see in the technology sector. In a construction project it is recognised as a matter of course that there will be delay and claims and counter-claims about all manner of issues will be made. For the most part these are handled by the professionals involved with occasional sorties into arbitration or the courts or other form of dispute resolution if there is a serious disagreement. What does not happen is that the first letter written in anger in this context following the procedures in the contract gets escalated to chief executive level at the customer and the supplier, with the inevitable resulting deterioration in the overall relationship between the parties. There also seems to be a recognised time and place when these issues are resolved, often in a wash-up at the end of the project. This is probably a reflection of the greater maturity of the construction industry in its approach to projects but it does seem to me to be something that can and should be emulated in the IT industry.

Successful Management of Delay

So what is the answer for the IT industry and its advisers? How do we move to a more mature industry approach which will foster successful delivery and at the same time protect the legitimate rights and expectations of the customer and of its supplier?

Here are some thoughts.

1 Is it the right regime in the first place?

I sometimes suspect that a delay and relief event regime is a figment of lawyers' drafting designed with the best of intentions but not actually promoting successful delivery of a project. Could better joint programme management and early escalation through the contract governance processes and resolution of, for example, resource problems within either party offer a better solution? Can we learn from the Agile development processes and, without detracting from the ultimate responsibility of the supplier to deliver, avoid a yawning and unexpected gap between what is actually occurring on the ground and what the contract provides for?

2 Scrap relief event regimes

Developing this theme, what most customers really want (as mentioned above) is not so much a restriction on the remedies available to the supplier but an attitude of focusing on fixing the problem and worrying about who was to blame later. Forcing a supplier through this sort of formulaic process on relief event and compensation ostensibly to limit the supplier's remedies drives the wrong behaviour. Instead of concentrating on fixing the problem it makes both sides defensive – and disproportionality worried about whether they are either applying or ignoring the strict provisions of the contract. In fact, taking this argument forward to its ultimate conclusion, why not scrap relief event and compensation regimes altogether and rely on the right of either party to claim damages through the courts if this is justified. Or, if this might be considered to take too much time or effort or be unduly damaging to the relationship, at the end of the transition have a wash-up discussion with a proper process for resolving disputes (perhaps through adjudication or mediation with ultimate resort to arbitration or the courts) when any claims arising during these 'project' stages can be resolved. This should clear the decks and still preserve the relationship that is needed for successful service delivery.

3 Early commercial/legal engagement

Assuming that a relief event regime applies then, rather than wait for the first occurrence of a situation in practice that requires a notification, the commercial or legal advisers for the customer and the supplier can get together right after contract signature and agree how the process will work. They can in particular agree on a form of notice which will be delivered and also an early warning system. That way each side will know what is likely to happen and can manage their own sides to avoid the 'soft touch' under-reaction and the 'hysterical' overreaction. Regular commercial/legal meetings will help as will a phone call to say a delay notice is being despatched.

4 Lower level of notice

As this is likely to be an administrative issue, albeit potentially an important one, another solution is to specify a lower level of initial notice delivery for delay events that will not at that stage trouble senior management. This can be escalated as required for repeated or serious delay but will permit the appropriate management of a project that will get delivered but where there are some teething issues (as opposed to one that is doomed to failure).

5 Be realistic about customer responsibilities

Needing a customer to carry out certain tasks is not an unreasonable expectation for a supplier. Under one contract I worked on with 24/7 service obligations the supplier's advisers discovered during the negotiations that it could  not access the customer's building after 11pm at night without travelling five miles to the home of a security guard to get the key to the front door! A quite precise customer responsibility about access to the premises was crafted as a result and the relevant service levels adjusted accordingly. Despite the legitimate purpose of an outsourcing contract being the transfer of risk to a supplier, there are some things the customer must of necessity still do to ensure the successful delivery of the outsourcing service. A supplier should not be shy about asking for these to be set out in the contract and a customer should not be over precious about accepting them.

6 Professionalism

The computer industry should seek to learn from the construction industry that such processes and claims are a fact of contractual life and apply them in a professional and calm manner without overreacting and either ignoring the contract processes or deeming their use to be a terminal event for the relationship.

7 Appreciation of true state of affairs

It will often be the case that these sorts of claims around the conclusion of a project are simply sweeping up inadequate but not fatal performance. The computer services will have been developed and delivery completed, albeit perhaps late or with some relatively minor omissions. This is different from the situation where these events are symptoms of a larger malaise on either the supplier's or the customer's part which will inevitably lead to termination of the contract and claims for damages. Understanding the nature of the particular circumstances, hard though that can sometimes be, is important to providing effective legal input.

Conclusion and Feedback

I advocate that these delay processes, if they must be applied, are kept as simple and manageable as possible. If they have to be operated this should be done in a professional and dispassionate way as appears to be much more likely in the 'more mature' construction industry. However, I suggest that in the IT industry too much contractual emphasis is placed upon these formal processes in a well-meaning but ultimately misguided effort to protect the customer or supplier. This is why they are not properly understood or used by either side. The application first of effective governance processes before having to reach for the contractual sword may be far more effective in practice in promoting the successful delivery of IT projects. Abandoning relief event regimes entirely and having the sort of end of project wash-up I have suggested above merits serious consideration.

Am I a lone voice crying in the wilderness here or are there other outsourcing specialist lawyers out there who agree with me? Or do you take a diametrically opposed view? Either way I am interested in any responses either through the editor or directly to me.

Ultimately successful and timely delivery of the initial stages of outsourcing projects is in the interests of the industry and of our profession as advisers so I suggest that this is an important topic to debate. 

Clive Davies (clive.davies@uk.Fujitsu.com) is currently a Senior Counsel at Fujitsu Services Limited who previously advised customers and suppliers on outsourcing contracts whilst in private practice. The views expressed are those of the author and not necessarily those of his current employer.

 

Published: 2014-11-07T11:36:55

    1 comments

    • I don’t think you are a lone voice crying in the wilderness and this is a problem which crops up frequently. A couple of thoughts: (i) in my experience, clients (both developers and customers) often simply ignore or abandon relief event regimes. This can even happen when their importance is emphasised, some haggling takes place over the clause and the client has clearly read and engaged with the clause during negotiations! This can often lead to difficulties later on where neither party has complied with their obligations, but more significant problems with the build have emerged; and (ii) At points 4 and 5 of your further considerations I think you hit the nail on the head. Where these kind of clauses are being negotiated, increasingly we try to set up lower level notifications, with the option to escalate one or two stages before it reaches senior management (I think this process applies equally to the management of SLAs for the ongoing service provision). I think clauses can be crafted to accommodate the real life practicalities of customer input (although this is tricky with ‘mission critical’ software which does need urgent action). Thank you for this interesting and thought provoking article, particularly the analogies with the construction industry. Richard Barnett, Associate, Hansel Henson @RichardBLaw
      anonymous, 16:24:42 12/11/2014
    Please wait...