Service Level Agreement Template - U.S. · Web viewService Level Agreement Template Last modified by Lubinski, James (HP) Company Dept. of Veterans Affairs

<Service Name>

Service Level Agreement

<Month><Year>

Version <#.#>

Department of Veterans Affairs

This template contains a paragraph style called Instructional Text. Text using this paragraph style is designed to assist the reader in completing the document. Text in paragraphs added after this help text is automatically set to the appropriate body text level. For best results and to maintain formatting consistency, use the provided paragraph styles. Delete all instructional text before publishing or distributing the document.

This template conforms to the latest Section 508 guidelines. The user of the template is responsible to maintain Section 508 conformance for any artifact created from this template.

Revision HistoryNote: The revision history cycle begins once changes or enhancements are requested after the Service Level Agreement has been baselined.

Date Version Description Author

Place latest revisions at top of table.

The Revision History pertains only to changes in the content of the document or any updates made after distribution. It does not apply to the formatting of the template.

Remove blank rows.

<Project Name> Service Level Agreement ii <Month> <Year>

Service Level Agreement

Service Name: <Enter Service Name>

Service Level Category

Description

Application Code <Enter Application Code, if applicable>. If not applicable, enter N/A

Service Level Agreement Duration:

This agreement renews automatically one (1) year from the date of SLMB approval.

Requested Service Level

<Enter desired service level (i.e. Mission Critical (99.9% service availability), Essential Support (99.5% service availability), or Routine Support (99% service availability))>

Service Level Agreement Scope

This Service Level Agreement (SLA): Provides a description of the <Service Name> service covered by

the SLA Defines the service’s key stakeholders and their responsibilities Defines the service hours for <Service Name> service, Describes key SLTs and key Service Level Targets and Service

Level Goals specific to <Service Name> that shall be electronically measured and reported to gauge acceptable and degraded service performance

Identifies the key performance indicators (KPIs) specific for <Service Name> service as identified by the service’s key business stakeholders

Provides schedules for escalations and conflict resolution Provides guidance on modifications and reviews.

Service Description

<Service Name > is a <explain the service, what it does>

<Service Name > consists of the following sub-services (if applicable):

aaa

bbb

ccc

ddd

Identified Stakeholders

Service Consumer: <list Service Consumer(s)>Service Provider: <list Service Provider>Additional Stakeholder: <list any additional Stakeholders>

<Project Name> Service Level Agreement 1 <Month> <Year>

Service Level Category

Description

Service Hours Hours of Operation 24x7x365Allowable Service Outage Exceptions: NoneAllowable Maintenance Windows:List all planned maintenance windows to include minor and major releases, EO CRISP releases, and any other maintenance:

Thursdays from 5:00am to 5:30am ET, monthly Sundays 8:00am to 4:00pm ET, once per quarter 10:00am to 6:00pm ET, 2nd Sunday of every month Notification: Extended release windows can be requested by

OI&T with no less than 30 days advanced notice, approved by the Customer no later than 7 days after request

Additional Release / Maintenance Windows (Interdependent Systems):

AAA: Monday through Friday, 10:00 PM to 6:00AM ET BBB: Every Saturday from 7:00 PM to 8:00 PM ET CCC: First Sunday of every month from 1:00 AM to 5:00 AM

ET DDD: 4th Saturday in the 3rd month of the Quarter from 7:00

PM to 1:00 AM ET

Service Level Targets and Goals

List the Service level Target (SLT) as provided by the business and agreed to by OI&T. List the Service Level Goals (SLG) as defined by the key business stakeholders. All SLTs and SLGs presented below will be reported on a dashboard.

A target and goal will also be set for degraded service/performance. The system will be considered degraded when greater than 0% or less than 5% of users are affected. The system will be considered down when 5% or more of users are affected.

Service Level Target Area Service Level Target Service Level GoalsTarget Area 1: <List Service Level Target area>

<Service Level Target> <Service Level Goal>

Target Area 2: <List Service Level Target area>


Target Area 3: <List Service Level Target area>


Example:Target Area #1 Response Time

Target:≤ 2.8 seconds

Goal:≤ 2.5 seconds

Additional service level targets may be added as needed.


Key Performance Indicators

A KPI is used to determine how you are performing against your business objectives. Any metric which has the ability to directly impact an important outcome (e.g. customer service) can be a KPI. KPIs are optional and only the business can determine them. For example, for VBMS, a KPI could be the average time for application for benefits to be processed.

List the metrics that are used to measure the achievement of the Critical Success Factor (see CSF in definition of terms) as defined by the business. All KPIs presented below will be reported on a dashboard.

Key Performance Indicator MetricsKPI 1: <List KPI>

<IT Performance Dashboard report location>

<Target metric for success>

