Service Level Agreements (SLAs) are a vital part of any outsourcing engagements. Majority of the successful offshore outsourcing engagements today are SLA driven. SLAs help define your expectations clearly from the vendor and also provide you with a measurement system to evaluate the vendor performance and the health of your offshore outsourcing program.
SLA defines the support functions that the Vendor Team will commit to throughout the engagement; assigns priorities to these functions; and establishes baseline service standards and commitments. It becomes the reporting vehicle for the performance measurement and provides the opportunity to identify service-level improvements throughout the engagement.
The service-level commitments contained in the SLA are developed from estimates of current and desired service levels that are subject to fluctuation. Accordingly, the SLA should be viewed as a dynamic document and should be periodically reviewed and changed when the following events occur:
• The environment has changed;
• Clients’s expectations and/or needs have changed; and
• Workloads have changed.
• Better metrics and measurement tools and processes are evolved
The service level agreement should:
• specify the nature of the service provided – E.g. SAP application maintenance support
• identify the provider of and the customer for the service – E.g. Vendor X would provide Web Application development and support for Client’s ABC Division.
• specify the level of the service provided – frequency, coverage, timescales, etc – E.g. the Vendor shall provide 24X7 support services to Client
• incorporate limitations/may include details of the refunds/compensation if things do not go to plan – E.g. the Vendor shall refund the amount of US $ xxxx or x % of the total invoicable amount in case the successful project implementation is not completed on or before June 15, 2007.
• be indicators of quality – E.g. The vendor shall meet the delivery schedules 95% on time during the contract term
• make expectations explicit – E.g. Client would need a dedicated communication link between the vendor and their office in New York with a guaranteed uptime of 99.9%
• assist communication – E.g. There would be weekly conference call between the Client Project Managers and the vendor offshore team to review the progress and clarify doubts, if any
• may help clarify the service which can be expected and what is not available – E.g. The vendor should provide a full time on site co-coordinator for Client. Client should also get it clarified if the onsite co-coordinator would be billed or not billed directly to them
• ensure that providers become accountable for delivering the serviceand its quality – E.g. The vendor also agrees to help Client to improve its internal IT processes in line with the SEI CMM standards.
• indicate personal responsibilities and accountabilities of both vendor and Client – E.g. Client would provide the existing documentation available for the various software used by the ABC. It would be the responsibility of vendor to build on the base version and deliver improved comprehensive versions of these documents.
• ensure that customers / users at Client become aware of the costs of the service and any additional cost if they change their minds or their requirements – E.g. The vendor will migrate the existing COBOL database to Oracle 8i. However, in case the data is to be migrated from COBOL to Oracle 8i as well as MS SQL 2000, the vendor may charge additionally. Similarly the DBA may be available free once every week and any additional service by the DBA during the week would be billable @ US $ 100 per hour?
• include exclusions to accommodate changes beyond the control of either party – E.g. Clause relating to force majeure like act of God, etc.
Specifying the services to be provided puts flesh on the bones of the SLA. Specifications for all types of support services could set out:
• the precise nature of each function or service provided
• the volumes and quality to be achieved for each of these services
• whether optional services are on offer – and if so, what they are and what they cost
• what procedure should be followed if it becomes necessary to vary the agreement or specification
• where applicable, the response times to be achieved by the provider when receiving requests for assistance
• sanctions for non supply or poor quality.
If charges are to be applied three types are possible:
• input-based charges such as an hourly rate, based on actual costs, for actual time spend
• charges partially dependent on inputs, such as pre-determined (perhaps averaged) hourly rates, charged against actual time spent
• charges wholly independent of inputs e.g. pre-set free scales, schedules of rates and lump sums.
Possible charging methods could include:
• unit charges, such as pre-set sum per person recruited or computer supplied or a per capital charge per training day for training course attendances
• fixed price sums for undertaking projects – e.g. lump sum charges (as per conventional commercial consultancy practice) for undertaking a staffing or IT review
• daily (or hourly)
‘consultancy’ rates, for work done on a day work basis
• lump sum retainer fees (probably annual) for maintaining a general availability to provide advice and assistance.
Charges should always:
• be consistent and unambiguous – the user must at all times know what charges are being accrued
• be understood by the users and be open to their influence (i.e. users should be able to influence their own costs by their decisions about the pattern of usage of the services on offer)
• give users a choice of options (i.e. users should be able to choose between paying as they go on a direct usage basis, or selecting a lump sum or general retainer)
• be easy to bill and keep accounts
• be in a form which facilitates comparisons of the costs and charges for similar services in other departments or external suppliers.
• All documents which have commercial implications (e.g. time sheets, QA report, project plan) should be signed by Client and vendor representative and always attached with invoices
While framing the SLAs, the first and the most important point to be addressed is to define the incident classification for both all types of projects (e.g. new development as well as maintenance projects). An example of the same is given below:
Fatal:
Failure deemed as having a critical / fatal impact on the business – e.g.
For New Development
• Delay in delivering as per the agreed schedule beyond 2 weeks
For Maintenance type of projects
• Application not usable for any purpose
• Time critical service will not run
• Failure of any significant part of a large business critical application
• Data loss or data corruption in any part of the Application which is critical to the business.
Major:
Failure deemed as having a high impact on the business – e.g.
For New Development
• Delay in delivering as per the agreed schedule beyond 1 week
For Maintenance type of projects
• Problem causing serious system degradation
• Important service unable to run
Minor:
Failure deemed as having a medium impact on the business – e.g.
For New Development
• Delay in delivering as per the agreed schedule beyond 3 days
For Maintenance type of projects
• Problem causing significant Application degradation
Normal:
Failure deemed as having a low impact on the business – e.g.
For New Development
• Delay in delivering as per the agreed schedule by 1 day but which can be covered up easily
For Maintenance type of projects
• Bespoke software problem causing minor Application degradation
• Request for advice and guidance on product usage
Client and the vendor should also mutually agree on the response time for each of the
above category of the incident. Client should also define a metrics system to evaluate the performance of the vendor on a quarterly basis and link this performance with the vendor payment terms.
Client and the vendor should also mutually agree on the response time for each of the above category of the incident. Client should also define a metrics system to evaluate the performance of the vendor on a quarterly basis and link this performance with the vendor payment terms. This can be done by agreeing to pay a base rate and then based on the performance metrics, pay incentive or deduct penalties. For example, Client may agree to pay a rate of US $ 22 per hour for offshore projects. However, Client can put a clause that on a monthly basis they will pay @ $ 20 per hour. The additional US $ 2.00 per hour will be paid in the following way at the end of each quarter:
US $ 2.00 per hour will be paid in case the vendor achieves a score of 99% on the metrics.
US $ 1.00 per hour will be paid in case the vendor achieves a score of 95% on the metrics
US $ 2.00 will be deducted towards penalty for performance below 95% on the metrics
For more information, please visit www.sourceparadigm.com . The author represents, Source Paradigm Limited, a UK based consulting company providing services in the areas of Offshore Outsourcing, Process Enhancement and Systems Integration.
