Credit: Dreamstime
Being diligent about service-level agreements (SLAs) has always been important for IT organisations working with IT service and cloud providers. But understanding how to negotiate, structure, manage, measure, and report on these metrics is more crucial than ever.
“Given digital transformation and the spending cuts across IT and business lines, it is critical to confirm the expected outcomes in advance relative to the IT spend, otherwise IT leaders will be disillusioned and disappointed in the results,” says Dave Jordan, vice president and global head of consulting and services integration at Tata Consultancy Services.
The COVID-19 pandemic has also raised the stakes of SLA management. “SLAs reinforce those agreed levels of performance required for clients to continue to receive the services required to run their operations regardless of the location of client or provider staff, the impact of the pandemic, or the client’s customers’ ability to buy and/or interact,” says Clay Calhoun, partner at technology research and advisory firm ISG.
What’s more, as many IT functions continue to work in a dispersed manner, SLAs have become a primary measure of performance. “This new COVID-induced reality increases an organisation’s dependency on reliable data to identify how well (or poorly) operations are performing,” says David Borowski, director with business and technology consultancy West Monroe.
SLAs have often been a point of contention — not only between providers and customers, but within organisations themselves.
“It often boils down to IT leaders hating to read legal agreements while procurement and legal teams can be focused on business and financial risk rather than IT dependencies or the impact of system outages to delivering services,” says Joel Martin, cloud strategies research vice president at HFS Research. And as companies move more solutions to the cloud, understanding the service levels agreed to is important to developing trusted and dependable relationships.
Moreover, SLA development and management has evolved significantly in recent years, with an eye toward driving business value.
“Service recipients have become far more sophisticated in how they manage SLAs,” says Marc Tanowitz, managing director with West Monroe, adding that they “are looking for end-to-end outcomes that drive business success and recognise that the true value of SLAs is to drive business insights and performance — rather than to reduce the cost of service by capturing performance credits.”
Nonetheless, there remain some common — and potentially costly — SLA mistakes IT leaders can make. Following are some of the most detrimental to the IT organisation and the business at large.
1 - Failure to agree on and establish SLAs up front
“Oftentimes, both parties presume that expectations are clear and mutually shared, but that may not be the case if they are not spelled out,” says Robert Castles, principal and CTO of PMG, maker of process organisation software. “It is far preferable to both parties to negotiate SLA terms before an issue exists.”
One of the biggest mistakes an IT leader can make is ignoring the “A” in SLA, adds Wendy M. Pfeiffer, CIO at Nutanix.
“An agreement isn’t a one-sided declaration of IT capabilities, nor is it a one-sided demand of business requirements,” she says. “An agreement involves creating a shared understanding of desired service delivery and quality, calculating costs related to expectations, and then agreeing to outcomes in exchange for investment.”
2- Too many SLAs
An overabundance of SLAs can lead to a breach of agreed service, resulting in a service credit that is nearly meaningless, says Mike Fuller, principal with The Hackett Group.
For example, if a customer has 65 SLAs and the at-risk amount is only 10 per cent of monthly invoiced fees, the breach of one results in a service credit that is 1/65th of 10 per cent. “Defining too many SLAs [dilutes] the impact of each one and [makes] it difficult for providers to know which are the most necessary to prioritise and actively manage,” says Borowski of West Monroe.
3 - Not understanding the provider’s point of view
“Often an SLA focuses on uptime provided by the third party; however, the business or IT leader may care more about the performance of the application or service being provided,” says HFS Research’s Martin.
When it comes to an SLA for backup or disaster recovery, for example, a company should consider clearly documenting recovery point objective (RPO)/recovery time objective (RTO) in its agreement. “The same could be said for IT towers that are moving to a cloud-native model,” Martin says. “These include service desk, service management, infrastructure management, and more.”
4 - Siloed SLAs
SLAs that are too focused on individual infrastructure and application component uptime are problematic, The Hackett Group’s Fuller says. TCS’s Jordan agrees.
“More organisations are requesting the establishment of services integration with business outcomes when it comes to SLAs. Then, based on those outcomes you get relevant IT performance metrics and it’s clear who in the ecosystem is responsible for supporting each business outcome,” he says.
With the increased focus on business outcomes, SLAs should be more consolidated and holistic and address larger umbrella categories or outcomes such as whether a business user can complete a transaction. Tanowitz of West Monroe recommends taking a portfolio perspective to identify areas where processes or provider scope can be optimised to drive improvements.
5 - No escape clauses
These are a must for ongoing poor performance or missed objectives.
“Without clear points in the contract, honestly, the SLA isn't worth much,” says Martin of HFS Research. “These should be clearly stated thresholds defining 'x' number of times in a given period and should be reviewed with the vendor regularly.”
6 - Lack of clarity around SLA calculations
“I have seen cases where the customer gets the SLA report from the provider, and it is written into their contract that only the provider’s SLA documentation is considered factual and accurate,” Martin says. “Working like that should be an obvious cause of concern for any astute leader.”
7 - No ability to measure
It’s not uncommon for IT organisations to establish a performance metric without adequate data to substantiate the objective, says ISG’s Calhoun. But not having a way to actually calculate the SLAs — clear, understood, and easy-to-use tools and processes — typically results in overly onerous or ignored SLA management, says The Hackett Group’s Fuller.
“A shift we’re beginning to see is an increased use of data and process discovery tools to measure SLAs,” says Borowski of West Monroe. “While not pervasive yet, these tools represent an opportunity to identify the most meaningful metrics and objectively measure performance (e.g., cycle time, quality, compliance). When provided by the client, it also eliminates the dependency on provider tools as the source-of-truth for performance data.”
8 - Missing IT representation on shadow deals
When the business contracts for its own tech services or IT leaders allow lower-level directors to sign deals for a growing number of services, there is increased risk exposure for the business not only in terms of SLAs but also remediation, says Martin of HFS Research.
9 - Viewing SLAs as a one-time exercise
“Achieving the right business outcomes through SLAs and service integration is like a marathon. It’s an ongoing part of IT’s core competence,” says Jordan of TCS. “IT leaders must build the muscle memory in defining their role and understanding the dollars they spend relative to the business outcomes or benefits.” IT organisations should establish competence around managing SLAs for value realisation.
10 - Assuming SLAs don’t matter in the cloud
Lack of understanding of how SLAs intersect with cloud services and applications is an issue. Network service providers, for example, are responsible for the data transfer until the exact moment the traffic is handed over to a public cloud provider.
“Yet most providers don’t offer any cloud SLAs committing to a high level of performance,” says Terry Traina, CTO at Masergy, a software-defined network and cloud platform. “Every service is an opportunity for an SLA, and the contract should cover that entire ground.”
11 - Not addressing security
Think about what continuous commitments the provider makes around disaster recovery, encryption, incident response, or vulnerability assessments. “When possible, customers should push service providers to address security in their SLAs,” says Alain Pannetrat, senior researcher and product manager with Cloud Security Alliance.
12 - Using SLAs as conflict resolution tools
Relying on contractual language to resolve an issue before digging deeper is a mistake. “The first step in any conflict should be understanding the impact and trying to address the harm rather than focusing on who was contractually at fault and what penalty should be levied,” PMG’s Castles says.
Dustin Hilliard, CTO at eSentire, adds: “It is more important to prioritise the customer relationship and outcome than litigate technical or operational misunderstandings that may have led to the conflict initially.”
13 - Focusing on penalties
Looking at SLAs as a revenue source instead of insight to drive performance improvement breeds contention rather than business benefits. “Customers shouldn’t be focused on recouping their losses,” says Traina of Masergy. After a network outage has happened, the damage is often done. IT leaders should instead focus on SLAs that hold the provider accountable for the highest levels of service up front.
Setting unnecessarily — and often unrealistically — high performance targets increases provider costs without necessarily providing a corresponding business benefit, says West Monroe’s Borowski. What’s more, vendors realise that SLA clawbacks are one-sided, says Ali Yasin, managing director in Protiviti’s financial services technology group.
“Hence, if revenue clawbacks exist due to nonperformance, then over-performance on SLAs should also provide revenue incentives. These two-sided SLAs are becoming more prevalent.”
14 - Failure to take responsibility
IT organisations have a role to play in service delivery. And those that build the most productive relationships with their service partners recognise this. It’s a mistake to fail “to recognise the service recipient’s role in enabling service providers to perform as expected,” says Tanowitz of West Monroe. SLA prerequisites may state that a certain threshold will not hold if a vendor doesn’t receive the requisite information in full to perform the function from the requesting organisation.
“Hence, an organisation must consider if the maturity of their internal processes allows for the type of SLAs they expect of a vendor,” Yasin says. “It’s possible that SLAs are put in place but never triggered because the vendor’s prerequisites are not met due to the immaturity of the organisation.”
15 - Static SLAs
It’s critical to include language in IT service contracts to automatically update or increase SLA targets based on historical trending, advises Fuller. For example, many IT organisations granted their partners SLA relief early on in the pandemic.
“As the remote operating environment has stabilised and become the ‘new normal,’ it is important to revisit whether such relief remains necessary and to also review SLA metrics and priorities to ensure they remained aligned to the business needs,” says West Monroe’s Tanowitz.
Sriramkumar Kumaresan, head of service lines markets at Mindtree, advocates for dynamic business process level agreements (BPLA) that can keep pace with the speed of change in business and technology. “Dynamic and comprehensive BPLAs enable enterprises to map IT to business outcomes thereby.”
IT leaders should also factor in increasing efficiencies and vendor stickiness. “It’s important to progressively narrow SLA key risk indicators over time,” says Yasin. “This incentivises vendors to consistently improve and remain accretive to the relationship.”
In addition, comprehensive SLAs should include ongoing review of documentation to allow the IT organisation access to critical processes should it want to change providers in the future.
