Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 A Necessary Evil, and Why they are...

Listen. Plan. Deliver.

Project Delivery Summit – 12-9-2015

A Necessary Evil, and Why they are important…December 9, 2015Project Delivery Summit

Service Level Agreements - SLAs



Introduction

Hali Reyes (Customer perspective)Executive Director WCDS Consortium30 years of experience in public sector IT

projectsFully executed contract value $500M+

Frank Otto, PMP (Vendor perspective)Managing PrincipalNexLevel Information Technology, Inc.More than 25 Years of State and Local

Government IT ProjectsHelped many clients with SLAs



What we will cover

Customer and Vendor PerspectivesWhich projects need SLAs?Why are SLAs necessary?How are SLAs developed?How are SLAs managed and

applied?Q & A



What are SLAs?

Service Level Agreements are contract obligations that describe the expected level of service and how that service will be measured and managed throughout the contract



When do you need SLAs?

Large, custom-service contractsExamples

• WCDS Consortium – CalWORKs Information Network (CalWIN)

• DFW - Automated License Data System• CHP – Computer Aided Dispatch System

Some services have existing SLAs:Cloud providers

• Azure – Monthly uptime of 99.95%Telecom providers



Why are SLAs necessary?

Provides mutual understanding of service to be deliveredDefines expected quality and

importance of services SLAs set clear expectations of

the services to be deliveredSLAs delineate responsibilityConsequence – Liquidated

Damage



Defining the SLAs

SLAs are defined in the RFPIt is customary to leverage SLAs from past

projects that are similar in size and scopeDuring re-procurement, it is typical for the

RFP to be updated with new vendor obligations based on the account’s history and past vendor’s performance

Vendors will cost a RFP response based on SLA obligations

SLAs are often a significant part of contract negotiations



Managing the SLAs

The contract defines what needs to be measured

The contract does not contain enough detail to define how each SLA will be measured

The vendor and customer need to mutually agree upon how each SLA will be measuredThis process is very time-consumingBe prepared to create a mutually respectful

and results-oriented environment



Managing SLAs

After agreement is reached about how the SLAs will be measured, it is time to define the processWhat reports and monitoring tools

will you need?Who will monitor?How will it be validated?What is the escalation process if

you disagree?



Common SLAs

UptimeSystem Response TimeOnsite Response Time (Repair)Call Answer StatisticsProject Deliverables on TimeSoftware DevelopmentBatch Processing



Uptime Example

Where to measureServer O/S, Database, Application

How to measureWhen did downtime start (helpdesk ticket?)When did downtime end?What was down?

• Complete system, one module, one site…

Subtract scheduled downtimeRemove what you control

Network, building power, HVAC



Uptime Chart

Availability % Downtime per Year

Downtime per Month

90% ("one nine") 36.5 days 72 hours97% 10.96 days 21.6 hours98% 7.30 days 14.4 hours99% ("two nines") 3.65 days 7.20 hours99.5% 1.83 days 3.60 hours99.9% ("three nines") 8.76 hours 43.8 minutes99.99% ("four nines") 52.56 minutes 4.38 minutes99.999% ("five nines") 5.26 minutes 25.9 seconds



System Response Time

Where to measureDatabase, Application

How to measureScripted toolStopwatch over a shoulderDatabase transaction time

Remove what vendor cannot controlNetwork?



Onsite Response Time (Repair)

Tracking time starts when call is placed (trouble ticket)Metropolitan areasRural areas

Tracking time ends when repair personnel are onsite

Consider tracking time to repairIssue - Need to review all repair

trouble tickets



Call Answer Statistics

Example: Outsourced Help DeskStats should come from ACD/PBXTrack:

Average call answer timeAverage and maximum hold timeCount busy signals (at the switch)



Project Deliverables

Project Deliverables (e.g. Project Plan, Scope Plan, Comm Plan, etc…)

Set turnaround times for Deliverable Expectation Documents (review days per number of pages)

Set dates for DeliverablesSet turnaround times for edits

(cosmetic vs. content)



Software Development

Release QualityUser Acceptance Test (UAT)Features and Functions

Release TimelinessTarget Date

Deficiency ResolutionTimelyBy Priority



Batch Processing

TimelinessExample: System up by 6:00 amCan impact performanceCan impact time-sensitive processes

Percent of jobs completing successfullyCancelled jobs can impact client

Day, Week, Month, Quarter, Annual



Problematic SLAs

Downtime for workstationsDowntime from trouble ticketsSlow response time measured at

DatabaseUptime measured at O/S



SLA Management

SLAs need to be monitoredMonthly meetingVerification can be hard and time

consumingVendor report of all SLAs

Start in RFP



Philosophy of SLAs

Create an environment where:Processes are definedMonitoring occursVendor and client mutually contribute

Core SLA TeamWorks through issuesKeeps discussions to core members

Escalate to management as needed



Questions

Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 A Necessary Evil, and Why they are...

Documents

Transcript of Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 A Necessary Evil, and Why they are...