Understanding and Managing SLA (Service Level Agreement)

What Does an SLA really mean in S/w Product Industry?

What is the SLA in software, why should we get an SLA and how software development industries can perform better by understanding and managing it? These are some burning issues that every industry wants to have better solutions for making them a trusted brand. But there are lots of challenges to understand and manage its end to end implementation. So, Let’s have a detailed walkthrough of these key aspects step by step.

SLA stands for Service Level Agreement between a service provider and customer. Key aspects of the service – service availability, mutual responsibilities are agreed upon within service provider and customer. SLA can be applicable for any kind of service provided and produced product.

When we see this SLA in software development, its management becomes quite important as well as challenging.

For any software product company, three different teams usually work on product Management, Development until release and further Support. Firstly, there is the Product Management Team (PMG) which owns the complete requirement of the internal/external parties, analyses, prioritization and then the Scrum team for sprint development. Secondly, the Development team (PE) is primarily responsible for the development of any product. Finally, there is a Professional Service team (PS) which owns overall product implementation at various customer sites.

Now, let’s take a real example of any product industry where the product is released at a defined frequency (say half-yearly) and their respective service packs (customer-reported defects) are fixed monthly. Overtime (say 2 years): there are lots of versions available on the market that are being implemented by different customers. Considering that each customer requires certain specific threshold (SLA) for the different severity of defects. This means that Severity A shall be closed within 7 working days, Severity B shall be closed within 14 working days and Severity C within 21 working days. So, here the question is how to meet these SLAs for different released versions.

Key Challenges:

• The latest released product may have a high number of defects due to many reasons such as product complexity, team attrition, lack of functional expertise, team maturity and vague requirements.
• Many times, the customer fails to describe the defects and prioritize them. All clarifications, queries and other requests are generally marked with defects.
• Respective teams must put their efforts into defect analysis, root cause identification and their proposed solutions along with the development of the current running product version.
• Product Management team (PMG) does root cause analysis and parked defects for the future roadmap, but customers are asking for early release due to business impact.
• In light of these challenges, the industry usually follows a defensive approach with no penalty clause during the SLA agreement.

The challenges mentioned above are very practical, and teams are striving to do better for the action required. Hence, teams have executed their past project learning and best practices based on these real examples. Below are some proposed solutions to handle such challenges.

Proposed Solutions:

• The team shall strive for focused support execution rather than ad-hoc activities.
• To have more granular accountability, teams are further divided into sub-teams. Ex: PE team is divided into 2 sub-teams (Development team and Support team) for taking care of pure product development and defect analysis and bug fixing respectively.
• Resource estimation should be more realistic and accurate so that proper resource planning can be done proactively.
• Flexible workaround solutions for low-severity defects should be available to manage customers effectively.
• The product backlog should be regularly groomed to cover such potential aspects of such customers.

These solutions are best fit to tackle the above-highlighted issues, and many of learning are still being executed for further betterment. However, we should not be limited to these solutions alone and continue to explore more and more feasible solutions.

But if you think that some other solutions can be more effective to handle these problems, do share your thoughts and suggestions.