“Business partners are the second most significant source of new innovation for enterprises.” ~ IBM Survey, 2006
Service Level Agreements in technology can often lead to a contentious relationship between a company that needs the service and the one that provides it.
In one of my engagements I found myself in a situation where there was much anxiety between a Fortune 500 company and one of its technology partners. Neither party was clear on how to proceed with an agreement that required management of hundreds of unique deliverables, quality of technical service, and ongoing service level management meant to support a newly implemented system.
Nonetheless a relationship had to be forged where both parties could give and take while keeping their minds on what was best for their companies.
Effort – The Service Levels
Given the situation, I realized that I had to find a win-win solution that enabled both parties to repair their relationship and ultimately meet the needs of their individual customers. Following is an account of the approach I took to defined SLAs based on Fortune 500 companies’ business needs:
1. Defined Business Objectives: The most important piece of work I undertook was defining business objectives for this relationship. If there was one thing that both parties (even lawyers) could agree on was that they both wanted to be successful in this long-term relationship. So business objectives for this relationship provided common grounds both parties could agree to and accept as a foundation for the relationship.
2. Collected and prioritized list of deliverables: I collected and prioritized list of hundreds of business deliverables including reports, statistical business intelligence, tools, real-time vs. batch updates, timed queries, customized features, etc. that needed to be part of the agreement. I also took time to review the importance of each individual item to ensure that it was actually necessary from a business perspective. To have a partner report on items that no one will use for business decisions is a waste of time and effort for both parties.
3. Outlined architectural service requirements: These are services required by most technology systems but they may vary based on what type of architecture is in place or the technical service that is being provided:
|Availability||Amount of time the service is available for use.||99.5 % availability required between the hours of 7 am and 7pm annually, and lower availability required during remainder of the time.E-commerce operations typically have extremely aggressive SLAs at all times; 99.999% availability is common requirement for a site that generates millions of dollars of revenue an hour.|
|Reliability||Comparison of actual availability to planned availability. Reliability is measured in Mean Time To Failure (MTTF) in days.||Minimum 40 Days of reliability is required by the site per quarter.|
|Scheduled Downtime||Expected times when service is withdrawn for maintenance or upgrade purposes.||Maximum of 15 hours per month, Saturdays 12am to 3am per week|
|Scalability||Ability to increase resources as service needs change over time (i.e. increase in volume of users)||Expected increase in volume of users by 25% annually.|
|Performance||Time it takes to load a User Interface for any system or website within a given timeframe.||CRM system user interface load time is expected to be minimum 2 seconds between the times of 6am to 8pm, thereafter it is expected to be minimum 5 seconds.|
|Defect Rate||Number or percentages of errors in deliverables or changes to the system.||Production failures should be no more than 5 annually. Production failures can include automated backups, restores, coding errors/rework|
4. Defined expectations for Service Level Management: This section rounded out the SLA development process to allow business managers to manage metrics on an ongoing basis. This section includes:
i. Change Management Process for managing major changes that take more than 2-3 days to complete.
ii. Support Ticket Process for managing any errors or user problems with the system. Note that in a newly implemented system, always expect the number of defects to be higher than after normalization of system during business as usual.
iii. Incident Management Process ensures that if there are significant issues like unscheduled downtime, there is a clear understanding of who should be notified, what actions need to be taken to address the downtime, what resources are available during off business hours to solve the problem, etc.
iv. Reporting Process allows business managers of the system to manage their SLAs in a systematic way. Example would be schedule of monthly meetings to review exception reports where only breaches of metrics are reviewed.
5. Align business objectives with defined SLAs to ensure business needs are being met: It is essential that all SLAs are directly related to outlined business objectives. Without this step it is possible that you will ask and pay for service you don’t need or worse not have enough services to meet the customer’s needs.
Process – The Agreement
After completing service levels, I went on to create a contract with the terms to enable these levels of service. The agreement in this case needed to ensure that both parties clearly understood why the service metrics were important. It is a fact that if Fortune 500 company was to continue to provide the service necessary to serve its customers, the technology partner must ensure that they can provide it and continue to improve it as the need changes. But if the technology company failed to provide the service necessary, there would be financial consequences.
For each service level metric breach, a percent reduction in support costs charged by technology company was negotiated. These percentages were between 2% to 5% based on the importance of the service to the business. The technology partner needed to improve their service based on the needs of the business of their client, the Fortune 500 company. And the Fortune 500 company could concentrate on serving their customers rather than rigorously managing service providers.
The financial reductions were not meant to cripple the service provider but ensure that the service behavior remains consistent. It was therefore not necessary to stage hardball negotiations, but rather reach an agreement where the partner is gently reminded of their responsibilities.
My ultimate goal here was to set up a long-term relationship where two partners could work together to grow each other’s business. A win-win partnership for the long-term.
- Business objectives of the company that requires the service
- Service levels defined based on business objectives including direct deliverables, architectural requirement and service level management processes
- Agreement negotiated based on importance of each service level that enabled a business objective
- A long term partnership that is set to enable new innovations
Kiran Sohi’s career has focused on leading companies to success by enabling effective decision-making. While her passion is strategy and technology, her work spans a number of corporate strategy disciplines including product development, process design, marketing and financial forecasting.Prior to finding OPEN WRX Consulting, Kiran was a business consultant at CIBC and Innovapost, where her clients included Canada Post and Purolator. She also had the pleasure of working as a strategist for NBA, Kraft, Samsung and Travelex. Visit openwrxconsulting.com for more info.