KPI 2: <List KPI>



KPI 3: <List KPI>



Additional key performance indicators may be added as needed.

Service Level Category:

Mission Critical

Service Continuity Recovery Point Objective(RPO): 2 hoursRecovery Time Objective (RTO): 12 hoursMaximum Tolerable Downtime (MTD): 24 hours per event

Security Link to information security policy: <<e.g. Office of Information Security>

Customer Support Technical help desk support for <Service Name> service is required 24 hours a day, 7 days a week, and 365 days a year. VA will utilize its existing Tier 1 Help Desk infrastructure to receive and track initial inquiries/incidents.

Escalation Once the National Service Desk (NSD) is made aware of an Incident, it will follow established Procedures to ensure proper resolution or escalation within established timeframes.

Change Management

Any party to this agreement may request changes at any time by submitting a request in writing to the SLMB. The technical description of availability (what components are monitored, measured, and reported) does not require a formal SLA change. Requests to change/add to what is monitored must be sent to the SLMB who will schedule a meeting with OI&T and the customer within ten (10) business days. The goal is to reach a mutually agreeable solution within thirty (30) calendar days of the request.


https://vaww.portal2.va.gov/sites/infosecurity/index.aspx

Service Level Category:

Mission Critical

Conflict Resolution Either the customer or the service provider may request a meeting with the SLMB to address and resolve any conflicts that may arise that is not able to be resolved via normal processes and channels. A formal request shall be made to the SLMB Secretariat, and shall include a detailed explanation or the issue(s) along with documentation to point out the conflict. The SLMB will schedule a meeting with all pertinent parties within ten (10) business days and the SLMB Co-Chairs shall act as mediators for the event. Final determination and resolution shall be made by the SLMB.

Responsibilities of Stakeholders

To include: Duties of the service provider Duties of the Monitoring and Reporting Process Owner and

Process Manager Duties of the Service Level Manager Duties of the customer Responsibilities of service users (e.g. with respect to IT security) IT Security aspects to be observed when using the service (if

applicable, references to relevant IT Security Policies)

Service Reviews Monthly reporting shall be provided on or before the second Tuesday of each month, aggregating the previous month’s results and providing an average of performance results that can be weighed against the maximum and desired response times and availability.Root Cause Analysis Problem Reports are required within thirty (30) working days of a serious outage, describing the root cause of a particular incident or sequence of incidents. A serious outage is defined as a Critical Event per the National Service Desk (NSD) ticketing system. An After Action Report shall be provided by the NSD and distributed through normal distribution channels.An annual meeting shall be scheduled by the Service Level Management Board (SLMB) and shall include identified members of both the customer and service organizations responsible for <Service Name>. The representatives agree to attend the review meetings, or they agree to send a suitable and prepared alternate representative. The purpose of the meeting shall be to have an open dialogue between customer and provider to discuss overall performance of the service and particular concerns over trends and/or issues. Attendees shall be prepared with questions and responses based on the information documented in the reports. The ultimate goal of the meeting shall be to gain an understanding of customer pain points that lead to improvements in service design and management to align the needs of the business to the capabilities of IT services.


DEFINITION OF TERMSAgreed Service Time - The total agreed time that a service will be readily available for use. For example, typical service times may include: 24/7/365 (525,600 minutes of availability per year) or normal business hours, typically 8 hours daily (125,280 minutes of availability per year). Agreed Service Time can be customized based on time zones, recognized holidays, business need, etc.

Availability - The ability of an Information Technology (IT) service or other configuration item to perform its agreed-upon function when required. This means that users are able to complete tasks as advertised and/or within the reasonable amount of time expected.

Availability will be calculated as Agreed Service Time minus Unplanned Downtime divided by Agreed Service Time times 100 (to express it as a percentage)

Agreed Service Time is Total Time less Planned Downtime (see definitions below) OI&T must provide planned maintenance times for subject service and dependent

systems for exclusion from the availability and degraded service calculations The technical description of availability (what components are measured/monitored) is

maintained by the SLMB. SDE is responsible for measuring/monitoring on the technical description of availability and following prescribed formulas for calculating availability

Critical Success Factor (CSF) - A CSF is an objective that must be attained if an IT service is to succeed. Key performance indicators are used to measure the achievement of each CSF. For example, for VBMS, a CSF could be the ability to process claims timely and accurately. Another example of a CSF for VBMS could be to enable each Veteran to manage his/her relationship with VA in a unified manner.

Degraded Service - Condition that exists when one or more of the required service performance parameters fall outside of predetermined limits resulting in a lower quality of service

Degraded Service Time

Includes time when features of the service are unavailable, but the entire service is not unavailable

Includes response times greater than three standard deviations from the average response time

