Service Level Agreements (SLAs) are a very important part of outsourcing agreements. Yet, they are often overlooked when creating contracts for software development outsourcing. We think this is a mistake.
What is a Service Level Agreement?
Google the term SLA or “Service Level Agreement” and you will see definitions that begin with very strong phrases like:
- “...a contract”
- “...a commitment”
- “...a covenant”
While an SLA isn’t a contract, it IS an important part of contracts with service providers such as software development outsourcing and software support outsourcing companies. An SLA may be only a few sentences or many pages. Sometimes you might see “SLAs of an agreement”, which might be confusing. A contract’s SLA is comprised of multiple service commitments - and sometimes each service commitment is ALSO called an SLA (confusing, huh?)
Talk to an Expert in SLAs for Software Development
What are the Components of a Service Level Agreement?
Each service commitment (SLA) has these attributes:
- Service - the service or action the the vendor provides. For instance, your Internet Provider gives you internet access.
- Measurement - this is a metric that quantifies the service commitment. Again, using our Internet Provider example, the measurement could be 99.999% availability (also known as “5 nines of uptime”).
- Interval - the measurement (metric) must captured at defined intervals. For example:
- “....Every time the helpdesk is called..”,
- “... every month”,
- “average of all tickets every month”,
- Obligations - Some SLAs have obligations that the Client AND the Vendor must fulfill in order for the SLA to be enforceable. Also, it’s a common obligation for the Client to declare an “SLA Violation” in order to exercise their right to receive penalty fees from the Vendor.
- Penalty - This is the penalty for failure to comply with the SLA component’s obligations (“SLA Violation”). In subscription-based agreements, the penalty a vendor incurs will usually be to give a credit back for a percentage of the monthly subscription. In software development outsourcing - anSLA penalty is often the loss of a “bonus payment” (or percentage) held in reserve by the Client for a successfully completed project with all SLA’s met.
SLA Management is reported as a top challenge for high growth companies.
The Top 4 Reasons why an SLA is Important
Here are the top 4 reasons why you need to have SLAs as part of your agreement(s) with a software outsourcing partner.
- Clarify Expectations - SLAs help quantify expectations of “goodness” from the relationship in measurable terms... no surprises.
- Focus on Customer Service - SLAs help the Vendor remain focused on customer priorities and requirements.
- Establish Measurable Standards - An SLA sets clear, measurable standards of Vendor performance.
- Penalize non-performance - SLA penalties should incentivize the Vendor to fulfill commitments made to the Client, and penalize the Vendor when they do NOT fulfill those commitments.
What SLAs Should I Use?
Accelerance would love to help you develop SLAs that are best suited for your situation. Some of the most common SLAs we see used are:
System Availability - If you have a telco circuit or an internet circuit you probably have an SLA for uptime in your subscription agreement (example: 99.999% availability measured monthly). Similarly, if your outsourcing agreement includes IaaS, PaaS, SaaSthen take a page from the telco playbook and have an SLA around availability (percentage uptime - measured over a month). Here’s a pro tip - you may care MORE about availability during your standard business hours. Try to use an SLA metric focused on BUSINESS HOUR availability - not 24x7x365 availability.
System Response - Again, if you are using cloud infrastructure, platforms of software your vendor provides - try to have an SLA for the speed of the system. If your software development outsourcing partner is delivering a turn-key solution or major component, an SLA of system response for the software they produce may be a good idea. How do you measure response time? Many companies create an SLA for response time based on one - or a few key - user functions. Another method is to quantify the expected response time of a complex, predetermined SQL query as the “service” to be measured.
Vendor Responsiveness - If you have a helpdesk service, your contract probably includes SLAs for response time (how long before a live agent responds to your ticket) and possibly mean time to resolution (typical time all tickets are resolved in a month). Similarly, think about SLAs that create expectations of responsiveness from your Vendor. Examples might be:
- Time to respond to newly posted issues or bugs found during testing.
- Time to estimate work-effort on proposed changes in scope.
- Weekly deadline to post team progress with an expectation of 100% compliance.
Customer Satisfaction: Vendors who provide some sort of support desk or helpdesk will often send users a “how did we do?” follow-up survey they send to users. You can require an SLA for satisfaction scores to measure Customer satisfaction (example: “... 95% positive feedback each month”).
Make sure you’re getting the best SLA for your engagement.
Talk to an Expert
SLA for Reporting Metrics in Agile
In an Agile Development project you may want an SLA commitment from the software outsourcing partner to periodically provide a report of software development metrics. The SLA could read something like “Vendor will provide a monthly report on the following development metrics…” Using an SLA like this accomplishes two objectives:
- The vendor is held accountable for continuous measurement and reporting. The reporting rhythm is your SLA.
- The metrics the vendor reports on, per the SLA, became baseline measurements for continual improvement.
What metrics would you expect in a periodic report? Companies using Agile development methods are able to utilize new techniques for estimating complexity and level of effort. Here are some metrics we recommend:
Lead Time - In manufacturing, the “lead time” is the length of time between receipt of an order to the point of delivery of the product to the customers. In software development, you need to measure the time elapsed from concept to the point delivery of the completed software. From project-to-project, or even Epic-to-Epic, you want to see an increase in speed to deliver software.
Sprint Time (Duration)- Teams using Agile will have Sprints measured in a few days, instead of months, for work timed in “phases” or “activities”, using traditional development methods. Track the duration of your sprints - and evaluate trends over time. You may be surprised what you learn!
Sprint Volume - How many Sprints are needed to complete a Story? How many Sprints are needed for a Version? For each of these metrics, look for consistent volume (i.e. number of Sprints produced) over time. Variations in volume could mean you have a “lumpy” plan for new feature rollout: too many in one Version, too few in another. A decline in number of Sprints produced might suggest that a recent developer change or reassignment caused a dip in team productivity.
Issues & Open/Close Rates - Measure how many production issues are reported AND closed within a specific timeframe. Observe and take action on trends, rather than establish a hard-and-fast number - there is no “right answer”.
Where Can I Find Benchmarks for SLAs?
How do you know what standards of performance to hold my software development to? Where can you get benchmarks for SLAs? The best place to find benchmarks for software development SLAs is from a company who has a deep knowledgebase of experience with software outsourcing companies across the globe,. You need to get help from a company knows outsourced software development best practices and performance standards. That EXACTLY describes Accelerance.
Our Software Outsourcing Advisory Services prepare you and your company to be ready for outsourcing, connect you with an ideal software development outsourcing partner, help you establish meaningful SLAs and work alongside you every step of the way.