In the work we do for customers procuring ICT to meet their business and operational objectives, it seems like an increasing number of tender responses are joint responses where a local New Zealand entity is implementing an offshore software solution (often cloud-based).

On their face, these proposals can look very attractive. The customer gets the benefit of a potentially world-class technology solution at an attractive price, implemented by a company 'on the ground' which is more likely to be familiar with the New Zealand environment and may be more responsive to the customer's needs if it has a local reputation to protect.

However, from a customer's perspective, the two suppliers typically have no intention of entering into one tripartite contract where both suppliers are 'jointly and severally' liable for the outcome. Nor do they typically propose a contractual arrangement where one of those suppliers is responsible for licensing, support and implementation of the solution but subcontracts a portion of the required work to the other supplier. What they will insist upon instead is a structure where the customer signs up to a separate implementation contract with the implementer and licensing/subscription (and possibly support and maintenance) agreement with the off-shore vendor.

This contractual structure is relatively common and often may be the best (if not merely the only) way forward. However, there are several potential pitfalls to avoid. In our experience, they include:

Compliance with the 'requirements'

While global suppliers and local implementers may have put forward joint proposals, we quite often see them squabbling over who will be responsible for ensuring that the solution meets the customer's RFP requirements - sometimes with an outcome that the customer is left carrying the risk. An implementer may be reluctant to warrant, for example, that the solution once configured and implemented will meet the customer's functional and/or non-functional requirements if it has not developed the solution itself. The offshore vendor may only be prepared to warrant that the solution meets its published specifications. Getting either party to commit that the solution, once implemented, will meet the customer's requirements, can be very challenging. In our experience, this needs to be called out as an express expectation in the RFP to have the best chance of successful resolution.

We recommend that customers make it very clear from the outset in RFP documentation that (a) the customer is not the expert in the solution and is relying on the response to the RFP and (b) the customer requires that the successful respondent(s) commits in some way to meeting the customer's requirements. If push back occurs during negotiations, we often find that the best approach is to insist that the two suppliers together resolve the issue and put forward a joint response that addresses the concern before either will progress in the RFP process.

The impact of failed implementation on licensing

We often see global suppliers insisting that the customer order a certain number of subscriptions or licences before development and testing even commences. The obvious problem with this is that the customer does not, at the outset, have a configured and accepted solution and is dependent on another party (the implementer) doing its job to achieve this. We typically seek to negotiate a position that if the implementation fails (ie acceptance of the solution is not achieved or is delayed so long the customer ends up terminating) either (a) the global licensor/provider must refund the licence fees paid up until that point or (b) the implementer must pay the customer an amount equal to those licence fees.

Liability

If separate contracts govern implementation and subscription/licensing, you'll typically find that both suppliers want to tie their respective liability cap to a multiple of the fees they have been paid. The problem with this is that the implementation fees might be relatively small but this might be the stage at which the customer faces the biggest risk and potential losses. Without a cap that is tied to the amounts paid to both suppliers, the cap in either or both contracts may be too low and may require some careful consideration and negotiation. Furthermore, an ability to recover up to a cap is only valuable if the party on the hook has the financial standing to meet the potential liability (or is appropriately insured). For example, even if a local implementer agrees to a high cap, that won't help if (a) the offshore supplier won't guarantee the implementer's performance; and (b) the local implementer is a small company with limited assets or insurance.

To ensure customers enter into these contractual structures with 'eyes wide open', we suggest that RFP processes require joint proposers to clearly explain their position on risk allocation. This should include requiring them confirm whether they intend to have joint and several liability for the solution as a whole (and all related services). If the answer to that question is no (as is often the case), they should specify what each joint respondent intends to be liable for and to what extent, provide separate financial information about each proposed contracting entity, and propose any other means by which risk to the customer might be addressed (eg guarantees, performance bonds).

Support - whose job is it?

Time and time again we see support becoming a very fraught area of negotiations, particularly if it isn't given much attention until the close of the deal. Support can account for a small proportion of the overall fees and therefore viewed by the customer as a comparatively easy issue to close out. However, despite the lack of money at stake, support can be crucial in terms of the ongoing viability of the system. Having less financial incentive to drive a support partner to find a suitable outcome, if this isn't dealt with early on, customers can find themselves close to the end of the deal before they find out that they won’t be able to receive a key element of support that may leave them exposed.

A local implementer will typically make the most margin on implementation services and have not much interest in providing local support (or, even if it does, may not wish to commit to binding service levels). An offshore provider may have a very limited support offering (sometimes limited to time zones that don't work for NZ clients) and little appetite for changing the offering (particularly if they are offering a one-to-many, subscription-based service). Customers can therefore struggle to get the support they need and so the benefit of having a local implementer on the ground needs to be balanced against the ongoing BAU requirements of the customer.

Our advice - even if the support seems likely a relatively small portion of the deal (at least from a financial perspective), focus on support requirements early in negotiations to avoid a situation where you are presented with a support offer and terms at the last minute which you have little choice but to accept.