Version: 1
Status: draft 2/10/00
Contact: Harry Sellers

The purpose of this model is to describe the background, justification, and the required elements for VCCS Service Level Agreements (see End User Expectations document).

This model defines the elements of the SLA needed to describe the level of service agreements between VCCS constituencies.

This guideline covers all operating units of the VCCS (See Shared Customer Support Services document.

Customers (end users), the college IT support organization, and the VCC Utility must come to agreement on their respective expectations, responsibilities, and levels of support required for each application. The Service Level Agreement establishes a contract between the college/Utility technical support organization and the groups they serve. In establishing an SLA, the customer bears some responsibility for their own technical and application training, maintaining a knowledge of their processes, and establishing some problem determination skills. SLAs set expectations by explicitly defining the products, services, and support structure the college/Utility IT support organization will provide. In addition, SLAs serve as a reality check for all parties involved in the customer support process, crystallizing the links among IT services and the performance, operations, and costs of providing those services.

SLAs should be established for identified services and applications that are significant in the daily operation and support of VCCS business processes. These would include, but not be limited to:

Student Information Systems (SIS)

Instructional Support Systems

Administrative Information Systems (AIS)

Management Information Systems (MIS)

E-mail/Directory/Security systems

Help Desk Problem Management System

Network infrastructure and WAN connectivity

Video Network

Operating System and related systems software (i.e. Oracle) support

Commonwealth Classrooms

Classroom Support

Office Support

To be successful in the VCCS environment, SLAs will need to reflect consensus between the technology support organization (college and Utility) and the various business unit managers in terms of what services are defined and what events are measured. Pertinent services should be expressed in a way that the customer understands

Each SLA should include at least the following elements:

Customers – who specifically is supported by this SLA

Mission – what does the application or service supported do

Location – where are the services and support located

Contacts – who provides technical support

Services Covered – specific description of the application or service provided

Service Goals – measurable tasks, deadlines, or milestones

Hours of Support – specific coverage hours provided

Environments Supported – hardware, software, release levels, etc. covered

Support Levels – specific escalation levels provided in the agreement

Service Metrics – specific measurable events covered by the agreement

Coverage: The products and services covered by an SLA must be built around measurable events (e.g., 30 percent of software-related trouble tickets will be closed during the initial call, 40 percent within two hours, 20 percent within one business day and 10 percent within five business days). This will ensure that SLAs can be monitored for meeting performance standards, and that customer expectations are met. To ensure measurability, coverage should have well-defined opening triggers (e.g., when the call is received by the help desk) and customer-approved closure triggers (e.g., asking the customer, "Are you satisfied that this problem has been resolved?"). Performance standards should be set conservatively in the beginning, and then increased as more experience with delivering the service is developed. One critical success factor is the implementation of help desk problem management tools such as Applix that can track problems and be used to measure SLA performance levels. Finally, SLAs should list what is being excluded as well as what is being included.

Marketing: SLAs work most effectively when generally recognized. The college and Utility must publicize their existence. It is recommended that the Utility post system-wide SLAs on the web and college-specific SLAs be posted on the college web sites. Periodic publication of how well (or poorly) IT is meeting performance standards must be a part of the process.

Review: SLAs must be reviewed periodically to ensure they are synchronized with the existing technology base, customer expectations, and available technical support resources. It is recommended that VCCS SLAs initially be reviewed annually.

Example: See example Service Level Agreements.