Multi-vendor or ‘tower’ based IT outsourcing programmes have become increasingly common over the last few years, and have been adopted by the Cabinet Office ICT strategy for central government. Roger Bickerstaff explains that the allocation of liabilities for implementation and service failure amongst the tower contractors and the customer is inevitably complex and can be contentious, depending on the customer’s preferred approach.
Many multi-vendor IT outsourcing arrangements are now structured around the 'tower' concept. Under this approach, the customer enters into service contracts with a number of relatively specialist 'tower' contractors, each of which provides a different aspect of the overall IT service provision required by the customer. The 'towers' can be structured in many different ways depending on the customer's particular circumstances: popular combinations are desktop/end-user devices; infrastructure (including data centre and hosting services); applications development and support; and networks.
The key advantages of this multi-vendor approach are the avoidance of 'lock-in' to a single IT outsourcing contractor and the avoidance of prime contractor mark up. There have been plenty of examples of single suppler IT outsourcings where there has been relatively little innovation or improvement during the lifetime of the project and the single services provider risks being thought of as treating the account as a 'cash-cow' for its benefit. The multi-vendor approach ought to provide a more competitive environment which enables the customer to require the tower contractors to compete for on-going business. The tower contract approach ought to result in the customer avoiding paying a prime contract 'mark up' as a result of the customer contracting with the tower contractors individually, instead of contracting with a single prime systems integrator for all of the required services which are then sub-contracted to – possibly the same – more specialist service providers.
The services provided by the tower contractors still need to be coordinated and managed. In the private sector this role is often taken on by the customer, with the customer having (or developing) the in-house technical, service management and commercial skills required for this role. In the public sector, the Cabinet Office ICT Strategy recognises that these skills are in short supply. (In many cases, they were outsourced to the private sector in the original first generation outsourcing projects.)
As a result, the standard public sector approach is to appoint a Services Integration and Management (SIaM) Contractor. The scope of the services to be provided by the SIaM contractor depends on the skills and capabilities of the in-house team. At its most extensive, the SIaM contractor coordinates the delivery of the services by the tower contractors, acts as the overall technical design authority for the integration of the services to be provided by each tower contractor and acts as the customer's agent for commercial issues across the tower contracts.
The role of the SIaM contractor is generally formalised in an Integration Agreement which is entered into between the customer, the SIaM contractor and each of the tower contractors.
The focus of this article is to review the liability implications arising from this tower operating model. There are a number of complexities which need to be taken into account in both the tower contracts themselves and in the integration agreement.
Dealing with Inter-contractor Liabilities
Within a multi-vendor environment, liabilities inevitably arise where one tower contractor does something or fails to do something which it ought to have done which affects one or more of the other tower contractors.
For example, during the implementation phase, the infrastructure contactor may be late in developing elements of the infrastructure which are required for the testing of an application. The applications contractor will then incur expenses through being delayed in its testing activities. Alternatively, during the operational phase, the infrastructure contactor may need to carry out additional work if there are problems with an application (e.g. where an application has poor performance, the infrastructure contractor may need to install additional hardware in order to improve its performance). There is a wide range of inter-connectedness in these IT service delivery arrangements which can easily result in liabilities being incurred on an inter-contractor basis.
There have been attempts to allocate these inter-contractor liabilities through direct contractor-to-contractor liability structures within the integration agreement. The purpose of these arrangements is to create a contract mechanism so that each contractor has a direct right of action against the tower contractor that caused the problem. In most cases, these structures have been strongly resisted by suppliers. IT companies are very resistant to the idea of entering into contractual relationships with companies that they have not chosen and who may well be their competitors.
From the customer's perspective, although this approach seems to avoid the customer becoming involved in these inter-contractor liability issues, it also means that there is a risk of legal actions being brought between the tower contractors without the customer having any real control. This would be very destabilising in a long-term IT outsourcing arrangement.
This may be one of the reasons why 'joint and several' liability structures, as used in the Heathrow Terminal 5 project, are rarely seen in IT outsourcing projects. It may be possible for a group of contractors to accept this form of liability on a project basis, where the contractors are working together over a relatively short period of time to deliver a specific implementation requirement. The individual contractors may well take the view that there is likely to be a 'litigation phase' at the end of the implementation project and that all of the inter-contractor liability issues will 'come out of the wash' in that process at that time. This is not the case in longer term IT outsourcing projects, and any significant inter-contractor legal action is likely to be very destabilising for the ongoing success of the service delivery.
Instead, the most common approach to inter-contractor liabilities tends to be for the liabilities to 'flow-through' the customer. If a contractor incurs liability due to an act or failure on the part of another tower contractor, it must make a claim against the customer. The customer will then manage that claim by making a claim against the tower contractor that actually caused the liability in the first place. This may seem very cumbersome but it means that the customer remains in control of the legal claims that may be made on an inter-contractor basis. This is probably less destabilising for the overall success of the project.
These claims are often delegated to the management of the SIaM contractor in the first instance. This raises concerns over the impartiality of the SIaM contractor, particularly in a situation where the SIaM contractor is a competitor of one or more of the tower contractors. The extent to which the SIaM contractor can make a decision on the allocation of liabilities in these circumstances needs to be carefully constrained in the SIaM agreement. The SIaM contractor will provide a form of expert determination in these circumstances. The SIaM agreement needs to make clear what level of liability the SIaM contractor can give a determination on and the redress procedure if a tower contractor disagrees with a decision of the SIaM contractor.
Limits of Liability
In a customer 'flow-through' arrangement for inter-contractor liabilities, the limit of liability for customer liabilities needs to be carefully considered. Customers will generally seek to limit their liability as far as possible in IT outsourcing contracts. In public sector and financial services outsourcing contracts, it is relatively common for customer limits of liability to be very low, on the basis that the all the customer is doing is receiving the services and it therefore should not be in a position to carry extensive liabilities.
In multi-vendor tower arrangements, the limit of liability for customer liabilities needs to be established at a level that will allow for the 'flow-through' of the likely inter-contractor liabilities. If the customer's limit of liability is very low then the contractor may be precluded from recovering for losses that are caused by other tower contractors.
One way of dealing with this issue is to make clear that the customer's limit of liability has two caps: one which relates to liability which is caused by the customer itself and another which relates to liability incurred by the customer on a flow-through basis. The customer's limit of liability can then be set at a relatively low figure that relates to the amount which the customer may itself actually cause.
The customer will want protection in its tower contracts so as to limit any flow-through liability that it may incur to each tower contractor. Where that liability arises from the acts or omissions of another tower contractor, the customer's liability should be limited to the passing through of the compensation that the customer receives from the tower contractor that caused the losses.
Force Majeure
One of the almost inevitable consequences of these types of connected multi-vendor arrangements is that each party must bear the risk and costs arising as a result of the occurrence of force majeure to any tower contractor or the customer.
At first sight this may seem a rather harsh position but the alternative approaches would mean that tower contractors that are affected by force majeure would be responsible for the costs and expenses of other tower contractors and the customer as a result of force majeure. This would not be reasonable. Also, it clearly would not be reasonable for the customer to compensate the other tower contactors for the consequences of force majeure that affects a particular tower contractor.
SIaM Contractor Liabilities
The SIaM contactor plays a key role in the coordination and management of the overall service delivery arrangements, depending on the extent to which the customer outsources the SIaM responsibilities to a third-party contractor. If there is a significant outsourcing of these responsibilities, the performance of the SIaM contractor is pivotal in the success or failure of the overall arrangement.
The service management, technical design and commercial roles provided by the SIaM contractor are unlikely to attract particularly extensive service charges. In essence, the SIaM contractor's fees are generally based on the number of people working on the project. It is not a particularly personnel-intensive role. Undoubtedly, many of the SIaM roles are quite specialised and attract reasonably high day rates. Nonetheless, the charges paid to the SIaM contractor will be low in comparison to the charges paid to the other tower contractors.
This means that the overall level of risk that the SIaM contractor can be expected to accept needs to be considered in the light of these fee levels. The customer should not expect the SIaM contractor to provide an overall guarantee of the delivery of the services to the customer under its multi-vendor tower operating model. If it were to do that, the SIaM contractor would effectively become a full systems integrator and it would be entitled to charge a systems integration fee, with a limit of liability relating to the overall delivery of the solution.
This is not usually the liability approach taken by multi-vendor outsourcing customers. The general approach is to regard the SIaM contractor as acting in a managing contractor role, with a responsibility to provide the SIaM services – in effect - to the usual professional standard of reasonable skill and care for the performance of these services.
On this basis, the overall limit of liability of the SIaM contractor should probably relate to a percentage of the SIaM contractor's charges for the provision of the SIaM services in much the same way as limits of liability are established for most IT services contracts.
Overall Approach
It has to be recognised that once the allocation of liability issues are considered in practice, there is a tendency in many situations to regard the complicated and, to a certain extent, onerous liability consequences of the multi-vendor operating model as being 'all too difficult'. Instead, the customer simply takes on the SIaM role itself and enters into a series of free-standing contracts without creating and entering into the types of liability structures that are outlined in this article.
There is nothing wrong with this approach, as long as the customer is aware of, and accepts, the overall services integration responsibilities, together with the relatively unbounded commercial consequences of this approach. Many customers believe that they can manage these risks themselves, and in many cases they can and do. For less experienced and capable customers, the appointment of a SIaM contractor and a more explicit liability structure is a sensible protection. Always assuming that it is possible to persuade someone to take on the SIaM role, which is not a foregone conclusion.