Includes time when the service is unavailable The system will be considered degraded when greater than 0% or less than 5% of users

are affected

Downtime - A period of time during which the users of a business system cannot use the system to perform their work. Downtime can be either planned or unplanned.

Planned Downtime Includes Planned Maintenance Time for normal service on a respective system; Includes Planned Maintenance Time for scheduled maintenance on upstream systems to which the service is dependent

Unplanned Downtime Includes all unplanned outages, including upstream outages; Includes a significant number of errors reported over a set duration of time; Includes the excess time from scheduled release / maintenance windows that extend beyond allotted


time, including the service and its upstream systems; Includes system-wide or near system-wide events, and can be national or regional in scope

The system will be considered down when 5% or more of users are affected

IT Business Service – Provided to one or more business units by IT. It is based on the use of Information Technology and is made up of a combination of IT Technical Services (applications, infrastructure and resources) that collectively support a function of the business.

Key Performance Indicators – A KPI is used to determine how you are performing against your business objectives. Any metric which has the ability to directly impact an important outcome (e.g. customer service) can be a KPI. KPIs are optional and only the business can determine them. For example, for VBMS, a KPI could be the average time for an application for benefits to be processed.

Maximum Tolerable Downtime (MTD) – The total amount of time that a business process can be disrupted without causing any unacceptable consequences. Note: See Diagram of Disaster Recovery terms below.

Recovery Point Objective (RPO) – The maximum tolerable period in which data might be lost from an IT service due to a major incident. Acceptable data loss between backups - Example: With an RPO of 2 hours and If there is a complete replication at 10:00am and the system dies at 11:59am without a new replication, the loss of the data written between 10:00am and 11:59am will not be recovered from the replica. This amount of time data has been lost has been deemed acceptable because of the 2 hour RPO. This is the case even if it takes an additional 3 hours to get the site back into production. The production will continue from the point in time of 10:00am. All data in between will have to be manually recovered through other means. Note: See Diagram of Disaster Recovery terms below.

Recovery Time Objective (RTO) – The duration of time and a service level within which a business process must be restored to at least the RPO after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity. Note: See Diagram of Disaster Recovery terms below.

Service Level Requirement (SLR) – A customer requirement for a measurable aspect of an IT Service such as performance, capacity, or availability. Service level requirements are based on business objectives and used to negotiate agreed service level targets. Even if provider cannot meet the SLR, the SLR remains intact as evidence of what customer requires and requested.

Service Level Target (SLT) – Service level targets are based on service level requirements, and are the measureable service objectives that can be met given the available infrastructure

Service Name – Title for the service being provided


Diagram: Disaster Recovery Terms


<Service Name> SLA REVIEW AND CONCURRENCE:

The parties below reviewed the <Service Name> SLA and concur.

______________Concur_____________ ________________

<Customer Representative Name> Date <Customer Representative Title, Organization><Customer Administration>

______________Concur_____________ ________________

<OI&T Representative Name> Date

<OI&T Representative Title, Organization>

Office of Information and Technology


Template Revision HistoryDate Versio

nDescription Author

December 2015

3.0 Major revision of document submission including substantial edits to fields in the Service Level Agreement section and Definition of Terms. Added SLA Concurrence page.

Office of Customer Advocacy

June 2015 2.7 Edited to conform with Section 508 guidelines and remediated with Common Look Office tool

Process Management

June 2015 2.6 Updated fields in Service Level Agreement section. Updated Definition of Terms and added Disaster Recovery Terms Diagram.

Office of Customer Advocacy

June 2015 2.5 Edited to conform with Section 508 guidelines and remediated with Common Look Office tool

Process Management

January 2015 2.4 Updated status to Final Draft PMAS Process Improvement

January 2015 2.3 Minor updates to wording and format PMAS Process Improvement

January 2015 2.2 Addition of Service Degradation definition and metrics, many miscellaneous wording changes to add clarity

PMAS Process Improvement

January 2015 2.1 Added System Errors and updated Acceptable and Degraded performance categories

PMAS Process Improvement

December 2014

2.0 Major revision of document submission PMAS Process Improvement

November 2014

1.2 Remediated with Common Look Office tool Process Management

March 2013 1.1 Updated formatting to ProPath documentation standards and edited to latest guidelines for Section 508 conformance

Process Management

January 2013 1.0 Initial Version PMAS Business Office

Place latest revisions at top of table.

The Template Revision History pertains only to the format of the template. It does not apply to the content of the document or any changes or updates to the content of the document after distribution.


The Template Revision History can be removed at the discretion of the author of the document.

Remove blank rows.


Documents

Service Level Agreement Template - U.S. · Web viewService Level Agreement Template Last modified by Lubinski, James (HP) Company Dept. of Veterans Affairs