Cloud platforms are often used to underpin significant business transformation projects, where complex configuration or augmentation of the cloud platform (or integration of the cloud platform with third party systems) may be required to deliver a system meeting the customer’s objectives. We’ve already explored the key issues when reviewing or negotiating a cloud subscription contract.
If your business is engaging a systems integrator or implementation partner to implement a cloud solution, it is likely that these services will be provided under a contract that is separate to the cloud subscription agreement. The downside with having separate vendors and contracts for the cloud subscription itself and the implementation service is that they could engage in finger-pointing which complicates resolving any issues.
On the upside, unlike the underlying cloud subscription terms, contracts for implementation services will generally be negotiable, so customers can clearly define the respective responsibilities of the implementation partner and cloud service provider. In this article we’ll explore some of the key issues to consider in your negotiations.
Mind the gap: end-to-end responsibility
One of the most common issues to confront when a third party implementation partner is engaged to configure and customise a cloud solution is determining who should bear responsibility for problems with the resulting solution – the implementation partner or the cloud service provider?
Ideally, the implementation contract will require the implementation partner to take end-to-end responsibility for ensuring that the solution as a whole (ie. the cloud service as implemented, configured and integrated with the customer’s systems) meets the customer’s requirements. Without this, customers commonly find that neither the implementation partner nor cloud service vendor will take responsibility when an issue is discovered.
If it is not commercially possible to achieve end-to-end responsibility for the implementation partner, there are other options available. Third party co-operation clauses and obligations for an implementation partner to investigate issues and raise any support requests with the cloud vendor on the customer’s behalf (and assist in the ultimate resolution of those issues and the provision of workaround assistance) can reduce the risk of the customer being caught in the middle. In this case, you will still need to define carefully the hand-off points between the implementation partner and the cloud service provider, to avoid gaps emerging for which you bear the risk.
Service levels
If the cloud vendor is providing support for the underlying platform and an implementation partner is providing support for the configuration (and any enhancements), the service levels agreed with each vendor must work together.
For example, while it may be appropriate to agree certain availability and incident resolution service levels with the cloud vendor, limited to the underlying cloud platform, you should also consider having separate, overarching service levels with the implementation partner (covering the solution as a whole). In this scenario, the implementation partner would be expected to take initial responsibility for investigating any issues with the solution and liaising with the cloud provider to resolve issues that can be shown to be caused by the underlying platform. Appropriate processes for handing off responsibility between the vendors should be considered here, as well as the extent of the implementation partner’s role in escalating issues to the cloud vendor and assisting in managing them. Ideally, the handoff process will be sufficiently rigorous to mitigate the risks of vendor blame games and issues falling between the cracks, but also to recognise where responsibility for addressing any given issue is most appropriately allocated.
Managing security
There is often confusion regarding who is responsible for security. In broad terms, a cloud provider should be subject to obligations to ensure that the platform is secure and meets appropriate standards (such as ISO27001). However, the level of security offered by most cloud platforms also depends on user-controlled security settings and may be affected by configuration, integrations or enhancements; ensuring they don’t should be the responsibility of the implementation partner. Implementation contracts should include requirements for the implementation partner to ensure that the underlying platform’s security features are appropriately configured, integrations and enhancements do not give rise to security issues and, if the implementation partner is providing ongoing support, to monitor potential vulnerabilities on an ongoing basis and take appropriate remedial action.
Delay management
As with all IT projects, cloud implementations are vulnerable to potential delays. Implementation contracts should include:
- a detailed project schedule;
- obligations for the implementation partner to meet the milestones identified in the project schedule by specified dates; and
- a comprehensive delay regime.
Delay regimes should address:
- requirements for suppliers to monitor for, and immediately notify the customer of, any actual or potential delays;
- requirements for suppliers to mitigate the effects of delays (including by redeploying resources to perform later-scheduled tasks where reasonable to do so);
- the circumstances in which the implementation partner will be entitled to an extension of time (including to the extent that a delay is caused by the customer or its personnel) and the process for seeking an extension;
- a process for determining the length of extension to be granted, usually by reference to the actual length of the delay caused by the relevant event. In determining the length of an extension, customers should take into account the impact of the delay on the project’s critical path and any concurrent delays for which the supplier is not eligible for an extension.
Overlap between this type of regime and any generic force majeure regime needs to be considered carefully. In general, time-based delays are often better addressed by a specific extension of time regime which is tailored to the steps to be taken to quality for and receive an extension of time (as opposed to a force majeure clause, which can be a blunt instrument that does not create the appropriate drivers of behaviour).
Changes to the cloud service
Cloud services are generally provided in the same way to all customers – and particularly so for public cloud products. As part of this model, customers may benefit from improved functionality or performance over time. However, this approach also means that a customer has minimal control over changes to the cloud service – generally a vendor can make changes to its service at any time without the customer’s approval and without providing an ability for customers to roll back to a previous version.
To protect a customer’s investment in implementing a cloud service, implementation contracts should specify how updates to the underlying cloud software will be addressed. At a minimum, updates must be tested to ensure that the updated software and any configuration and integrations continue to function in accordance with the specifications. Contracts can either require updates to the cloud software to be tested and implemented at no additional cost or at a per-determined additional cost. You should also consider a mechanism for performing any additional rework needed to preserve the benefits of any configuration or customisation associated with the initial implementation following an update to the cloud platform – this may involve a work-order based mechanism for further implementation services.
Subscription costs during implementation
There’s often a tension between a customer’s need to secure a favourable price for a cloud subscription based on the scale of its planned implementation, and the need to avoid wasted expenditure if the implementation project is unsuccessful.
To avoid wasted expenditure, it is preferable for the cloud subscription (and any longer term subscription commitments) to commence only when the implementation project has been completed. Often this can be achieved through the use of either a trial licence during development, or a requirement for the implementation partner to use its own subscription during development. If it is necessary to pay cloud subscription fees from the start of the project, customers should consider a mechanism to minimise expenditure during the implementation period. For example, a compromise may be to purchase a limited number of user licences for the “development” environment, with additional user licences being purchased for the “production” environment only once implementation outcomes are known.
In either case, it is important to ensure that there is a commitment to what terms and pricing will apply once the customer is in a position to purchase the full service. Since many cloud vendors do not agree to long-term price holds, this is a key item to negotiate early with the cloud vendor.
Dealing with implementation failures
If the implementation fails, the customer may wish to terminate both the implementation contract and cloud subscription, so you need to consider the ability to terminate the cloud subscription agreement. Typically, cloud vendors will not accept any risk associated with an implementation partner’s attempts to configure and customisation the cloud platform for a customer, and so it may be that the customer will need to terminate the cloud subscription for convenience. The costs of doing so should be considered carefully. You should consider specifying in the implementation contract that any costs associated with terminating the cloud subscription are considered direct loss (and so recoverable through a claim for breach of contract).
Longevity and return on investment
Most cloud providers will offer their services either on a rolling 12 month basis, or require that customers commit to an initial term of 3 years followed by rolling 12 month terms. Unlike many traditional IT contracts, cloud providers generally reserve a right to themselves terminate at the end of any renewal period. As such, the provider is not required to continue to provide the platform over an extended period of time (or to continue to provide it on at any specific price).
This lack of certainty regarding the potential term of the contract and pricing beyond the initial term may impact the business case for implementing a solution. For example, if an organisation is making a significant investment in implementing a solution based on a cloud product, and the business case for implementation assumes a specific effective life of the solution to achieve a return on the investment, the customer should be in a position to know (or at least forecast accurately) the cost of the underlying cloud solution for that effective life. Where the effective life is longer than the initial cloud subscription period, consider seeking an ability to renew the cloud subscription, preferably on the basis of committed pricing or pricing which is subject to a pre-defined adjustment regime (such as annual increases based on CPI), for at least that renewal period.