8 Ingredients for Crafting a Service Level Agreement
By Sean Fitzgibbons | August 13, 2014
Whether augmenting your current development team or leveraging third-party vendor resources for application management, a clearly defined Service Level Agreement (SLA) is key to the success of your engagement.
SLAs have traditionally applied to IT service providers, guaranteeing performance, uptime, incident reporting, and responses. The fundamentals, though, can be adapted to apply to any agreement in which new resources are being engaged and there is a level of performance expected in delivery.
With an SLA in place, both client and vendor are aware of what they have committed to deliver and there are clear consequences if delivery falls short of—or exceeds—the mutually agreed-upon metrics. A well-crafted SLA will provide client with recourse should a vendor underperform. It will also protect vendors by setting client responsibilities and defining the performance metrics to hit.
The following eight elements are essential to any SLA between a client and a services provider:
1) Define Metrics & Velocity
What are the units we can use to break down the work and what is the expected time to complete the work? Each engagement is different, as is each client and vendor. Aligning on what metrics both parties will manage to is the first step in defining an SLA.
General terms can help, such as defining whether a task is small (several hours to complete), medium (a day or two), or large (over three days). Once a size is determined, it should be easy to define expectations for team velocity. Time to complete a task can be determined by what other vendors or in-house resources have performed to. For instance, do you expect your new vendor to outperform in-house averages? Perform slightly lower? The same?
Use these metric definitions to determine the velocity to be expected from a vendor team. If a team of three developers is expected to complete an average of 4 medium-sized tasks each per week, the total team velocity to be expected is 12 tasks.
2) Standards for Quality of Work
Particularly applicable for development teams, there is often a quality standard expected of the work being delivered. However, as clients and vendors differ, there may be no “universal standard.” Any explicit best practices, coding, or quality standards for the work to be completed should be put into writing.
Standards help a client set expectations and vendors benefit by ensuring the team they put in place is capable of the level of work being requested.
3) Ongoing Responsibilities
Keeping work going can be just as challenging as getting it started. In your SLA, both parties will have responsibilities that must be fulfilled in order to meet the desired metrics.
Some common responsibilities to define include:
- Task assignment: Who assigns work and how far in advance? A steady backlog of work should be kept in reserve to ensure the team is efficient and able to move onto new items.
- Communication & availability of resources: Not only should the time when resources are working be defined but also channels (email, phone, messaging) through which client and vendor resources can communicate. A lack of timely responses can adversely impact team performance.
- Review and feedback cycles: There should be a common understanding on review processes and timing for all work submitted to a client. Depending on how tasks are reviewed, team resources can wait for responses or begin a new task while awaiting feedback.
- Systems access: Define the systems that all parties will need to access in order to complete work. If accounts or credentials expire, teams may burn hours not working because of a blocker.
One responsibilities are defined, the SLA is set-up for success.
An equal playing field should be established for an SLA so that both parties have visibility into the work being completed. If a standard ticketing system like JIRA is not available, the vendor should provide a report of hours spent by each resource on a weekly basis and the number of “tasks” completed based on the metric definition above.
When provided regularly, this reporting will provide clear and objective visibility for all parties into the velocity of work being completed.
All teams will encounter aberrations and circumstances that impact the ability to deliver. However, if a team is consistently under or over delivering it may be time for both the client and vendor to revisit the SLA. Both parties must mutually agree to the length of time work can be outside the SLA before a review and/or penalty is enforced.
As an example, an agile development team on a two week sprint may underperform one week and excel the following with a net-zero impact to the SLA over the course of the sprint. However, two consecutive weeks of underperformance impacts the final delivery and should be subject to review.
6) Audit / Review
Implementing an audit or review process allows for both parties to agree upon the reasons for performance issues and then align on corrective actions. It is in both vendor and client interests to have the team operating as efficiently as possible and an audit can uncover underlying issues before they have a big impact.
Structure for an audit can take any number of forms but try to focus on specific tasks that have taken the most time. By doing a deep dive into these issues, the team can determine causes for delay and see if there is a pattern impacting performance (e.g. are coding standards not being followed causing multiple rounds of revisions or re-work? Do the tasks lack key information when provided that would help the work to be done efficiently?). Aligned on root causes, vendor and client should agree upon the corrective actions that will be put in place on either side to improve performance.
Vendor and client should align on the appropriate penalties for the SLA. Both under-performance and over-performance against SLA can incur a penalty if desired. Penalties may include the ability to switch out team resources, discounts to the original contract, or re-definition of the SLA itself to meet refined metrics.
The objective of an SLA is to put in place the proper steps to avoid a penalty phase. Both vendor and client entered a mutually agreed-upon contract to deliver and pay for a defined amount of work. A penalty should be the last recourse for either party when earlier methods for remediation fail.
The largest hurdle to implementing a successful SLA is making sure it is enforced with the vendor and client teams. Before any SLA is committed, the teams should be fully briefed on what is expected of them and ownership of reporting should be assigned.
Although it requires some heavy lifting to define up front, outlining an SLA in contractual language is key to establishing an efficient working relationship between clients and vendors.
→ Ready to kick of a new project? Get in touch.
Three Project Pitfalls (And How To Avoid Them)
This article was written by Sean Fitzgibbons, Director of Client Services at JD, as well as Massachusetts' very own All-State…Read more
Cover Your SaaS: Three Areas of Consideration Before Investing in Software as a Service
With the pace of today’s business environment, anything that can help us deliver more quickly or maintain less code is…Read more
How Confident Are You In Your Solution?
How Confident Are You In Your Solution? Don't Get Caught Off Guard. Janeiro Digital solves the problems that keep you…Read more