Last week we revealed how all too many cloud computing contracts (and more specifically, Infrastructure as a Service (IaaS) agreements) result in completely unacceptable outcomes for the buying organisation.
The key issue is typically a fatal misalignment between the buyer’s desired business outcomes and the terms of the agreement. You expect a system that can fulfill your specific business outcomes, but the vendor is tasked with providing infrastructure. That in itself is not a solution — it is merely the framework for a solution.
With that in mind, today I want to discuss how a cloud computing contract should be negotiated. I am going to revisit the six procurement steps outlined in my previous post and explain how you should approach the same situation differently in search of a beneficial outcome. It doesn’t involve fighting against your vendor — on the contrary, it is far more a case of properly aligning the interests of both parties.
Step 1: Your Invitation to Tender (ITT)
It can seem rather sensible to include as-is and to-be metrics within your ITT, and it is. But what many completely miss out is the most vital information — your desired outcomes.
The omission of outcomes at this early stage all but dooms the project before it has even begun. Consider this — if the vendor does not intimately understand your desired outcomes, how are they able to deliver a satisfactory end product? Moreover, how can they put an appropriate tender response together without all of the vital information?
If your vendor does not have all of the necessary information at the tender stage, the financial and technical risks of fitness for purpose and project success lay squarely on your shoulders.
You must include your outputs, desired outcomes required and the business case metrics in your ITT.
Step 2: Selecting a Provider
If tender responses are not drafted with all the relevant information to hand, every stage thereafter results in an exponential increase of the risk of complete failure.
On the assumption that step one was not satisfactorily completed, you are likely to be presented with a list of tenders that are full of guesswork and assumptions. As such, you will bear the risk of all the vendor’s assumptions and caveats.
But even if you do provide clear and quantifiable business outcomes in step one, this second step still offers potential tripping points. All too often providers are selected on price alone, when that should be only one factor amongst many up for consideration. After all — just because a provider claims that they can deliver does not mean that they can. Furthermore, the issue is not typically with the price, but rather what is excluded from it.
Require all the tenderers to confirm that they can deliver the outcomes and business case and make it a condition of contract. Perform robust due diligence on the contract terms and the supplier’s ability to deliver the data centre, architecture and your desired outcomes — including how the outcomes will be achieved.
Step 3: Contract Execution
All too often, a buying organisation will sign a provider’s standard terms contract. This means that you enter into a “clean” contract. As such, the warranties and obligations contained within are very light, and it is comparatively simple for the provider to discharge its obligations, whether or not this results in you achieving your desired outcomes.
And let’s not forget the inherent risk in signing standard provider terms. You’re entering into an extremely messy legal environment based upon “agreements to agree”, which are not contractually operative and so cannot be relied upon if they are not delivered against. Again, you are faced with a great number of unknowns and shoulder all risk for service delivery.
Negotiate fit-for-purpose contract terms with more than one supplier, to allow you to compare risk positions as part of the selection process. Put a residual process in place to ensure the contract is fully formed and contains no caveats, assumptions or agreements to agree.
Contract with providers to undertake a pre-contractual scoping of your requirements, outcomes, internal skill sets and resource availability, and to evaluate issues with moving the applications from legacy physical servers to a virtualised environment. Contract for this as advice in the first instance.
Agree terms of reference that will ensure that you understand the true risk position and have effective plans for mitigation. Ensure that an overall transition plan is created and agreed, which will take the project through to business as usual on the new architecture. Ensure that the outputs include a commercial model with effective what-if scenarios, so these are fully considered and understood by both parties before committing.
Finally, select a preferred partner who has evidenced that it can deliver to your desired outcomes, to agreed costs and timescales, and is prepared to underwrite this contractually.
Step 4: Provision of Infrastructure
At this stage, the provider often will purchase the infrastructure and set it up in their data centre. The infrastructure is based upon indicative information on the assumption that it can be scaled up and down as demand necessitates. Furthermore, the managed service is for kit and function, up to the operating system level only.
In line with the common theme established, unless you have implemented the “positive resolution” steps up until now, you will have taken on all the financial and technical risk that the infrastructure has been mis-specified. Assuming that the provider’s obligation is to monitor up to the operating system layer, check whether this excludes the virtualisation software layer. If it does, the buyer takes the risk that the solution is fit to run all its business application software and that all the software will migrate successfully to the new virtualised environment.
Ensure the provider builds and provides the infrastructure in the context of what you actually need. You have requested an end result that meets your desired outcomes, not a blank canvas.
Step 5: Testing
As one would expect by this point, the testing process carried out by the provider is of little use to the buyer in ensuring that the infrastructure is fit for purpose. The provider will test the infrastructure with a series of “green light” tests to verify that the hardware and network are performing as it should, but this is a long way from the system being fit for purpose (as the buyer would define it).
Additionally, once you accept the system (as you would be contractually obliged to do), your express contractual rights for non or partial delivery degrade drastically. And perhaps most damagingly, you will at this point be paying for a system that is not yet fit for purpose (nor do you know if it ever will be).
At this stage you should be carrying out the testing that truly matters — i.e. migrating and proving the business applications on the new infrastructure. You should be training your staff to use the new system and completing a clean transition from old to new.
Step 6: Closure
At this point, the provider has probably discharged all of its obligations under the terms of your initially ineffective contract.
It is now your responsibility to migrate your existing system over to the new architecture, which is in itself a major undertaking. You will need to set up a new project to migrate to the new architecture, and will be wholly responsible for its success or failure. You therefore retain overall responsibility for achieving the desired outcomes.
On the other hand, if you have contracted well, you should now be able to realise the benefits of the new system, achieve your desired outcomes and ensure that your business case is intact. This is what should represent project closure, and the provider should now of course be appropriately compensated.
How to successfully contract for cloud services
If you are experienced in strategic commissioning you may make the reasonable assumption that cloud computing cannot be much of a different beast. However, we have found that nothing could be further from the truth. There are a number of cloud contracting pitfalls that you must be wary of that can be read in this blog post. For a more in depth analysis on how to successfully buy and contract for cloud services, you can download our free white paper here.