1. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 A Necessary Evil, and Why they are important… December 9, 2015 Project Delivery Summit Service Level Agreements - SLAs

2. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 Introduction  Hali Reyes (Customer perspective) Executive Director WCDS Consortium 30 years of experience in public sector IT projects Fully executed contract value $500M+  Frank Otto, PMP (Vendor perspective) Managing Principal NexLevel Information Technology, Inc. More than 25 Years of State and Local Government IT Projects Helped many clients with SLAs

3. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 What we will cover  Customer and Vendor Perspectives Which projects need SLAs? Why are SLAs necessary? How are SLAs developed? How are SLAs managed and applied?  Q & A

4. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 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

5. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 When do you need SLAs?  Large, custom-service contracts Examples 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

6. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 Why are SLAs necessary?  Provides mutual understanding of service to be delivered Defines expected quality and importance of services  SLAs set clear expectations of the services to be delivered  SLAs delineate responsibility  Consequence – Liquidated Damage

7. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 Defining the SLAs  SLAs are defined in the RFP It is customary to leverage SLAs from past projects that are similar in size and scope During 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

8. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 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 measured This process is very time-consuming Be prepared to create a mutually respectful and results-oriented environment

9. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 Managing SLAs  After agreement is reached about how the SLAs will be measured, it is time to define the process What reports and monitoring tools will you need? Who will monitor? How will it be validated? What is the escalation process if you disagree?

10. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 Common SLAs  Uptime  System Response Time  Onsite Response Time (Repair)  Call Answer Statistics  Project Deliverables on Time  Software Development  Batch Processing

11. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 Uptime Example  Where to measure Server O/S, Database, Application  How to measure When did downtime start (helpdesk ticket?) When did downtime end? What was down? Complete system, one module, one site…  Subtract scheduled downtime  Remove what you control Network, building power, HVAC

12. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 Uptime Chart Availability % Downtime per Year Downtime per Month 90% ("one nine")36.5 days72 hours 97%10.96 days21.6 hours 98%7.30 days14.4 hours 99% ("two nines")3.65 days7.20 hours 99.5%1.83 days3.60 hours 99.9% ("three nines")8.76 hours43.8 minutes 99.99% ("four nines")52.56 minutes4.38 minutes 99.999% ("five nines")5.26 minutes25.9 seconds

13. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 System Response Time  Where to measure Database, Application  How to measure Scripted tool Stopwatch over a shoulder Database transaction time  Remove what vendor cannot control Network?

14. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 Onsite Response Time (Repair)  Tracking time starts when call is placed (trouble ticket) Metropolitan areas Rural areas  Tracking time ends when repair personnel are onsite  Consider tracking time to repair  Issue - Need to review all repair trouble tickets

15. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 Call Answer Statistics  Example: Outsourced Help Desk  Stats should come from ACD/PBX  Track: Average call answer time Average and maximum hold time Count busy signals (at the switch)

16. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 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 Deliverables  Set turnaround times for edits (cosmetic vs. content)

17. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 Software Development  Release Quality User Acceptance Test (UAT) Features and Functions  Release Timeliness Target Date  Deficiency Resolution Timely By Priority

18. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 Batch Processing  Timeliness Example: System up by 6:00 am Can impact performance Can impact time-sensitive processes  Percent of jobs completing successfully Cancelled jobs can impact client  Day, Week, Month, Quarter, Annual

19. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 Problematic SLAs  Downtime for workstations  Downtime from trouble tickets  Slow response time measured at Database  Uptime measured at O/S

20. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 SLA Management  SLAs need to be monitored  Monthly meeting  Verification can be hard and time consuming  Vendor report of all SLAs Start in RFP

21. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 Philosophy of SLAs  Create an environment where: Processes are defined Monitoring occurs Vendor and client mutually contribute  Core SLA Team Works through issues Keeps discussions to core members  Escalate to management as needed

22. Listen. Plan. Deliver. Project Delivery Summit – 12-9-2015 Questions