In an industry that provides services to parties that may or may not have a thorough understanding of the services being provided and the technologies being deployed, service level agreements (SLAs) provide a middle ground where terms of engagement can be clearly crafted.
SLAs are meant to specify what service a customer can expect, when, how, how often there may be downtime, and remedies that can be applied if the provider fails in any of its promises. In reality, they're often confusing, complicated documents that don't really assist either service provider or client in managing the relationship, especially when things go wrong.
Says John Giles, managing attorney at Michalsons: "There's quite a bit of confusion in South Africa about service level agreements. People seem to have different understandings of what they are and why they should exist. There are many kinds of service level agreements, which confuses the issue."
An SLA, according to Michalsons SLA Guide (http://www.michalsons.co.za/service-level-agreement-sla/4610), 'is an agreement that describes the services (not goods) that one entity will provide to another. If goods are being provided, an SLA is not the right agreement. It is a type of contract and in the IT context it is an IT contract'.
Says Web*Tech*Law director Paul Jacobson: "An SLA for a business regulated by legislation may have specific provisions intended to help the business meet its regulatory obligations. Other than that, SLAs are usually governed by more general contract and corporate laws that establish baseline requirements and frameworks or contain frameworks that the parties want to vary with their contract."
SLAs are not one-size-fits-all contracts - each has to be negotiated specifically to take into account the service being provided, the client's specific needs and requirements (like regulations or legislation) and what level of service is agreeable to all parties.
Says Giles: "Negotiation of service levels involves a compromise between the clients' ideal list of requirements and the need to prioritise these in terms of what is realistically achievable. Performance measurement can entail considerable negotiation. Therefore, a balance has to be struck so the desired levels of performance can be secured without imposing restrictions on the service provider that are so tight that they inhibit the development of a creative and effective working relationship."
SLAs are legally enforceable, provided they've been constructed correctly. Whether or not it's financially viable to pursue a breach in court, of course, is a question each company will need to ask and assess based on what was lost versus the cost of taking the matter to court.
An SLA is a tool to build a good relationship, and should not be seen as a weapon to use against the other party.
John Giles, Michalsons
Says Pria Chetty, founder and director of technology law and policy advisory service EndCode: "There are two key challenges with enforceability. The first is that the accountability framework is unclear. Service levels need to be specified in plain language that can be translated into day-to-day responsibilities. Generic SLAs, specifically in the realm of IT services, don't provide the necessary assurances.
"The second challenge," she says, "is the governing law. Many SLAs in South Africa, particularly with multinational IT corporations, are versions of international contractual documents. These SLAs are touted as best practice and difficult to amend due to an unrelenting legal team at the head office in, say, Germany or the US. The law that governs the contract is also that of the country of origin. This places an obligation on the client to understand the governing law as the legal remedies are determined accordingly."
"In practice, any legal action in our courts to force the service provider to perform, or even to force the customer to pay, is a lengthy and costly process. An SLA is a tool to build a good relationship, and should not be seen as a weapon to use against the other party," Giles cautions. As such, structuring an SLA clearly and carefully is critical.
Notes Jacobson: "SLAs, real SLAs, tend to be very specific and detailed because they deal with operational challenges."
For CIOs and IT managers, there are a number of things to look out for when crafting and signing SLAs.
"CIOs need to be aware of (and carefully consider) various things...such as the warranties, indemnities, liability, remedies, and penalties for a breach. The duties and the responsibilities of each party to the agreement should also be set out. They need to make sure that a description of the service is also included, as well as the standard at which services are to be performed," says Giles.
Comments Chetty: "Escalation clauses are critical for the CIO. CIOs are often extracted from the day-to-day engagement with IT service providers. The CIO needs to be clear as to when service delivery and performance issues need to be escalated to her.
"Service level agreements proposed by the service provider tend to be one-sided. CIOs need to engage trusted advisors to ensure the inclusion of client-specific interests in the SLA. Escape clauses are vital. "Providing for early termination of contracts where the service levels are not met is critical, together with provisions to manage transitions to new service providers and mandatory cooperation from the incumbent service provider. The client has a significant dependency on IT for business operations and securing operational continuity is key. Careful specification of events that trigger risks is essential to provide for early detection and mitigation.
"Avoid complex penalty clauses. Penalty provisions typically comprise complex formulae for calculation with little interrogation of how the formula is to be applied. The end result is the unavailability of an adequate remedy to failure to perform by the service provider. Disputes as to calculation of penalties often arise, which compound the issue. CIOs need to ensure adequate risk management through workable penalty structures."
This article was first published in Brainstorm magazine. Click here to read the complete article at the Brainstorm website.
Share